29 вопросов для собеседования с инженером-программистом (с примерами ответов)

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

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

Общие вопросы для собеседования с инженером-программистом

При подготовке к собеседованию по программной инженерии может быть полезно просмотреть примеры ответов на некоторые наиболее часто задаваемые вопросы, например:

• С какими языками программирования вы знакомы?

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

• Что вы думаете о декларативном языке в сравнении с. императивные парадигмы, такие как функциональное и объектно-ориентированное программирование?

• Какие паттерны проектирования вы используете чаще всего и в каких контекстах вы их применяете??

• Что такое Agile разработка программного обеспечения и каковы ваши мысли по этому поводу?

• Что вы думаете о тестировании программного обеспечения?

• Опишите сложную ошибку, которую вам было поручено исправить в большом приложении. Как вы отлаживали проблему?

• Как вы объясняете технические проблемы заинтересованным лицам, не обладающим техническими знаниями и опытом?

• Какой аспект нашей компании, продукта или команды интересует вас больше всего?

• Как вы определяете успех проекта?

С какими языками программирования вы знакомы?

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

Пример: Я хорошо владею Java, C++, JavaScript, C#, Ruby и Python . Из этих языков программирования я чувствую себя наиболее комфортно, работая с Java, C# и C++. В своей предыдущей должности я работал в основном с Java для создания приложений, которые работали на разных платформах. Я также использовал C++ для разработки новой операционной системы, которая работала с приложениями, которые я проектировал. Используя C#, я смог повысить свою производительность при разработке веб-приложений и программного обеспечения.

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

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

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

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

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

Что вы думаете о декларативном программировании?. императивные парадигмы, такие как функциональное и объектно-ориентированное программирование?

Парадигма программирования - это широкая классификация языков на декларативные и императивные. Тем не менее, полезно рассматривать эти общие стили программирования, а не конкретные директивы языка. Хотя некоторые подходы могут быть громоздкими, есть много подходов, которые не такие жесткие. Такие языки, как JavaScript и Java, позволяют использовать любой из этих подходов, даже если они больше склоняются к одному подходу, чем к другому.

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

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

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

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

Какие паттерны проектирования вы используете чаще всего и в каких контекстах вы их применяете??

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

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

Что такое Agile разработка программного обеспечения и каковы ваши мысли по этому поводу?

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

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

• Что сработало в процессе?

• Что не получилось?

• Отклонялась ли ваша команда от рекомендаций?

• Пошло ли это вам на пользу или во вред??

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

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

Каковы ваши мысли о тестировании программного обеспечения?

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

На самом деле, этот вопрос даже обсуждается среди авторов Манифеста гибкой разработки программного обеспечения , который, возможно, популяризировал тестирование как стандартную часть процесса разработки программного обеспечения. В докладе 2015 года Agile мертв соавтор Прагматика Дэйв Томас заявил: Я в основном не тестирую. Это резко контрастирует с другими соавторами, такими как Мартин Фаулер и Кент Бек, которые в основном выступают за подход, основанный на тестировании.

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

Пример: Тестирование жизненно важно для производства высококачественного программного обеспечения для наших пользователей. Однако в новом проекте я, как правило, не использую их. Я рассматриваю тесты как инструмент для фиксации зрелой функциональности. Часто концепция проекта сильно отличается от конечного продукта, когда мы начинаем собирать показатели использования и отзывы. По этой причине я начну с простого ручного тестирования. Когда набор функций стабилизируется, я начну проводить тесты. Большую часть моего набора тестов будут составлять модульные тесты, направленные на ключевые области приложения.

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

Опишите сложную ошибку, которую вам было поручено исправить в большом приложении. Как вы отладили проблему?

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

Пример: Я получил отчет об ошибке от нашей команды DevOps о том, что одна из наших баз данных испытывает стресс из-за чрезмерного вызова дорогостоящего запроса из пользовательского интерфейса. Сначала я проверил журналы, чтобы выяснить, когда начались проблемы. Это дало мне примерный диапазон коммитов, в которых была введена ошибка. Я смог воспроизвести ошибку на последней части кода, но только в продакшене. Я выполнил git bisect, чтобы изолировать конкретный коммит, в котором была обнаружена ошибка, и удалил ветку. Однако я не смог воспроизвести проблему. Я перешел к пользовательскому интерфейсу для отладки с помощью инструментов браузера devtools. Карты исходного кода недоступны в нашей производственной среде, поэтому мне пришлось сопоставить минифицированный код JavaScript с исходным кодом CoffeeScript.

