Привет! 👋
Поговорим на тему собеседований 💬
Для себя я определяю следующие виды ⤵️
0⃣ Ленивое — собеседующий не имеет четких критериев для отбора кандидата, например, это разработчик, которого попросили провести интервью помимо его работы, а ему это делать лень. В таком случае, просто гуглится топ ~10 вопросов по Java и кое-как формируется слабое представление о том, подходит ли человек. Отсюда такая потребность в вопросах вроде "Отличие ArrayList от LinkedList", "Расскажите про ACID", "Расскажите про контракт equals и hashCode" и т.д. которые можно выучить, и если кандидат даже ни разу не умеет писать код, принимать ответственность и решать реальные проблемы заказчика, он его пройдет. Отчасти от неподходящего кандидата поможет последующий испытательный срок, но он может длиться 3 месяца, а интервью от часа до трех, тут количество сил несоизмеримо, а хочется отсеивать неподходящих кандидатов как можно скорее, скажем так, по принципу fail fast 🙂
1⃣ Тестовое задание — компания выдает задачу, которую за определенное время нужно выполнить. Казалось бы, хороший способ проверить навыки на небольшом проекте, похожем на задачу из реальной работы, однако тут есть свои минусы. Обходится ли такая проверка? Да конечно, человек может обратиться к своему другу Senior'y, найти решение в интернете, т.к. это может быть далеко не первое собеседование в такую компанию и решение уже давно слили в сеть, а постоянно придумывать новые задачи не то чтобы хочется, учитывая, что задача должна быть похожа на что-то реальное, даже если слегка изменить ее вид, суть останется той же. И при последующем обосновании своего решения, если оно вообще будет, также можно большую часть заучить, и с большой вероятностью пройти этот этап.
2⃣ Под проект — собеседующий понимает для какой конкретной работы и с какими навыками ему нужен человек. Вопросы составляются исходя из того, что придется делать на работе. Если много работы с БД, значит вопросы на понимание работы с БД, если писать средней сложности API, значит вопросы по всему циклу написания API. Т.е. здесь работает принцип, чтобы найти как можно более подходящего по навыкам человека для конкретной работы, и не переплачивать за тот опыт, который вероятнее всего не пригодится, а именно не нанимать Senior'a с опытом 10+ лет за много денег, чтобы делать средней сложности API на условно стабильном проекте.
3⃣ Под компанию — в случае, когда в компании несколько проектов, и собеседующий понимает, чем занимается его компания и какие требования должны быть к кандидату, чтобы он подходил под как можно большее количество имеющихся проектов. В данном случае имеет смысл большее количество концептуальных вопросов и их понимание, т.к. если кандидат понимает принципы, например, разобрался с тем как устроен Spring, то поставив его на проект где используется Quarkus, он сможет разобраться в нем достаточно быстро и в приемлемом качестве. Такого кандидата в большей степени можно назвать инженером, чем разработчиком на определенном фреймворке.
4⃣ FAANG — условно стандартный подход, используемый Big Tech компаниями, включающий в себя, например, [Behavioral, Coding, System design] интервью в различных количествах и вариациях. В сети огромное количество материалов "как пройти в FAANG", тем не менее, задача эта не из легких и требует большой дисциплины. Сама идея построения процесса найма высококвалифицированных инженеров по Hard и Soft скилам, достаточно сложная, особенно с масштабом таких компаний. Не всем интересно долго решать задачи на Leetcode, однако таковы правила игры, с которыми многие могут быть не согласны. Что говорить, например, в Meta даже Git не используется, не говоря уже о Spring и других технологиях. Дает ли прохождение таких интервью гарантию, что вы идеальный разработчик? — Да нет, и вот пример.
Конечно, можно комбинировать подходы, но нет 100% рабочего метода, как быстро понять подойдет ли вам кандидат. Даже если вы уверены в своем методе, на определенной выборке кандидатов, у вас все равно будет определенный процент ошибок. Но это все лишь мое мнение 🙂
А что вы думаете по этому поводу?
Поговорим на тему собеседований 💬
Для себя я определяю следующие виды ⤵️
0⃣ Ленивое — собеседующий не имеет четких критериев для отбора кандидата, например, это разработчик, которого попросили провести интервью помимо его работы, а ему это делать лень. В таком случае, просто гуглится топ ~10 вопросов по Java и кое-как формируется слабое представление о том, подходит ли человек. Отсюда такая потребность в вопросах вроде "Отличие ArrayList от LinkedList", "Расскажите про ACID", "Расскажите про контракт equals и hashCode" и т.д. которые можно выучить, и если кандидат даже ни разу не умеет писать код, принимать ответственность и решать реальные проблемы заказчика, он его пройдет. Отчасти от неподходящего кандидата поможет последующий испытательный срок, но он может длиться 3 месяца, а интервью от часа до трех, тут количество сил несоизмеримо, а хочется отсеивать неподходящих кандидатов как можно скорее, скажем так, по принципу fail fast 🙂
1⃣ Тестовое задание — компания выдает задачу, которую за определенное время нужно выполнить. Казалось бы, хороший способ проверить навыки на небольшом проекте, похожем на задачу из реальной работы, однако тут есть свои минусы. Обходится ли такая проверка? Да конечно, человек может обратиться к своему другу Senior'y, найти решение в интернете, т.к. это может быть далеко не первое собеседование в такую компанию и решение уже давно слили в сеть, а постоянно придумывать новые задачи не то чтобы хочется, учитывая, что задача должна быть похожа на что-то реальное, даже если слегка изменить ее вид, суть останется той же. И при последующем обосновании своего решения, если оно вообще будет, также можно большую часть заучить, и с большой вероятностью пройти этот этап.
2⃣ Под проект — собеседующий понимает для какой конкретной работы и с какими навыками ему нужен человек. Вопросы составляются исходя из того, что придется делать на работе. Если много работы с БД, значит вопросы на понимание работы с БД, если писать средней сложности API, значит вопросы по всему циклу написания API. Т.е. здесь работает принцип, чтобы найти как можно более подходящего по навыкам человека для конкретной работы, и не переплачивать за тот опыт, который вероятнее всего не пригодится, а именно не нанимать Senior'a с опытом 10+ лет за много денег, чтобы делать средней сложности API на условно стабильном проекте.
3⃣ Под компанию — в случае, когда в компании несколько проектов, и собеседующий понимает, чем занимается его компания и какие требования должны быть к кандидату, чтобы он подходил под как можно большее количество имеющихся проектов. В данном случае имеет смысл большее количество концептуальных вопросов и их понимание, т.к. если кандидат понимает принципы, например, разобрался с тем как устроен Spring, то поставив его на проект где используется Quarkus, он сможет разобраться в нем достаточно быстро и в приемлемом качестве. Такого кандидата в большей степени можно назвать инженером, чем разработчиком на определенном фреймворке.
4⃣ FAANG — условно стандартный подход, используемый Big Tech компаниями, включающий в себя, например, [Behavioral, Coding, System design] интервью в различных количествах и вариациях. В сети огромное количество материалов "как пройти в FAANG", тем не менее, задача эта не из легких и требует большой дисциплины. Сама идея построения процесса найма высококвалифицированных инженеров по Hard и Soft скилам, достаточно сложная, особенно с масштабом таких компаний. Не всем интересно долго решать задачи на Leetcode, однако таковы правила игры, с которыми многие могут быть не согласны. Что говорить, например, в Meta даже Git не используется, не говоря уже о Spring и других технологиях. Дает ли прохождение таких интервью гарантию, что вы идеальный разработчик? — Да нет, и вот пример.
Конечно, можно комбинировать подходы, но нет 100% рабочего метода, как быстро понять подойдет ли вам кандидат. Даже если вы уверены в своем методе, на определенной выборке кандидатов, у вас все равно будет определенный процент ошибок. Но это все лишь мое мнение 🙂
А что вы думаете по этому поводу?