[Управление персоналом, Карьера в IT-индустрии] Аарон Шварц: Как я нанимаю программистов (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Об Авторе: Аарон Шварц — американский интернет-активист, программист, писатель, хактивист. Умер за свободу информации.
- В 12 лет создал сайт Info, где каждый мог писать о том, что знает (а другие могли дополнять и комментировать). Это был предвестник Википедии.
- В 14 лет Шварц стал соавтором спецификации RSS 1.0.
- Аарон Шварц работал под руководством Тима Бернерса-Ли в составе основной рабочей группы RDF в Консорциуме W3C.
- Попал на первую программу в Y Combinator со стартапом Infogami, который впоследствии слился с популярным сайтом Reddit.
- Работал над Open Library и Creative Commons
- Внес существенный вклад в Markdown.
Пост 2009 года
Когда вы нанимаете программиста (да и вообще кого-либо, если уж на то пошло), перед вами стоят три вопроса. Умный ли он? Способен ли выполнить то, что нужно? Сможете ли вы с ним работать? Тот, кто умён, но неспособен выполнить задание, может быть вашим другом, но не работником. Вы можете обсуждать с ним свои проблемы, тогда как он будет тянуть с выполнением важной работы. Тот, кто способен выполнять задания, но неумён — тот неэффективен: неумные люди выполняют работу трудоёмким способом, работа с ними продвигается медленно и полна разочарований. Ну а с тем, с кем вы не можете работать, вы просто не сможете работать.
Обычная процедура найма программиста состоит из: а) чтения резюме, б) задавания каких-то трудных вопросов по телефону и в) постановки перед ними задачи по программированию при личном общении. Я думаю, что такая система найма людей ужасна. Из резюме можно узнать очень мало, а трудные вопросы во время интервью очень нервируют людей. Программирование — это не та работа, которая выполняется под давлением, поэтому наблюдать за действиями людей, которые нервничают, довольно бессмысленно. А вопросы для интервью обычно подбираются по принципу «чем тяжёлее, тем лучше». Думаю, я сносный программист, но я никогда не проходил такие интервью, и сомневаюсь, что вообще смог бы это сделать.
Поэтому, когда я нанимаю кого-то, я просто пытаюсь ответить на три вопроса, описанные выше. Чтобы выяснить, способен ли человек делать нужные вещи, я просто спрашиваю, что он уже сделал. Если человек действительно способен выполнять работу, к этому моменту он уже должен был что-то сделать. Трудно быть хорошим программистом без какого-то опыта работы, а сейчас любой может набраться опыта, приняв участие в каком-то проекте по созданию бесплатной программы. Поэтому я просто прошу у человека пример кода и работающую программу и смотрю, хорошо ли это выглядит. Так действительно можно узнать очень много, потому что ты не наблюдаешь за тем, как он отвечает на надуманный вопрос во время интервью — ты смотришь на код, который он выдаёт на самом деле. Является ли он лаконичным? понятным? элегантным? практичным? Хотели бы вы иметь что-то такое в своём проекте?
Чтобы выяснить, является ли человек умным, я просто веду с ним неформальную беседу. Я стараюсь сделать всё, чтобы снять любое напряжение — назначаю встречу в кафе, поясняю, что это не интервью, делаю всё, чтобы быть неофициальным и дружественным. Ни при каких обстоятельствах я не задаю ему стандартных вопросов из интервью — я просто болтаю с ним, как болтал бы с кем-то на вечеринке. (Если на вечеринках вы просите людей назвать их сильные и слабые стороны или вычислить количество настройщиков фортепьяно в Чикаго — у вас большие проблемы.) Думаю, в непринуждённой беседе довольно легко выяснить, умён ли человек. Я постоянно оцениваю ум людей, которых встречаю, точно так же, как постоянно оцениваю их привлекательность.
Но если бы пришлось записать признаки того, почему некто кажется мне умным, я бы сделал акцент на трёх моментах. Во-первых, насколько глубоки его познания? Спросите, о чём он думал в последнее время, и «прощупайте» его на эту тему. Похоже ли на то, что у него есть детальное понимание предмета? Может ли он понятно объяснить его? (Понятные объяснения — признак подлинного понимания.) Знает ли он о предмете то, чего не знаете вы?
Во-вторых, любопытен ли он? Задаёт ли он в ответ вопросы о вас? Действительно ли он заинтересован или просто старается быть вежливым? Задаёт ли он дополнительные вопросы к тому, что вы говорите? Заставляют ли его вопросы вас задуматься?
В-третьих, учится ли он? В какой-то момент разговора вы, возможно, будете что-то ему объяснять. Действительно ли он понимает, что вы говорите, или же просто улыбается и кивает? Существуют люди, которые обладают знаниями в какой-то небольшой области, но не интересуются другими вопросами. И существуют люди, которые любопытны, но не учатся, они задают множество вопросов, но на самом деле не слушают. Вам нужен тот, кто является и тем, и другим, и третьим.
Наконец, я определяю, смогу ли я работать с человеком, просто проведя с ним какое-то время. Многие выдающиеся люди кажутся восхитительными в первый час общения, но через пару часов их эксцентричность начинает раздражать. Поэтому когда вы закончите непринуждённую беседу, пригласите его на обед с остальными членами команды или на игру в офисе. Опять же старайтесь, чтобы всё было как можно более неформальным. Цель — просто понять, будет ли он действовать вам на нервы.
Если всё выглядит неплохо, и я готов нанять человека, здравый смысл говорит о необходимости последней проверки, чтобы убедиться, что меня каким-то образом не надули: я прошу его сделать часть работы. Обычно это означает, что ему следует написать какой-то более-менее независимый кусок кода, который нам нужен. (Если вам в самом деле так уж хочется увидеть, как он работает в напряжённых условиях, установите ему срок.) Если необходимо, можете предложить ему оплатить эту работу — хотя я заметил, что большинство программистов не прочь выполнить небольшую задачу, если потом они смогут сделать полученные исходники открытыми. Этот тест не работает сам по себе, но если кто-то прошёл первые три испытания, его должно быть достаточно, чтобы доказать, что человек не надул вас, что он в самом деле может выполнять работу.
(Я встречал людей, которые говорят: «Ну, ладно, давай мы попробуем тебя нанять на месяц и посмотрим, как оно пойдёт». Не похоже, чтобы это работало. Если вы не можете принять решение по окончании работы над небольшим проектом, вы не сможете сделать этого и через месяц, так что выходит, что вы нанимаете человека, который недостаточно хорош. Лучше просто сказать «нет» и поискать кого-то получше.)
Меня вполне устраивает такой метод. Когда я придерживался его лишь частично, это заканчивалось приёмом на работу неподходящих людей, которым со временем приходилось уйти. Но когда я действовал по этому плану, то получал людей, которые настолько мне нравились, что я на самом деле очень сожалею, если мне приходится расставаться с ними. Удивительно, как много компаний вместо этого пользуются другими, глупыми методами найма на работу.
Перевод: «Вебпланета»
===========
Источник:
habr.com
===========
===========
Автор оригинала: Aaron Swartz
===========Похожие новости:
- [Управление персоналом, Законодательство в IT, Карьера в IT-индустрии, Удалённая работа] Почему из Колорадо теперь нельзя устроиться на удаленку
- [Программирование, Карьера в IT-индустрии, История IT] Последние четверть века развития в программировании нет
- [Поисковые технологии, Машинное обучение, Развитие стартапа, Карьера в IT-индустрии, Поисковая оптимизация] Как мы запустили агрегатор удаленных вакансий и зачем в нем ML
- [IT-эмиграция, Карьера в IT-индустрии, Урбанизм] [Личный опыт] Как живётся разработчику в Венгрии: стипендии для иностранцев, IT и вино
- [Data Mining, Big Data, Машинное обучение, Карьера в IT-индустрии] Все что вы (не) хотели знать о Data Science
- [Анализ и проектирование систем, Проектирование и рефакторинг, Управление разработкой, Карьера в IT-индустрии] Кто вы, мистер архитектор?
- [Разработка веб-сайтов, Учебный процесс в IT, Карьера в IT-индустрии, TypeScript] По другую сторону: как фронтендер стал софтверным инженером
- [Управление проектами, Управление персоналом] Фактор демотивации №1: “Отсутствие стратегии в головах сотрудников”
- [Управление разработкой, Управление персоналом, Конференции] Митап «Инженер заходит в бар»: Dev-to-Teamlead
- [Управление персоналом, Офисы IT-компаний, Будущее здесь, Удалённая работа] Свежий воздух, «гибридная» модель и отпуск для вакцинированных. Как компании готовятся к выходу в офис после пандемии
Теги для поиска: #_upravlenie_personalom (Управление персоналом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_najm (найм), #_upravlenie_personalom (
Управление персоналом
), #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:46
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Об Авторе: Аарон Шварц — американский интернет-активист, программист, писатель, хактивист. Умер за свободу информации.
Пост 2009 года Когда вы нанимаете программиста (да и вообще кого-либо, если уж на то пошло), перед вами стоят три вопроса. Умный ли он? Способен ли выполнить то, что нужно? Сможете ли вы с ним работать? Тот, кто умён, но неспособен выполнить задание, может быть вашим другом, но не работником. Вы можете обсуждать с ним свои проблемы, тогда как он будет тянуть с выполнением важной работы. Тот, кто способен выполнять задания, но неумён — тот неэффективен: неумные люди выполняют работу трудоёмким способом, работа с ними продвигается медленно и полна разочарований. Ну а с тем, с кем вы не можете работать, вы просто не сможете работать. Обычная процедура найма программиста состоит из: а) чтения резюме, б) задавания каких-то трудных вопросов по телефону и в) постановки перед ними задачи по программированию при личном общении. Я думаю, что такая система найма людей ужасна. Из резюме можно узнать очень мало, а трудные вопросы во время интервью очень нервируют людей. Программирование — это не та работа, которая выполняется под давлением, поэтому наблюдать за действиями людей, которые нервничают, довольно бессмысленно. А вопросы для интервью обычно подбираются по принципу «чем тяжёлее, тем лучше». Думаю, я сносный программист, но я никогда не проходил такие интервью, и сомневаюсь, что вообще смог бы это сделать. Поэтому, когда я нанимаю кого-то, я просто пытаюсь ответить на три вопроса, описанные выше. Чтобы выяснить, способен ли человек делать нужные вещи, я просто спрашиваю, что он уже сделал. Если человек действительно способен выполнять работу, к этому моменту он уже должен был что-то сделать. Трудно быть хорошим программистом без какого-то опыта работы, а сейчас любой может набраться опыта, приняв участие в каком-то проекте по созданию бесплатной программы. Поэтому я просто прошу у человека пример кода и работающую программу и смотрю, хорошо ли это выглядит. Так действительно можно узнать очень много, потому что ты не наблюдаешь за тем, как он отвечает на надуманный вопрос во время интервью — ты смотришь на код, который он выдаёт на самом деле. Является ли он лаконичным? понятным? элегантным? практичным? Хотели бы вы иметь что-то такое в своём проекте? Чтобы выяснить, является ли человек умным, я просто веду с ним неформальную беседу. Я стараюсь сделать всё, чтобы снять любое напряжение — назначаю встречу в кафе, поясняю, что это не интервью, делаю всё, чтобы быть неофициальным и дружественным. Ни при каких обстоятельствах я не задаю ему стандартных вопросов из интервью — я просто болтаю с ним, как болтал бы с кем-то на вечеринке. (Если на вечеринках вы просите людей назвать их сильные и слабые стороны или вычислить количество настройщиков фортепьяно в Чикаго — у вас большие проблемы.) Думаю, в непринуждённой беседе довольно легко выяснить, умён ли человек. Я постоянно оцениваю ум людей, которых встречаю, точно так же, как постоянно оцениваю их привлекательность. Но если бы пришлось записать признаки того, почему некто кажется мне умным, я бы сделал акцент на трёх моментах. Во-первых, насколько глубоки его познания? Спросите, о чём он думал в последнее время, и «прощупайте» его на эту тему. Похоже ли на то, что у него есть детальное понимание предмета? Может ли он понятно объяснить его? (Понятные объяснения — признак подлинного понимания.) Знает ли он о предмете то, чего не знаете вы? Во-вторых, любопытен ли он? Задаёт ли он в ответ вопросы о вас? Действительно ли он заинтересован или просто старается быть вежливым? Задаёт ли он дополнительные вопросы к тому, что вы говорите? Заставляют ли его вопросы вас задуматься? В-третьих, учится ли он? В какой-то момент разговора вы, возможно, будете что-то ему объяснять. Действительно ли он понимает, что вы говорите, или же просто улыбается и кивает? Существуют люди, которые обладают знаниями в какой-то небольшой области, но не интересуются другими вопросами. И существуют люди, которые любопытны, но не учатся, они задают множество вопросов, но на самом деле не слушают. Вам нужен тот, кто является и тем, и другим, и третьим. Наконец, я определяю, смогу ли я работать с человеком, просто проведя с ним какое-то время. Многие выдающиеся люди кажутся восхитительными в первый час общения, но через пару часов их эксцентричность начинает раздражать. Поэтому когда вы закончите непринуждённую беседу, пригласите его на обед с остальными членами команды или на игру в офисе. Опять же старайтесь, чтобы всё было как можно более неформальным. Цель — просто понять, будет ли он действовать вам на нервы. Если всё выглядит неплохо, и я готов нанять человека, здравый смысл говорит о необходимости последней проверки, чтобы убедиться, что меня каким-то образом не надули: я прошу его сделать часть работы. Обычно это означает, что ему следует написать какой-то более-менее независимый кусок кода, который нам нужен. (Если вам в самом деле так уж хочется увидеть, как он работает в напряжённых условиях, установите ему срок.) Если необходимо, можете предложить ему оплатить эту работу — хотя я заметил, что большинство программистов не прочь выполнить небольшую задачу, если потом они смогут сделать полученные исходники открытыми. Этот тест не работает сам по себе, но если кто-то прошёл первые три испытания, его должно быть достаточно, чтобы доказать, что человек не надул вас, что он в самом деле может выполнять работу. (Я встречал людей, которые говорят: «Ну, ладно, давай мы попробуем тебя нанять на месяц и посмотрим, как оно пойдёт». Не похоже, чтобы это работало. Если вы не можете принять решение по окончании работы над небольшим проектом, вы не сможете сделать этого и через месяц, так что выходит, что вы нанимаете человека, который недостаточно хорош. Лучше просто сказать «нет» и поискать кого-то получше.) Меня вполне устраивает такой метод. Когда я придерживался его лишь частично, это заканчивалось приёмом на работу неподходящих людей, которым со временем приходилось уйти. Но когда я действовал по этому плану, то получал людей, которые настолько мне нравились, что я на самом деле очень сожалею, если мне приходится расставаться с ними. Удивительно, как много компаний вместо этого пользуются другими, глупыми методами найма на работу. Перевод: «Вебпланета» =========== Источник: habr.com =========== =========== Автор оригинала: Aaron Swartz ===========Похожие новости:
Управление персоналом ), #_karera_v_itindustrii ( Карьера в IT-индустрии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:46
Часовой пояс: UTC + 5