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

В настоящее время каждый может написать код, поэтому первая задача - найти людей с определенными навыками. Тот факт, что разработчики обладают определенными навыками и могут решать некоторые алгоритмы, еще не означает, что они могут создавать приложения. Если мы создаем что-то маленькое или являемся стартапом, мы можем игнорировать недостаток опыта, но если мы создаем корпоративное приложение, нам нужны люди с опытом, люди, которые понимают разницу в сложности, уже испытали боль технического долга и т. Д. Они должны уделять особое внимание чистому коду, понимать, почему функция, которая имеет более 15 строк кода или вложенные ifs, может вызвать проблемы в течение 1 года, понимать, что мы пишем код не для себя, а для чтения другими и для себя в будущем. и Т. Д.

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

Так что же такое старший разработчик?

Кто имеет опыт работы не менее 7 лет, почему?

  1. Поскольку ничто не может заменить опыт, вам просто нужно преодолеть боль создания и доставки приложений, чтобы понять определенные концепции.
  2. Вы должны почувствовать боль технического долга.
  3. Вы должны выдержать сроки доставки,
  4. Вы должны терпеть конфликты в своей команде.
  5. Вам нужно повзрослеть и уметь сочувствовать.
  6. Вам нужно научиться говорить «нет». Ваш менеджер или начальник приходит к вам и говорит, что он нам понадобится после завтра. Старший разработчик должен иметь возможность извиниться, но мне потребуется 2 недели, чтобы доставить его. Ваш менеджер проекта говорит, что пока пропустите тесты и качество, и старший разработчик должен иметь возможность донести это до того, что мы не делаем сокращений в отношении качества, потому что оно всегда будет давать отпор, и мы не выиграем ни разу, идя на компромисс в отношении качества.

Глубина знаний

Есть несколько способов разделить разработчиков

  1. Младший разработчик - это тот, кто нуждается в надзоре, постоянном контроле и руководстве. Это может быть человек, который только начинает свою карьеру, кто-то, кто разбирается в вещах, но не обязательно знает, как это делать, или это может быть разработчик Ninja, который думает, что знает все лучше всех, и если вы позволите Он как бы то ни было, он начинает писать свою собственную ОС или язык программирования только для того, чтобы создать HTML-форму.
  2. Разработчик среднего уровня - имеет некоторый опыт, знает, как что-то делать, но все еще не знает, зачем это делать.
  3. Старший разработчик - знает, зачем что-то делать, обладает более широкими знаниями технологий, имеет опыт работы с несколькими языками программирования, знает о сборках и конвейерах, CI / CD, имеет представление о шаблонах проектирования и архитектуре программного обеспечения.

Итак, старший разработчик знает, зачем что-то делать, это означает, что он глубоко разбирается в React и JavaScript. Он понимает, что происходит за сценой, понимает движок, этап компиляции, то, как DOM работает в браузере, он понимает причины решений, принятых командой Facebook, понимает, почему так важно надежное тестовое покрытие и так далее.

Работа в команде

С группой старших разработчиков споры о личных предпочтениях и мнениях - это бесконечная борьба. Старший разработчик должен уметь подавлять свое эго на благо команды. Старший разработчик должен уметь излагать свое мнение, не оскорбляя и не вызывая у других неудобств. Поскольку у него есть глубокое понимание, он может спорить, почему, а не просто сказать, потому что я так думаю или потому, что так сказал знаменитый парень. Старшие разработчики должны уметь думать наперед, понимать слабые стороны своей команды и наверстывать упущенное. Например, если я знаю, что у нас будет куча младших разработчиков в команде, у нас будут гораздо более строгие рекомендации по качеству, и мы будем избегать слишком абстрактного кода, даже если это немного ограничит нас. Мы можем использовать нехватку навыков у младших разработчиков для улучшения нашей работы, просто планируя соответствующим образом. Иногда люди просто дают какое-то несущественное задание младшему, чтобы его не беспокоили, но у старшего разработчика много скучной работы, которую ему нужно сделать, поэтому, если он потратит некоторое время на преподавание, он сможет извлечь выгоду даже из человека с недостатком знаний и опыта и помогите ему расти.

Вопросы на собеседовании

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

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

Я предпочитаю начать со следующего вопроса:

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

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

Что такое шаблоны проектирования? Какой ваш любимый шаблон дизайна? Как бы вы объяснили шаблон проектирования адаптера?

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

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

