Yvision.kz
kk
Разное
Разное
399 773 постов41 подписчиков
Всяко-разно
5
06:19, 04 января 2014

ТОП-10 ошибок на технических собеседованиях на должность программиста

Blog post image

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

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

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

Сегодня я хотел написать о ТОП-10 ошибках, которые делают кандидаты на собеседовании:

1) Готовиться к собеседованию на компьютере

Когда кандидат приходит к нам на собеседование, единственное, что он получает это ручку с бумагой, иногда конечно даем маркер и доску(как premium option). Так вот часто кандидаты делают очень много ошибок, потому что они привыкли к подсветке кода, autocomplete, и др.вещам. Готовитесь к собеседованию, делайте это с помощью бумаги и ручки, используйте компилятор только для проверки того, что вы написали на бумаге. Удивитесь как много вы ошибок сделали

2) Не готовиться к поведенческим вопросам

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

3) Не проводить тестовые собеседования

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

4) Пытаться запомнить ответы

Запомнил как работает бинарный поиск по дереву отлично. Думаешь, что это спасет тебя? До поры, до времени, если дадут немного модифицированную версию бинарного поиска - все пиши пропало. Думаю это понятно

5) Решать задачи на собеседовании в гробовой тишине

Когда я делаю собеседование, я хочу услышать нЕ правильный ответ от кандидата, а то как он думает, для меня важнее всего понять его мотивы такого мышления, почему он решил использовать Insertion Sort, а не Quicksort? Возможно он не знает Quicksort(или плохо его помнит)? Ни я ни кто либо другой не умеют читать ваши мысли к сожалению, проговаривайте что вы делаете, спрашивайте если не знаете как подойти к задаче.
Очень часто чтобы решить задачу нужно спрашивать детали.

Пример:

Интерьювер: Как отсортировать массив данных?
Кандидат: Какие данные в массиве?
И: Числа
К: Целочисленные?
И: Да
К: Что это за числа?
И: Класс в котором учится ученик
К: Хорошо, как много этих данных? (Значит минимум 0, а макс 13)
И: Миллиард

Отсюда можно сделать вывод, что хорошим алгоритмом сортировки будет Counting sort

6) Спешка

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

7) "Говнокод"

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

Пример: Напишите алгоритм решения крестиков-ноликов
Плохо: Сделать решение для случая когда сетка 3x3 и написать все в один метод
Хорошо: Сделать решение для случая когда сетка NxN, создать структуру данных для объекта(для Х и О - 1 объект к примеру) - и создавать лист из этих объектов, разделить на задачу на методы

8) Не тестировать код

Я не прошу писать unit тестирования, но перед тем как сказать интервьюверу, что все готово, удостоверьтесь, что код работает. Проверьте для случаев экстремумов(Что будет если алгоритм получит мин.значение как input, а если макс.значени? 0? null?). Выдает ли программа exception'ы?

9) Исправлять ошибки на бум

Баги - это нормально. Но исправить их вовремя и правильно это самое главное. Иногда бывает такое, что кандидаты видят, что их функция возвращает не правильное значение для input'а 0 и делают так:

// Bad idea
if(input == 0)
return SOME_TRUE_VALUE_HERE;

Смешно не правда ли :)? Не делайте так

10) Сдаваться

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

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

Отвечу на все ваши вопросы, по данной теме
Удачи на собеседованиях,
Асхат

P.S. Мы ищем разработчиков к себе, если вы думаете что вы талантливы, напишите мне askhat@chocomart.kz

Источники

http://www.technologywoman.com/

https://www.kennethnorton.com/

http://www.cc2e.com/Default.aspx

 
5