Вопрос 1. Что выведет этот код?

Показывают кашу какую-то. Мешанина операторов, функций, всё в кучу слеплено.

Честно отвечаю: неважно что он выведет, важно что с этим кодом нельзя работать.

Надо не голову ломать а вернуть этот код автору и попросить переписать нормально.

Вопрос 2. Какие есть уровни изоляции транзакций в БД?

Никогда не надо было, вот ни разу. Если нужда в таком знании появляется, значит с проектом всё очень плохо.

Этот вопрос — звоночек что ребята либо не знают что спросить и повторяют то что где-то слышали, что уже не очень, либо у них это реально нужно, следовательно в проекте сильно переусложнëнная архитектура с которой команда не справляется.

Вопрос 3. Что знаешь про оценку сложности алгоритма, “О большое”, “о малое”, вот в таком алгоритме сложность посчитаешь?

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

Охи, ахи, “а мы применяем!”

Спрашиваю, ну приведите пример, когда в последний раз использовали в работе?

Говорит, ну вот был месяц назад случай, разработчик принёс код на ревью, а там цикл в цикле, каждый условно на 1000 итераций. Указал что будет суммарно слишком медленно, исправили.

Говорю, ну вы там про О-нотацию хоть словом обмолвились, формулы применяли? Или просто “чел, итерации во вложенных циклах перемножатся, 1000*1000 будет миллион итераций”?

Замолчал, погрустнел, сменил тему. В итоге решение по интервью “технический уровень хороший но коммуникации не очень” (читай токсик).

Вывод:

Хотите чтобы вас взяли на работу — будьте белыми и пушистыми и не спорьте. Давайте ровно те ответы которые от вас ждут.

Но если хотите работать только с ребятами вашего уровня — будьте всегда честны, говорите прямо что думаете. Кто с вами на равных, тот это оценит.

Какими же тогда будут “хорошие” вопросы для собеседований?

Об этом написал в отдельной статье: 5 вопросов для собеседования