DRY, SRP, KISS, YAGNI, разделение проблем или твердые принципы

Неплохо было бы поговорить об этих основных принципах, чтобы узнать, что думает кандидат. Понимает ли он важность этих принципов. Здесь мы можем проверить, насколько важен для кандидата чистый код и его преимущества для будущего приложения.

Какой язык программирования - JavaScript?

Здесь мы ищем две вещи: тот факт, что JS является компилируемым языком, и то, как эта компиляция работает, и мы также ищем понимание части JavaScript, ООП, а также тот факт, что он полностью поддерживает функциональное программирование.

Функциональное программирование, что это такое и почему оно важно?

Поскольку мы нанимаем разработчика React и React является функциональной библиотекой, кандидату важно иметь какое-то представление о ней. Мы не ищем только поверхностных знаний о том, что такое чистая функция, мы ищем понимание принципов и того, что дает этот подход. Почему ребята из Facebook решили пойти по этому пути и т. Д.

Объясните, почему в JavaScript есть подъемник.

Здесь мы не ищем, как выглядит подъем, но почему в языке программирования вообще существует подъем, мы ищем занижение фазы лексирования во время компиляции. Это не то, что обязательно должен знать каждый разработчик, но это хороший способ проверить мыслительный процесс, а также посмотреть, как разработчики реагируют, если они чего-то не знают. Если они просто признают это, как должны, или попытаются отговориться от этого: D

В чем разница между объявлениями функций и стрелочными функциями

Это тесно связано с вопросом подъема, и мы ищем понимание разницы между контекстом выполнения и лексическим контекстом.

Объясните, как асинхронный код работает за кулисами

Здесь мы направляем кандидата к циклу событий и движку JavaScript.

Объясните виртуальный DOM и алгоритм согласования

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

Новые функции в последней версии React

Быть разработчиком программного обеспечения - это постоянно учиться, очень важно быть в курсе и быть вовлеченным

Какая, по вашему мнению, хорошая архитектура для интерфейсного приложения предприятия?

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

Как бы вы подошли к этому примеру проверки кода?

У нас есть PR, открытый с функцией, которая имеет несколько вложенных if. Один из наших товарищей по команде говорит, что вложенные if - это запах кода, и мы должны реорганизовать эту функцию. Другой товарищ по команде говорит, что эта функция небольшая и сфокусированная, поэтому не имеет значения, есть ли у нас пара вложенных if, и удобочитаемость не так уж плоха.

Это рассматривает несколько аспектов, сначала мы проверяем понимание важности чистого кода. Принцип разбитого окна, лягушка в колодце или, как говорил мой свекор, 1 евро умноженный на 10 000 - это 10 000 евро. Если кандидат понимает, что даже если в рамках этой небольшой функции вложенные if действительно не имеют значения, в более широком плане очень важно сохранять код в чистоте, потому что беспорядок будет только расти. другие последуют за ним, рефакторинг просто приклеит к нему какой-то другой беспорядок, и мы выработали привычку не писать чистый код в первую очередь. Эффект бабочки после одного года для небольших ошибок в коде огромен, и каждый, у кого есть опыт, это понимает.

Вы комментируете свой код? Почему это запах кода?

В этом вопросе мы ищем немного провокации, мы хотим немного взволновать кандидата и втянуть его в небольшой спор, чтобы посмотреть, как он отреагирует. Комментарии к коду OFC - это неспособность выразить себя с помощью кода, разработчики понимают, как работает код, и если фрагмент кода имеет настолько высокую сложность, что нам нужно объяснять его в комментариях, он требует рефакторинга. Также требования к функциям должны быть сохранены в документации, обновляемой нашим BA, и так далее, но независимо от того, что говорит кандидат, мы должны попытаться немного его подтолкнуть :). Мы оставляем этот вопрос последним, потому что мы не хотим, чтобы наш кандидат нервничал с самого начала, есть всего несколько человек, которые могут провести собеседование, когда они встревожены или взволнованы.

Надеюсь, это послужит руководством для людей, которые проводят собеседования и ищут вдохновения, и, возможно, это также может дать кандидатам хорошее представление о том, к чему им следует готовиться. Более конкретные технические вопросы вы можете найти в другой моей статье: https://blog.usejournal.com/react-interview-questions-13f8839f2711