Как нужно проводить собеседования

суперсолдат, умеющих еще и проходить собеседования (как отдельный навык, совершенно параллельный навыку «работать работу»).

И такие существуют, ббуду!

У тебя противоречие....

это противоречие в HR-модели, когда кадровичка разместила на сайте вакансию, и теперь вы сидите и ждете, когда привалит толпа поциентов

можно же делать проще. Надо постоянно бухать вместе с разработчиками, ходить по конференциям всяким, и участвовать в срачах на разные темы. Особенно в закрытых срачах, когда люди наплевав на NDA рассказывают, как устроены их проекты, и как это офигенно. После этого ты просто добавляешь их к себе в фейсбук, собираешь телефоны, и когда надо - зовешь еще раз попить кофейку на более конкретную тему. Ставишь ноут, и вы вместе по фану хачите какой-нибудь кусок кода. Потом объясняешь, что за то, чем мы занимались последние четыре часа, у нас еще и денег платят. Вот и всё. В совершенно спокойной дружеской обстановке собрана информация и о бэкграунде чувака, и как он думает, и какие у него ценности, и пресловутые «кем он видит себя через 5 лет».

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

Без IDE, гугла, и привычной среды - я не знаю вообще никаких. С ними - знаю любые.

Помню в Университете мне преподавали Delphi и я вызвался сдать экзамен в первый же месяц. Пришел. Решил задачу. Меня спрашивают какие есть методы у TList? Я пишу TList и жму Ctrl+F1 и читаю с экрана. Преподша выслушала. Задала еще 5 вопросов на которые я ей ответил с F1. Тогда она сказала «Не понимаю почему вы не хотите быть программистом» (а у меня уже стаж был программиста 6 лет, а делфи я с 95 года еще знал. Причем начинал на Win 3.11)

любой вменяемый человек с гуглом может выучить любое API за считаные часы.

Не любое. Погляди на API Amazon. Там для начала вообще понять что такое AWS и ES3. И для тех кто работал с файлами что такое букет....

Это реально только в Москве Нижнем и Питере. Ну есть сейчас еще студентота, но какие у них проекты?

с другой стороны, есть вопросы, на которые можно и нужно отвечать интуитивно. Например, вот ты писал веб-приложение, и там нажатия всех кнопочек обрабатываются по HTTP прямыми вызовами (совершенно похрену, помнит ли поциент каким конкретным API) - а не проще ли заменить это HTTP-концентратором с очередью (например ActiveMQ, но не особо важно), пусть каждый клик кнопочки ложится в очередь. Или например, есть у нас несколько очередей, и мы хотим сделать очередь очередей, чтобы она сливала очередь в очередь - какие продукты вы будете использовать, и когда (на вскидку) они сдохнут под нагрузкой? Ну и КОНЕЧНО человек не сможет просто так взять и привести конкретные баги в ActiveMQ, но сможет по опыту сказать что оно падало там-то и там-то, а ZeroMQ падало примерно там-то, поэтому наверное вот на таких задачах лучше Zero, а на вот таких - Active. И КОНЕЧНО он не сможет вспомнить детали API каждой из этих очередей, что он - задрот что ли помнить это говно наизусть

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

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

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

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

Сотрудника, которого все устраивает — не переманить. А если он ушел - значит, его что-то не устраивало и виноват не он.

для кровавого энтерпрайза тестовые - это нецелесообразно на мой взгляд.

это просто прекрасно, особенно когда человек берется сделать и сливается потому что «нишмагла», хотя «потрындеть» у него отлично получилось.

на js? что просишь сделать?

В рабочее время читать - неэтично как минимум

чеита?

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

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

В рабочее время читать - неэтично как минимум

чеита?

Руководство расчитывает что программист работает над выданными задачами и что их сдадут в срок. А чтение книг этому помешает.

Руководство расчитывает что программист работает над выданными задачами и что их сдадут в срок. А чтение книг этому помешает.

То есть читать stackoverflow для решения задачи - можно, а книгу - не можно? Я заказываю 3-4 раза в год книги для своей команды, в свободное от задач время ребята читают книги. Нельзя форсировать программиста кодить 8 часов в день, ничего толкового из этого не выйдет.

То есть читать stackoverflow для решения задачи - можно, а книгу - не можно?

Есть разница. Подсмотреть библиотечную функцию в или алгоритм - пожалуйста - если это быстро. И неважно из какого источника.

А если нужно с нуля освоить новую технологию или провести исследование - сделать нечто долгое - то это, по-моему, основание заводить отдельную задачу.

Впрочем, я имел ввиду другое :) Представьте что команда пишет на Python, и только на нём. А некий член команды на протяжении всего рабочего дня читает учебник по Java. И так продолжается несколько дней. Очевидно, что это действие пользы проекту не приносит :)

Я заказываю 3-4 раза в год книги для своей команды, в свободное от задач время ребята читают книги.

Я за 10 месяцев купил около 30 книг, из них 6 по компьютерам. Половину уже прочёл. И я только за повышение квалификации :)

Нельзя форсировать программиста кодить 8 часов в день, ничего толкового из этого не выйдет.

Форсировать - нет. Лучше вдохновить работать по 10 часов, оставаться после ухода начальства, думать о работе даже ночью. Эффективнее. Так винтики будут пахать и рассказывать как круто они это делают.

Говорят, больше 4 часов выдавать продуманный код человек не может. Наверное, соглашусь. Остальное время можно потратить на обсуждения, написание документации, тестов, проектирование (!).

Сам я не погромист, но ИМХО самое простое дать домой задание накодить какую-нить хрень, а потом обсудить почему он написал именно так и тд

Конкретно сейчас - https://github.com/nodeca/argparse/issues/112 проработать задачу и написать более подробную бумажку.

Проверяется насколько хорошо человек умеет систематизировать информацию и формулировать мысли.

Честно говоря, не осилят оба. Правда, «теоретик», с горем попалам, убив 10-к дедлайнов, получит таки результат. А «практик» напишет быстро, но так, что не зная про бакеты, эта его HashMap будет работать медленнее тупого std::find по вектору и спрашивается, зачем оно такое надо.

Честно говоря, не осилят оба. Правда, «теоретик», с горем попалам, убив 10-к дедлайнов, получит таки результат. А «практик» напишет быстро, но так, что не зная про бакеты, эта его HashMap будет работать медленнее тупого std::find по вектору и спрашивается, зачем оно такое надо.

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

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

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

Согласен. Но на собеседовании?! Надо же посмотреть в каких условиях будет работать новая эм... функция, посмотреть какие алгоритмы для этого бывают, сравнить, а потом - писать. На листочке за 20 минут что-то серьёзное сделать невозможно.

Ну даже если кандидат в свободное время увлекается оптимизацией, алгоритмами и типами данных - кто сказал что рутину (коей 90%) он будет делать так же хорошо?

Тестовые задания более чем на 15 минут вообще - зло. Чтобы отсеять совсем дубов этого достаточно. А ПО, которое потребует по делу применять шаблоны проектирования, глубокие знания стандартных библиотек, и т.д. и т.п. за 3 часа с 0-я не написать.

Как чувак который побывал по обе стороны, могу сказать:

1. Тестовые задания это нормально если они занимают адеватное количество времени и они интересные.

2. На собеседованиях нужно спрашивать: «Как это работает». Обычно адекватные кандидаты интересуются такими вопросами.

3. Вопросы и теоритические рассуждения в духе «Как можно построить такую архитектуру?», обычно бесполезны.

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

Второе. Потому что правильный.

Могу предложить прочесть эту статью.

Комментарии читать тоже - интереснее даже самой статьи.

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