«Искать баги и улучшать код — работа тестировщиков». 7 вещей, которые разработчикам не стоит говорить на собеседовании

2 декабря 2018, 12:09
«Искать баги и улучшать код — работа тестировщиков».

Все понимают, как важно произвести хорошее впечатление на интервьюера. Но некоторые фразы могут сильно понизить шансы разработчика получить заветную должность. Dice Insights приводит 7 примеров, когда лучше подумать дважды перед тем, как дать ответ.

«Мне не нравится язык Х / фреймворк Y»

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

«В моей предыдущей компании качество никого не заботило. Только я понимал, что баги нужно исправлять»

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

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

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

«Единственный верный способ решить эту задачу — HashMap. Через HashMap можно сделать всё, что угодно»

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

«Я хотел бы работать над этим проектом, а потом — возглавить следующий проект»

Для интервьюера это как красная тряпка для быка, если разработчик слишком забегает вперёд с проектами или должностями. Хотя целеустремлённость обычно приветствуется, нанимателю нужно заполнить вполне определённую вакансию, а не ту, что разработчик мечтает получить через несколько лет. Поэтому последнему лучше сосредоточиться на том, как он может использовать имеющуюся возможность и решить текущую проблему компании.

«Если прикинуть, расстояние между этими элементами примерно…»

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

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

«Я не занимаюсь тестированием. Искать баги и улучшать код — работа тестировщиков»

Фразы типа «это не моя работа» почти гарантированно будут стоить соискателю вакансии. В разработке программного обеспечения за качество кода отвечают все до единого.

«Я не знаю»

Нельзя отвечать «Я не знаю», если тут же не добавлять «но я узнаю!» Разработчик прежде всего решает задачи, и поэтому должен проявлять любознательность, навыки решения задач и способность логически мыслить.

Обсуждение