РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Технические интервью: хорошее, плохое и уродливое
Как человек, который в наши дни проходит технические собеседования (спасибо, COVID-19), я пришел к некоторым пониманию относительно технических собеседований или того, что в наши дни считается таковым. Вот некоторые из них…
1. Настройка
Как правило, любая компания, занимающаяся программным обеспечением (и все чаще не программным обеспечением), пытается придумать техническую проверку, которая «соответствует их потребностям», или внедрить какую-то версию процессов FAANG. Большинство из них просто копируют то, что делают «большие мальчики», даже не задумываясь об этом.
Неизменно процесс собеседования состоит из следующих частей:
- Вы отправляете заявку
- Рекрутер связывается с вами. Вы болтаете с ними о своем опыте и т. д. (~ 0,5–1 час)
- Если вы нравитесь рекрутеру, они назначают звонок для «технической проверки» (~ 1 час). Или онлайн-вызов кода (от 60–90 минут до нескольких дней в случае «домашнего задания»)
- Если вы прошли предыдущий этап, вам необходимо пройти «проверку команды» (~ 4–5 часов).
2. Хорошее
Хорошо, вы претендуете на должность разработчика программного обеспечения, вы должны знать некоторые (если не большинство) вещей, о которых вас спрашивают, верно? Верно. Вы готовитесь, как можете, ждете интервью, чистите алгоритмы/структуры данных, какой-то устаревший технологический стек, который они все еще используют, и т. д.
Наступает день «технической проверки». У вас порхают бабочки в животе, когда вы прекрасно понимаете, что вам придется «выступать» и что кто-то с другой стороны будет все время вас осуждать.
Все идет нормально. Скажем, ради аргумента, что вы проходите технический скрининг. Вы «достаточно хороши» для них, и они будут двигаться к «следующим шагам» вместе с вами. Дааа!
3. Плохое
Через некоторое время (иногда это «пока» может быть несколько недель) вы настраиваетесь на «командный скрининг». Это означает, что 4+ члена команды поджаривают вас, примерно по 1 часу каждый. Как человек, который был на другой стороне этого процесса, я знаю, как это работает. Поскольку у работающих разработчиков нет времени на подготовку к этим интервью, их 1 час обычно состоит из специальных вопросов, которые они только что нагуглили, или того, над чем они сейчас работают. Вот и все. Большинство из них прекрасно понимают, что сами не прошли бы такой проверки, если бы подверглись ей прямо сейчас.
Проходит 4+ долгих часа. Вам как-то удается пройти через это. Вы чувствуете себя истощенным, опустошенным. Теперь вам нужно поговорить с менеджером по найму. Этот разговор обычно короткий и менее требовательный. Обычно они не дают вам знать прямо сейчас.
4. Уродливый
Теперь начинается ожидание. Могут пройти дни, а иногда и недели, прежде чем они свяжутся с вами. Между тем, ваш разум сводит судорогой, пытаясь понять, что вы сделали правильно, что вы сделали неправильно и т. д. Неприятное время.
В конце концов они обращаются к вам с каким-то общим сообщением, говоря, что «они поражены вашими навыками», но они решили выбрать другого кандидата, который «лучше соответствует их текущим потребностям». Они могут или не могут пригласить вас «поддерживать связь» для какой-то будущей возможности.
К этому времени все, что вы чувствуете, это то, что вы рады, что все закончилось. Вы потратили слишком много времени и усилий, чтобы убедить их в том, что вы «правильный» кандидат. А ты нет.
Выводы
Вместо заключения, вот список вещей, где этот процесс нарушен, и возможные способы исправить это:
- В ситуации собеседования кодирование становится вещью, рассчитанной на время. Если вы хоть какое-то время работали разработчиком, вы знаете, что работа разработчика не такая. Программирование — это созерцательный (сначала нужно подумать) и итеративный (вы можете добавить то, что вы забыли позже) процесс, а не фортепианный концерт, где каждая нота должна быть идеальной (и это нужно практиковать годами).
- Если вы не одно из тех мифических существ, которых обычно называют «гуру», «ниндзя», «рок-старты» и т. д., вы не знаете всего. Что вы знаете, так это концепции/парадигмы, так что вы можете реализовать их, если нужно, с небольшой помощью того, что называется Интернетом. Я еще не видел ни одного разработчика, у которого не было бы нескольких окон браузера, полных вкладок, открытых во время работы.
- Компании думают о разработчиках как об автоматах, куда вы можете просто ввести свои (запутанные и неполные) требования, и вуаля — вот и работающее программное обеспечение, немедленно! Разработчики — это «необходимое зло»: компании предпочли бы готовое решение, но пока оно не появится, разработчиков можно терпеть. Ирония здесь в том, что разработчики, которые проводят такой отбор, знают, что это не так, но безропотно идут навстречу.
- В дни пандемии компании становятся более придирчивыми, потому что могут быть такими. Они ищут «лучшего», из нескольких десятков кандидатов. Никогда не видел столько претендентов на одну вакансию. Куда нам, не гуру, не ниндзя, хорошим работающим разработчикам идти? Вместо минимальных требований важны максимальные требования. Посмотрим, сколько мы сможем втиснуть в эту единственную позицию, и пусть за это борются кандидаты. Не хватает «гуру», чтобы ходить вокруг…
- Когда вы нанимаете сантехника, вы же не ругаете его за его «опыт», не так ли? Вы проверяете рекомендации (если они есть), смотрите их историю работы, а затем катитесь. В индустрии программного обеспечения опыт стал неактуален (и образование в том числе), если вы не можете решить запутанную техническую задачу, поставленную перед вами.
Куда идти?
- Потребность в стандартизированном, хорошо продуманном общеотраслевом процессе собеседования, тесно связанном с повседневной работой разработчика, имеет первостепенное значение. Что-то вроде сертификации, но в отраслевом масштабе, которая служила бы доказательством того, что у кандидата есть способности для выполнения работы. Это полностью устранило бы этот случайный процесс собеседования.
- Относитесь к степени информатики так, как она того заслуживает, не пренебрегайте ею. Если вы ищете разносторонних разработчиков, это ваши лучшие кандидаты, а не те, кто случайно запоминает алгоритм, который вы от них просите.
- Некоторые компании открыто хвастаются тем, что нанимают только лучших из лучших. Нет! Вы нанимаете только то, что считаете лучшим из лучших. Здесь на ум приходит ставший знаменитым доморощенный твит.
- Помните о том, для чего вы нанимаете. Нет, вы не пишете новую библиотеку/фреймворк в своей мастерской. Ваши разработчики в основном подключают данные к пользовательскому интерфейсу, вот и все. Вам не нужны гуру для такой работы.
Если этот пост кажется мне выражением разочарования, это потому, что это так, и я заранее извиняюсь за это. Просто не мог больше держать это в себе.
Ваше здоровье!
