На прошлой неделе я принял проектное предложение для моей компании. Клиент запросил «Expert React + Redux Developer». Это было для уважаемой компании, поэтому я ожидал, что процесс предложения будет немного «утомительным».

Этап 1. Телефонный звонок

Поскольку все удаленные операции предпочитают выполняться, первым этапом собеседования был телефонный звонок. После сотен звонков по проектам всех типов (как от имени фрилансера, так и от имени фирмы) у меня не было проблем с ответами на типичные вопросы.

Как давно вы работаете с {insert_langage}?

Вы предпочитаете работать индивидуально или в команде?

Над какими подобными проектами вы работали?

Есть ли у вас глаз для пользовательского интерфейса?

Как интервьюируемый (или предлагающая фирму), я выработал тенденцию «поднимать» настроение тестировщику, улыбаясь по телефону (люди могут услышать улыбку) или время от времени упоминая устаревшую информацию. получить смех.

Кроме того: Возможно, «поднятие» настроения должно быть обязательным требованием работы настоящего интервьюера.

В конце интервью настала моя очередь задавать вопросы. У меня всегда много вопросов.

Кроме того:собеседники, научитесь задавать правильные вопросы. Пожалуйста, не спрашивайте вечно мучительное «Вам нравится работать в этой компании?» Для получения этой информации есть более эффективные и интуитивно понятные вопросы.

Мой первый вопрос:

Вы предпочитаете, чтобы на должности, которые вы нанимаете, мужчины и женщины занимали должность или превосходили ее?

Многие компании нанимают «Expert React + Redux Developer», чтобы он был просто «Expert React + Redux Developer». Разработчики часто владеют гораздо большим количеством навыков, чем просто один язык или платформа. Компании, научитесь инкубировать, а не раздавливать провидцев. Разработчики получают пощечину, если когда-либо не соглашаются с «командой дизайнеров».

Мой второй вопрос:

Как вы смягчаете постоянную переутомление разработчиков и инженеров, чтобы уложиться в сроки?

Правда, некоторые разработчики предпочитают работать с 12 до 20 часов. Но, другие, все равно, предпочитают идти домой в приличный час и не работать до 2 часов ночи, укладываясь в нереальные сроки.

Рекомендуемая стратегия для этого — напомнить командам разработчиков, что «успеть к цели в срок» — это здорово, но вы увидите повышение эффективности, если сначала сосредоточитесь на личном здоровье и научитесь сообщать соответствующие оценки сроков.

Кроме того: после почти 5 лет работы в этой отрасли количество проектов, над которыми я работал, которые уложились в сроки, составляет ~15%.

Не позволяйте срочному и важному со стороны клиента (или, другими словами, неспособности правильно спланировать) стать вашим срочным и важным.

Компании, уменьшите количество срочных и важных.

Этап 2: тест на кодирование

Если вы были в мире разработки, вы знаете эти тесты. 3 часа. Огромное количество инструкций. Обычное, выделенное вверху примечание: «Этот тест занимает много времени. Мы не ожидаем, что вы закончите.

ПАУЗА

Мы не ожидаем, что вы закончите.

Тогда что меня проверяют? Моя способность не укладываться в нереальные сроки?

Кроме того: Сам тест был очень хорошо определен. Все в нем было фантастическим для проверки способности разработчика React справляться со сложными проблемами.

С React + Redux требуется некоторое время, чтобы настроить правильную среду разработки. Даже с create-react-app вам придется взад и вперед повторять соответствующие запросы командной строки для всех необходимых вам пакетов.

Лихорадочно перебирая прошлые проекты, я вытащил все строки и пакеты, которые, как я знал, мне могут понадобиться.

~ 30 минут спустя, мы готовы к работе!

(Обратите внимание, что этот тестовый проект не нуждался в Redux.)

Потом перебор требований, коды ошибок, локальный запуск сервера Node для обработки запросов, отладка предоставленного ими кода…

3 часа промелькнуло. Я смотрю вверх, сейчас 19:17. Все ушли из офиса, и мой вечер четверга закончился. Тест завершен только на 70%.

Я ушел не только совершенно обескураженный из-за того, что не закончил тест (в этом отношении ни один разработчик или сотрудник не должен никогда бросать работу с разочарованием), но и разочарованный тем, что потратил впустую вечер четверга.

А потом волшебный сон разработчика.

Ночью я мечтал о проблеме и придумал фантастическое решение, которое, вероятно, можно было реализовать. Но 3 часа явно закончились.

Итак, компании, если вы хотите нанять лучшего разработчика, дайте ему время на выполнение тестов.

Мир разработки программного обеспечения — это не Матрица. Несмотря на попытку NCIS, более быстрый набор текста не означает более быстрого решения проблем.

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

Давайте начнем обесценивать общество "соблюдать сроки независимо от личного здоровья".