«Старший разработчик» дает интервью младшим вопросы, Или: где говядина? [закрыто]

Старший разработчик — это всего лишь пара слов, они могут означать все, что угодно, в зависимости от того, что хочет компания. Не обращайте на них внимания, кроме как на общее руководство, и сосредоточьтесь на том, что вам платят. Это настоящая проверка того, что они ищут.

Я работал в компании, где все, кроме уборщиц и водителей, были старшими разработчиками или старшими инженерами.

Здесь две вещи.

1. Вы будете удивлены, узнав, сколько «старших» разработчиков не могут сделать даже основы. На моем последнем крупном раунде найма разработчиков, возможно, 75% пула провалились на первом реальном собеседовании, и мы начали шуметь, не потому что это был отличный положительный показатель, но это привлекло многих, кто не мог даже этого. Многие старшие разработчики достигают этого, проработав там несколько лет, но не продвинувшись в своих навыках, поэтому эти вопросы необходимы.
2. Сказав это, что вообще такое «старший»? Я бы не сказал автоматически, что технические навыки отличаются от роли джуниора, но я ожидаю, что это более мягкие навыки: способность управлять своим (и, возможно, джуниорским) временем; способность видеть задачу/историю с бизнесом от начала до конца и решать (или обострять) проблемы по мере необходимости; и возможность наставлять младшего в вышеперечисленном.

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

На самом деле это не «вопросы по Java», это «вопросы ООП» и «вопросы по любому языку программирования». Так что, если вы имеете в виду, что знали ответы на эти вопросы, работая с каким-то другим ООП-языком, тогда хорошо для вас.

Я думаю, что такие вопросы, а не вопросы о деталях синтаксиса или API Java, являются хорошим знаком. Это намекает на то, что компания осознает, что хорошим разработчиком программного обеспечения является то, что он понимает концепции, выходящие за рамки конкретных языков. Я был бы обеспокоен, если бы компания задавала мне такие вопросы, как «каков третий параметр функции foo в классе bar». Если не вспомню, могу поискать через минуту или две. Но если я не знаю, что такое сборка мусора, это долгая история.

Дайте интервьюеру немного слабины. Придумывать вопросы для интервью — непростое дело. Ваша проблема в том, что вопросы слишком простые? Если да, то хорошо для вас. Эти вопросы поставили бы в тупик большую часть разработчиков, с которыми я сталкивался. Если вы сможете правильно ответить на все из них, это, вероятно, поместит вас как минимум в 50% лучших, а может быть, и выше. Вы хотите, чтобы вопросы были достаточно сложными, чтобы вы могли отличить кандидатов, но если вы не даете им 20-страничный тест, вы не хотите исключать кандидата, потому что он не знал ответа на один сложный вопрос. Может быть, если бы вы попросили еще десять, он получил бы их все. Многое можно сказать не только по ответу, но и по тому, как отвечает кандидат. Очевидно, что если он понятия не имеет, это минус. Но если он отбарабанит определение из учебника, это может указывать на то, что он знает модные словечки, но на самом деле не знает, как все это работает. (Я как-то обжегся, когда нанял парня, который умел декламировать на собеседовании всякие технические термины и определения, но который оказался не в состоянии выполнить самые простые задачи. Да, он мог назвать все фреймворки и языков и продуктов, но когда мы попросили его написать экран с двумя полями ввода и сохранить его в базе данных, он понятия не имел.) Меня впечатляет, когда кто-то может объяснить концепцию четко и уверенно.

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