Я смог определить, что метод-нарушитель вызывается на каждой странице, а не изредка вызывается из менее используемой специфической функции. Вернувшись к коммиту, который я определил ранее, я не обнаружил изменений в ссылке на метод. Единственным примерным изменением, которое я смог найти, была несвязанная корректировка строки в файле, ссылка на которую была закомментирована около трех лет назад. Я решил развернуть несколько отчетливых протоколов регистрации, чтобы убедиться, что я правильно определил метод. Мое протоколирование подтвердило связь. После нескольких дополнительных раундов протоколирования я смог выявить досадную ошибку в CoffeeScript, когда код, который был закомментирован много лет назад, был включен в минифицированный производственный код из-за выравнивания этого твика и другой части кода от другого разработчика, которая была слита в master за несколько минут до этого.

Как вы объясняете технические проблемы заинтересованным сторонам, которые не обладают техническими знаниями или опытом?

Предприятия создают команды разработчиков программного обеспечения для решения проблем реальных людей. Будучи глубоко погруженным в разработку, легко забыть об этом. Хотя некоторые инженеры, возможно, хотели бы получить требования к программному обеспечению и работать над проектом непрерывно, пока он не будет готов , важно помнить, что заинтересованные стороны в нетехнических отделах - например, отдел по работе с клиентами и маркетинг - должны планировать разработку. Непредвиденные препятствия часто проявляются в той или иной форме, требуя разговора о том, как лучше решить проблему. Работодатели хотят знать, что вы способны четко донести эти препятствия до нетехнических заинтересованных сторон, гарантируя, что все стороны будут полностью информированы при принятии решений.

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

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

Какой аспект нашей компании, продукта или команды интересует вас больше всего?

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

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

Как вы определяете успех проекта?

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

Пример: Еще до начала проекта определяются показатели успеха. Я определю ключевой показатель эффективности (KPI), на который мы надеемся повлиять, и начну собирать информацию, чтобы сформулировать идеи. Эти идеи изложены в виде фальсифицируемой гипотезы. Например, Мы считаем, что сокращение этапов оформления заказа повысит конверсию продаж . Увеличение на 2% будет считаться положительным сигналом.' Это позволяет команде сосредоточиться на влиянии наших проектов на конечные результаты бизнеса.

Дополнительные вопросы для собеседования с инженером-программистом

Вот несколько дополнительных вопросов, сгруппированных по категориям, на которые вы можете потренироваться отвечать при подготовке к собеседованию:

Общие вопросы для собеседования

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

• Каковы были ваши основные обязанности на предыдущем месте работы?

• Когда вы в последний раз были в затруднительном положении?? Что могло бы предотвратить ситуацию и что изменилось, чтобы избежать ее в будущем?

• Почему мы должны нанять вас в качестве инженера-программиста в нашу команду??

• Какие ваши любимые книги по программной инженерии и почему?

• Как вы работаете самостоятельно и в команде?? Что вы предпочитаете?

• Предпочитаете ли вы стартап в компании или в более устоявшейся атмосфере? Почему?

• Каковы ваши самые сильные и слабые стороны?

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

Вопросы для интервью с инженером-программистом об опыте и биографии

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

• Опишите свой процесс завершения проекта от начала до конца.

• С какими проблемами масштабирования вам приходилось сталкиваться в прошлых проектах? Как можно было избежать этой проблемы и как вы ее решили??

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

• Опишите процесс, который ваша команда использует для завершения проектов. Что хорошо работает? Что бы вы изменили и почему?

• Какие инструменты управления проектами кажутся вам наиболее полезными в вашей роли инженера-программиста?

Вопросы для углубленного собеседования с инженером-программистом

Интервьюер может задать вопросы, которые позволят вам продемонстрировать свои знания в отношении конкретных аспектов роли, например:

• Какие ваши любимые инструменты для разработки программного обеспечения?

• Сколько вы ежедневно кодите в своей нынешней должности??

• Что отличает хорошего инженера-программиста от отличного?

• Опишите, каковы, по вашему мнению, ключевые принципы разработки программного обеспечения.

• Насколько комфортно вы чувствуете себя, просматривая код, написанный другими людьми? Какому процессу вы следуете при проверке чужого кода??

• Какие паттерны проектирования вы используете чаще всего и в каких контекстах вы их применяете?

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