Вопросы по алгоритмам на собеседовании - задают ли?

Всем привет, расскажите, пожалуйста, задают ли вопросы по алгоритмам на собеседованиях на должность qa automation? Какие алгоритмы спрашивают?

У меня спрашивали про хеш-таблицы, хеш-функции, бинарные деревья и бинарный поиск, быструю сотрировку, сортировку вставками.
Просили оценить сложность алгоритма.
Это сходу то, что вспомнил.

Конкретные вопросы зависят от конкретной компании. Для ориентира есть книжка “Cracking the Coding Interview”. Сайты типа https://www.hackerrank.com/ или https://leetcode.com/

1 лайк

Я спрашиваю.
Какие алгоритмы - зависит от вакансии, на которую собеседую. Начиная от чисел Фибоначчи и до каких-нить оптимизаций поиска. Семафоры и пр. реализовать руками не предлагаю - от QA автоматизатора мне это не надо :slight_smile:

Дмитрий, можете привести реальный практический пример, при котором автоматизатору нужно использовать числа Фибоначчи и оптимизатор поиска. Очень интересно узнать

Спасибо

6 лайков

Нет, разумеется. С помощью этих нехитрых примеров я проверяю 3 вещи:
1). Умение кандидата писать базовые алгоритмы;
2). Умение кандидата думать;
3). Умение кандидата оптимизировать своё решение.

Как альтернативу, можно предложить кандидату написать тест кейс на реальную систему, но тут есть несколько сложностей:
1). NDA. Я не имею права показать кандидату реальное приложение, даже пусть 3 релиза назад. А писать приложение специально для теста - у меня есть куда потратить время.
2). На тестовом ноуте надо заранее развернуть тестовый фреймворк. Можно, конечно, предложить это сделать кандидату в реалтайме - но даже в гугле время 1 интервью ограничено часом-двумя. Поскольку переговорка подбирается динамически, а кандидатов на 1 вакансию я просматриваю много - мне необходимо будет развернуть тестовый фреймворк + IDE на всех ноутах в переговорках. Мне есть куда девать своё время.
Свой ноут я не могу отдать кандидату - NDA.
3). Фреймворк вполне может быть самописным. Глупо требовать от кандидата написать тест кейс на фремворке, который он видит в 1-й раз в жизни. Кроме того, самописный фреймворк зачастую тоже под NDA, поскольку является частью программного продукта.

Поскольку у меня нет желания бодать лбом в эти трудности ради тривиальной задачи - я предпочитаю предложить кандидату абстрактную задачу и проверю его умение мыслить и строить алгоритмы на ней, а знания используемых на проекте тестовых тулов и фреймворков проверить несколькими вопросами типа “если у тебя в аппликухе тест на selenium говорит “element not visible exception”, какие могут быть причины этого и как это пофиксить”?

Вопрос холиварный конечно.

Моё имхо, что сейчас для автоматизации достаточно иметь навыки Junior developer, и алгоритмов (поиска, сортировки) знать не надо. Пару шаблонов проектирования и не более того. Единственное что нужно знать, так это какие инструменты когда применять, знать сильные и слабые стороны. Например:

  • про пирамиду тестирования, с чего бы кандидат начал свою автоматизацию.
  • что не надо юзать голый селениум, а использовать сразу готовый враппер по типу селенида.

В своей практике заметил, что часто люди действительно знают кучу алгоритмов и стараются по максимуму применить свои знания в проекте, что приводит к велосипедным фреймворкам, которые не решают проблемы.

2 лайка

Из поста Дмитрия я только понял, что ему лень думать и проще спросить алгоритмы. Не буду давать суждения по этому поводу.

4 лайка

Была где-то аналогичная тема, только среди разработчиков Java. Знание алгоритмов у них- это далеко не первый этап в эволюции. Что уж говорить об автоматизаторе QA.

Мы не задаем. Считаем, что это пустая трата времени. Но у нас есть технический тест, предшествующий собеседованию, где в частности есть задание провести сортировку массива, начать писать конвертор из римских цифр в арабские и т.п. (в том числе работа с реальными приложениями).

Цель этого теста - составить шорт-лист кандидатов для интервью. Специально для этого теста у нас есть виртуальная среда со всем необходимым. А NDA мы подписываем с каждым кандидатом, приглашенным на этап тестирования.

То есть процесс выглядит так: Отбор эйчаром кандидатов -> NDA -> Технический тест -> собеседование с руководителем направления и эйчаром -> собеседование с вышестоящим руководителем (если позиция предусматривает это) -> предложение о работе

2 лайка

знание алгоритмов стали неким вопросом затычкой во всех собеседованиях в IT и спрашивая такие вопросы собеседующий сам не понимает зачем он это спрашивает! Стандартный ответ: посмотреть как человек думает, ну что это за цирк?! Есть другая уйма вопросов которая показывает способность человека соображать. На примере сложности алгоритмов, все такие умные сидеть рассуждать, а на практике ни разу этого не применяли и не будут применять и большинство не знают (собеседующих “лидов”) в чем отличие биг О от биг тета. А если человек мыслит в правильном направлении, то понимание этих алгоритмов сведется к простой прочитке материала и ВСЁ! На моей практике встречались уйма “профессоров”, высчитывали алгоритмы и т.д. - а на практике продукт написан копи паст)))))))) вместо 100 строк, написано 1500

3 лайка

Что характерно, эти вопросы отнюдь не показывают, как человек думает. Максимум, что они могут показать, какая у человека память. Если алгоритм не применяется для решения повседневных задач, то он забывается очень быстро. Впрочем, это характерно для любых знаний.

Всегда есть уникумы которые могут прочитать Евгения Онегина наизусть. Но это не говорит о том, что они сами смогут написать письмо Татьяне.

4 лайка

Люди зачастую просто плохо умеют писать код. И вопросы типа разворота связного списка скорее на то, чтобы человек мог бегло написать один цикл и смог удержать в голове три переменные, а не знания списочных структур данных как таковых.

2 лайка

Все зависит от компании, конечно. И как я понял по комментам, никому в автоматизации алгоритмы не нужны. А если на собеседовании спрашивают алгоритмы - я бы пересмотрел желание туда попасть. Лучше технического теста нет ничего, что бы оценить кандидата. Можно выучить всю теорию на свете, но посмотреть ее применение в реальном случае это другое дело.

3 лайка