Типовые ошибки на собесах.
Уже разбирал типовые вопросы на собесах, теперь хочу поговорить про типовые ошибки.
Возможно, эта тема тоже станет постоянной.
Часто на интервью есть либо задачки на live coding, либо задачки на подумать - не имеющие точного ответа.
И тут я сталкиваюсь с 2 типовыми ошибками:
1) кандидат боится ошибиться, т.к. не был готов к такому повороту собеса. Поэтому отвечает кратко, не объясняет свои решения, дополнительные вопросы его вводят в ступор. Все это производит негативное впечатление и сильно снижает шансы на найм. Правильное решение: не бояться - как бы это ни странно звучало - думать, размышлять, а главное - результаты проговаривать. Даже если четкого ответа нет. Именно этого интервьюер и ждет, добавив такую секцию на собесе - понять ход мыслей кандидата.
2) кандидат скажем так сильно прикипел к своей предметной области. Предположим, его типовые задачи - реализация новых REST методов, а способ - связка controller-service-repository. Он получает задачку на собесе и сразу начинает выполнять ее по той же схеме, как делал бы на текущем месте работы. Что тут плохого? Только то, что интервьюер возможно хотел проверить знания алгоритмов, паттернов надежности или чего-то еще. А вовсе не умение раскладывать код на по слоям controller-service-repository. И получается как в анекдоте: "Некогда думать, трясти надо". Правильное решение - уточнить, что хотел интервьюер. А потом еще раз уточнить) Важнее четкое понимание задачи и обсуждение путей ее решения, чем скорость написания кода. Да, это может занять столько же времени, сколько и написание кода. И это нормально. Есть компании с нормой решенных задач на собес, но в любом случае неверно решенная задача в зачет не идет.
P.S. Отдельный важный момент связан с live coding - и это тесты. Можно сколько угодно говорить, что "надо написать тесты, я обычно так делаю, но сейчас времени нет.." Но лучше их просто написать) Можно даже перед кодом, по TDD.
#interview #interview_fails
Уже разбирал типовые вопросы на собесах, теперь хочу поговорить про типовые ошибки.
Возможно, эта тема тоже станет постоянной.
Часто на интервью есть либо задачки на live coding, либо задачки на подумать - не имеющие точного ответа.
И тут я сталкиваюсь с 2 типовыми ошибками:
1) кандидат боится ошибиться, т.к. не был готов к такому повороту собеса. Поэтому отвечает кратко, не объясняет свои решения, дополнительные вопросы его вводят в ступор. Все это производит негативное впечатление и сильно снижает шансы на найм. Правильное решение: не бояться - как бы это ни странно звучало - думать, размышлять, а главное - результаты проговаривать. Даже если четкого ответа нет. Именно этого интервьюер и ждет, добавив такую секцию на собесе - понять ход мыслей кандидата.
2) кандидат скажем так сильно прикипел к своей предметной области. Предположим, его типовые задачи - реализация новых REST методов, а способ - связка controller-service-repository. Он получает задачку на собесе и сразу начинает выполнять ее по той же схеме, как делал бы на текущем месте работы. Что тут плохого? Только то, что интервьюер возможно хотел проверить знания алгоритмов, паттернов надежности или чего-то еще. А вовсе не умение раскладывать код на по слоям controller-service-repository. И получается как в анекдоте: "Некогда думать, трясти надо". Правильное решение - уточнить, что хотел интервьюер. А потом еще раз уточнить) Важнее четкое понимание задачи и обсуждение путей ее решения, чем скорость написания кода. Да, это может занять столько же времени, сколько и написание кода. И это нормально. Есть компании с нормой решенных задач на собес, но в любом случае неверно решенная задача в зачет не идет.
P.S. Отдельный важный момент связан с live coding - и это тесты. Можно сколько угодно говорить, что "надо написать тесты, я обычно так делаю, но сейчас времени нет.." Но лучше их просто написать) Можно даже перед кодом, по TDD.
#interview #interview_fails
live coding это все-таки кодинг
Недавно писал про то, что на сессии live coding на собесе не надо сразу браться за задачу, вначале стоит позадавать вопросы и продумать путь решения задачи.
Но есть и обратный кейс. Пусть у нас остается максимум полчаса времени собеса. Есть задача на live coding. И вообще то задачку можно сделать за 10 минут. И, естественно, это понимают люди, ведущие собес. Как они отнесутся, если кандидат потратит 10 минут на вопросы, 10 минут на рассуждения как лучше реализовывать и 10 минут на написание кода? И как всегда без тестов, по причине того, что тесты бы написать надо, но времени нет. Ответ - плохо отнесутся.
И тут мы приходим к понятию баланса. Соотношению между сложностью задачи (да, ее нужно уметь оценить, причем в экспресс режиме) и усилиями, затраченными на ее решение. В данном случае баланс сильно нарушен, хотя все действия вроде бы правильные. И что самое важное - интервью намекает, как такие задачи кандидат будет решать в реальной жизни. Lead Time говорит - ну да, ну да, пошел я ...
В общем не делайте так
#interview #interview_fails
Недавно писал про то, что на сессии live coding на собесе не надо сразу браться за задачу, вначале стоит позадавать вопросы и продумать путь решения задачи.
Но есть и обратный кейс. Пусть у нас остается максимум полчаса времени собеса. Есть задача на live coding. И вообще то задачку можно сделать за 10 минут. И, естественно, это понимают люди, ведущие собес. Как они отнесутся, если кандидат потратит 10 минут на вопросы, 10 минут на рассуждения как лучше реализовывать и 10 минут на написание кода? И как всегда без тестов, по причине того, что тесты бы написать надо, но времени нет. Ответ - плохо отнесутся.
И тут мы приходим к понятию баланса. Соотношению между сложностью задачи (да, ее нужно уметь оценить, причем в экспресс режиме) и усилиями, затраченными на ее решение. В данном случае баланс сильно нарушен, хотя все действия вроде бы правильные. И что самое важное - интервью намекает, как такие задачи кандидат будет решать в реальной жизни. Lead Time говорит - ну да, ну да, пошел я ...
В общем не делайте так
#interview #interview_fails