Даже старшие разработчики нуждаются в помощи, чтобы справиться с ужасным экраном телефона и этапами «знакомства с вами» на собеседованиях при приеме на работу в области разработки программного обеспечения. Попробуйте этот совет в следующий раз.
Лучший совет, который я когда-либо слышал для технических интервью
Мне повезло, что я смог получить должность старшего разработчика относительно рано в своей карьере, по крайней мере, если считать с того момента, когда я начал мой блог на Medium.
За последние 3 года я перешел от консалтинга и фриланса к штатной должности, поэтому я участвовал в десятках технических собеседований.
Есть один ключевой совет, который, кажется, всегда приводит меня к более глубоким раундам интервью. Это просто, но эффективно.
Поделитесь своими последними работами и своими впечатлениями. Поделитесь последней ошибкой, которую вы допустили, или рабочей проблемой, над которой вам пришлось работать (разумеется, в разумных пределах).
Для меня этот совет оказался наиболее полезным во время технических телефонных разговоров, когда я впервые разговариваю с инженером, который работает в компании или, что еще лучше, работает в команде, к которой я присоединюсь.
Большинство интервьюеров невероятно вежливы и профессиональны, а это значит, что у вас будет достаточно времени, чтобы поговорить и вести беседу как кандидат.
Интервью, которые прошли для меня лучше всего, в том числе то, что дало мне мою нынешнюю работу, — это те, на которых я начинал с заявления «вау».
Когда вы представляетесь, упоминая недавнее достижение, вы, вероятно, произведете впечатление на интервьюера сразу же.
Конечно, вы можете оторваться хвастливо, а можете в итоге упомянуть технологии, даже не используемые в стеке технологий компании, но в 9 случаях из 10 вы будете выделяться из толпы.
Простая формула из 3 шагов для получения лучших результатов на технических экранах
Даже если вы сразу не упомянете о своей недавней работе и о том, как она бросила вам вызов в своем вступительном заявлении (вашем вступлении), у вас все равно может быть момент отключения микрофона позже в интервью.
Мне нравится использовать этот простой трехэтапный шаблон, когда я обсуждаю свою техническую работу в качестве профессионального веб-разработчика или инженера-программиста:
1 - Вот что я сделал
2 - Вот что я узнал
3 — Вот что я сделаю в следующий раз
Один из лучших советов, который я когда-либо получил от моего карьерного тренера Марка Д. Лэнгфорда, заключается в том, что собеседование очень похоже на свидание.
Я понял, что это означает — и это может не сработать для вас — что я должен взять на себя инициативу во время интервью, чтобы показать, что я приспосабливаюсь.
Когда я рассказываю о своей технической работе, я всегда стараюсь подробно рассказать о том, что пошло не так, и чему я научился в следующий раз.
Я обнаружил, что подавляющему большинству работодателей нужен кто-то, кто готов совершенствоваться, и особенно тот, кого не нужно просить об этом.
Прогулка по переулку памяти
Одно из моих достижений 2019 года, когда я впервые изучал React вскоре после выпуска React Hooks, связано с Prettier.
В то время я делал много простых демо-проектов, которые публиковал в своем тогда еще новом блоге на Medium.
Благодаря моему простому, чистому коду в сочетании с степенью бакалавра и магистра в области биоинформатики (концентрация в области компьютерных наук) я смог получить работу на неполный рабочий день в составе распределенной удаленной команды из 3 разработчиков.
Прошло некоторое время с тех пор, как я серьезно смотрел на производственный код других людей, поэтому я был рад загрузить GitHub и изучить некоторые запросы на включение (более известные как PR).
Сразу же у нас возникла проблема, когда все запросы на включение были бессмысленными, поскольку некоторые разработчики использовали точки с запятой, а другие нет, проблема обычно решалась форматированием всех файлов с помощью Prettier.
В этом плане была только одна маленькая загвоздка — команда не использовала Prettier. Это было еще до того, как я занялся настройкой VS Code в своем блоге.
В итоге на второй неделе я настроил Prettier для всей команды, и это сразу повысило нашу продуктивность и возможности для совместной работы.
Я все еще мог использовать это в качестве краткого примера во время моих технических интервью, как то, чему я научился, и опыт, на котором я вырос.
Суть в том, что я узнал, что форматировщики кода, такие как Prettier, не являются «хорошими» в современном программировании, они необходимость.
Мораль красивой басни: ключевой вывод
Конечно, это немного тривиальный пример, но причину, по которой эта «легкая победа» окупается на технических собеседованиях и экранах телефонов, легко понять.
Это простая в общении история с четким началом, серединой и концом, и я рассказываю о том, как я испытал вызов и вырос на этом опыте.
Что я научился делать в следующий раз, так это быть уверенным в применении лучших практик в составе удаленной команды, потому что преимущества того стоят. Может быть, мне даже не стоило ждать до второй недели, чтобы заняться этим проектом.
Мораль этой истории заключается в том, что находит отклик у менеджеров по найму всякий раз, когда я обсуждаю свою техническую работу и профессиональный опыт.
Что вы предложите? Сообщите им, что у вас есть солидный опыт внедрения кода в производство и извлечения уроков из него.
Вот как вы пройдете свое следующее техническое собеседование.
Удачи.
Доктор. Дерек Остин — автор книги Программирование карьеры: как стать успешным программистом с шестизначным доходом за 6 месяцев, которая теперь доступна на Amazon.
