Интересно, насколько хорошо или плохо давать практические задачи (за компом) на интервью — программистам.
С одной стороны, вроде положительная сторона в том, что видно, как человек умеет писать код, плюс еще видно достаточно ли он умный, чтобы полезть в интернет и найти уже готовый код. То есть можно поглядеть как он будет исполнять свои ПРЯМЫЕ обязанности.
C другой стороны, получается, что человека ставят не совсем в типичные условия. Слава богу, программистом не приходится писать код, с максимальным временем раздумывания в пол часа, на чужом компьютере и с угрозой не взятия на работу. Вот это как раз меня беспокоит в таких тестах, что можно легко срезать умных, но неторопливых или чересчур беспокойных программистов.
А что вы по этому поводу думаете? Кто-то вообще такое практикует? Как бы отнеслись, если бы на вас, кто-то попытался это применить?
О каких задачах идет речь? Одно дело задачи, предлагаемые Спольски («Напишите функцию реверсирования строки») и совсем другое, когда просят написать какую-то законченную программу (пусть и небольшую).
Небольшую программку. Скорее как реверсирование строки, но все таки чуть побольше.
Первое моё настоящее интервью, как раз было с написанием небольшой законченной программы. По времени я не уложился, за 30 минут я написал программу и потом в течении часа пытался её заставить работать, так и не смог. Как потом я выяснил, дело было в настройках среды программирования. Я предполагал, что они установлены по умолчанию, но как оказалось — это не так.
Согласен с предыдущем комментатором, на собеседовании желательно предлагать задачи как Спольски.
Согласен, одна из вещей как раз которая меня нервирует в такой ситуации
а) Настройка компа
б) Настройка среды
в) Отсутствие к закладкам (bookmarks) которые я обычно пользую
То есть за свои компом, я могут быть в несколько раз эффективнее и не долбатся об ненужные проблемы.
еще вариант — давать тоже задание, но домой. человек может и не торопиться\не пугаться и покажет какойто минимум своих навыков. можно даже спрашивать , вы можете на месте сделать или вам лучше домой. кстати те что на месет сделают поидее более ценные, так как более стресоустойчивые и активные. хотя зависит от требований конечно.
Не знаю, не люблю я домашние задания. Человек легко просит друга помочь и объяснить как оно работает. В результате нам нужно брать бы его друга, а не этого человека.
в большинстве никто не просит друга, это просто глупо. разве после первых дней работы не будет ясно что человек не сам сделал тестовое задание? и человеку заново менять работу. конечно люди стараются показать себя с хорошей стороны, но все таки показать именно «себя».
Возможно я конечно слегка утрировал.
Тем не менее, я считаю, что интервью на работу и другая подготовительная фаза не может занимать много времени. Те кто зеленые программисты и их время не ценно, может и сделаю задание, но мы не хотим нанять зеленых программистов.
Те, кто профессиональные программисты, их время достаточно дорого и требовать от них длительных действий по тому, чтобы прийти именно к вам — не самая лучшая идея.
Например, в одном месте (достаточно давно) меня попросили фактически переписать все мое резюме внутрь 8-9 страничной ихней анкеты, на что я просто послал фирму нафиг. У меня это заняло бы много времени, при том, что резюме несло бы абсолютно туже смысловую нагрузку.
Я давал такие задания на собеседованиях и именно они давали мне больше всего информации о собеседуемом.
Я сразу предупреждал, что мне важно получить не работающую программу, а алгоритм, записанный на c\c++. Ошибки и некомпилируемость — не важны. Важно понять, как и чем автор думал, когда это писал.
Лучший тест — это переворот строки. На нем отсеялись десятки претендентов. Казалось бы все просто, но нюансов — куча. Нормальный программист напишет эту функцию легко, а плохой — никогда.
Также просил последнее время написать функцию преобразования числа в строку типа itoa — тут вообще куча нюансов.
В целом могу сказать, что это очень хорошая практика — давать такие задачки. Т.к. после можно поговорить с претендентом именно об его коде, поискать вместе ошибки, пообщаться и составить более полное впечатление о нем.
То есть задачи именно скорее логические давать, на просмотр алгоритма.
Кстати, отсутствие требований к компиляции — вполне неплохая идея. Хотя, конечно на функции реверсирования строки — пожалуй, лучше чтобы компилилось.
Я предпочитаю не садить человека кодировать, а описываю типичную прикладную задачу (обычно из числа тех, что недавно решали мои разработчики, чтоб не высасывать из пальца) и предлагаю порассуждать, как бы он ее решал. Очень интересно слушать.
Некоторые сразу тухнут и не могут ничего предложить, потому что задача им не до конца ясна, или по каким то еще причинам. Такие люди как разработчики никуда не годятся, даже если прекрасно знают язык.
Другие моментально предлагают готовое решение и потом яростно его отстаивают. Часто это хорошие алгоритмисты и программисты, но работать с ними довольно трудно. Они пишут эффективный код, но готовые решения у них часто бывают никуда не годными.
Третьи изначально настроены от противного. Они всеми силами пытаются доказать себе и мне что предложенная задача не правильная и ее надо изменить. С такими тоже лучше не иметь дела.
И лишь не многие начинают уточнять условия, предлагая новые и новые решения. Таких надо брать сразу. Особенно если предлагаемые ими решения разумны 🙂
Кстати, так я собственно говоря и делаю. Общаюсь по алгоритму, не сажая людей за комп.
Единственное отличие, я беру задачу, в которой зачастую я не знаю правильного решения. Таким образом я не могу быть предвзят относительно того, предложил человек то решение которое я знал или что-то другое.
а я лично 2мя руками за. Писать код на бумажке меня коробит. Неудобно… А далее уже смотреть на сам подход необязательно чтобы все работало как часы, именно на стратегию решения задачи. Я думаю так более верно…
да на бумаге действительно не удобно.
Думаю, что стоит озвучивать, что главное идея, а не идеальное чистое решение.
На мой взгляд, допустимо только в случае, когда нужно нанять первого программиста или простого кодировщика. И то не всегда. У хорошего программиста какое-никакое портфолио должно быть, а кодировщик не всегда и нужен, скорее, вообще не нужен.
В остальных случаях просить писать код на интервью пустая трата времени. Ну что можно увидеть за полчаса-час? Что программист умеет быстро писать код и компилировать? Ну и все. Если задача большая — то код будет плохим. Если маленькая — то почему просто не спросить, как он ее решать будет на словах? Хотя бы тот же вопрос о реверсировании строки, а еще лучше о циклической перестановке, там буквально на пальцах все объяснить можно.
Если нужен именно программист, то, на мой взгляд, достаточно попросить его показать его код. Все остальное можно выяснить на собеседовании. Более того, я предпочитаю видеть код (отрывки, просто текст) кандидата до встречи. Чтобы просто понять, надо встречаться или нет. Если кандидат заявляет, что своего кода у него нет, все принадлежит работодателю, то такой и не нужен, это кодировщик. Я никогда не поверю, что у хорошего программиста нет десятка килобайт своего кода, которым он не мог бы похвастаться.
Кстати, если бы мне предложили написать тест — я бы отказался. Хотя бы потому, что на ту же функцию реверсирования строки у меня уйдет больше получаса, это и в интернете решения посмотреть, и написать функцию, и тесты еще нужно написать. Долго.
Хмм… инетересная позиция.
Согласен, что маленькую функцию и словами можно объяснить.
Насчет наличия своего кода у программиста не совсем согласен. Даже если человек писал что-то для себя то оно не обязательно хорошего качества и доведенное до конца. А показывать полусопливый кусок, как-то не интересно.
Опыт показывает, что шлют и отрывки хороших готовых приложений, этому, собственно, ничего не мешает.
И почему свой код обязательно полусопливый? На мой взгляд, и для себя надо писать сопровождаемый код, и постепенно все к этому приходят. Иначе информация забывается, помнишь только, что вроде где-то когда-то это делал. А где и как — увы, уже не найти. Плюс привычка вырабатывается, если регулярно пишешь код в команде.
По куску кода можно многое сказать, и MaxD об этом и говорит чуть ниже: десяток строк, а выяснить можно многое. И при этом достаточно легко сделать заключение, а надо ли вообще собеседовать? 😉
Впрочем, в какой-то мере есть зависимость от языка. Мы программируем на Delphi, а в нем уровень вхождения низкий, и приходиться максимально отсекать тех, кого нужно учить с нуля.
Но мне кажется по небольшой функции можно понять как хорошо человек пишет код, но нельзя определить насколько архитектурно правильный — сопровождаемый код он пишет. Для сюньера это более важная способность, чем просто чистый код.
Да, кстати, согласен с Яски.
Функцию в 10 строк, если нужно многие могут «вылизать», но это ничего не говорит о том, как человек пишет архитектуру и будит ли он «вылизывать» код в миллион строк.
Речь изначально шла о десятке килобайт кода. Это не десять строк, и даже не тысяча 🙂
Более того, если человек шлет кому-то код, то вполне естественно ожидать, что он его «подлижет». Уж по крайней мере, выберет наиболее вкусное.
То есть, когда я прошу, ознакомившись с резюме, прислать код, то я ожидаю «резюме» в коде.
А по нескольким килобайтам такого резюме можно сказать очень многое. И знает ли человек язык и в какой мере, знаком ли он с API, использует ли он чужой код, работал ли в команде, примерный опыт работы, программировал ли раньше на других языках…
Да, согласен, мало можно сказать об архитектуре, о том, что будет в большом проекте. Это выясняется на собеседовании.
Можно сделать отрицательные оценки, о том, что человек не знает, что есть такое понятие, как архитектура приложения, о том, что языка он не знает, хотя, как он уверяет, писал на нем пару лет, и так далее. То есть, если код приемлем, то — вперед на собеседование. На котором, в частности, можно и обсудить присланное, и выяснить остальное.
Но данный подход, пожалуй, не особо годится, если требуется программист с небольшим опытом, начинающий. Там на код лучше вообще не смотреть.
В общем в целом я согласен, кроме двух «но».
а) Кода у программиста может не быть и в целом это нормально.
б) Код у программиста может быть очень старый и ему будет лень его обновлять и приводить в нормальный вид лишь для интервью и это тоже нормально.
>На мой взгляд, и для себя надо писать сопровождаемый код
Вот тут мне кажется логическая ошибка. «Надо» это неправильное слово для хобби. Код для себя — это хобби и человек пишет, что-то просто так.
Я всего лишь имею в виду, что я вот оглядываюсь на себя и
а) Код, который я писал для себя я последний раз писал, эдак лет 5 назад.
б) Этот код достаточно жуткий, потому что писал давно (когда был гораздо более зелен) и потому, что не расчитывал, на то, что прийдется его кому-то показывать.
Да, для себя. Но потом может возникнуть надобность посмотреть, а что там было. Или, не дай бог, поправить. Или взять оттуда что-то в проект. И если написано как попало, то остается либо разбираться и вспоминать все что было и почему так, либо надеяться, что ты сам вчерашний все-таки заложил некоторую расширяемость. «Надо» здесь — просто требование гигиены, не более. Хочется, чтобы код был максимально долговечным, для этого и надо прилагать некоторые усилия. К сожалению, человек я довольно неряшливый, и имею кучу программного мусора, который и выбросить жалко (еще бы, некоторым отрывкам больше десяти лет), и разбираться не хочется. Так и держу на «антресолях».
Так вот об этом же я и говорю. Конечно, если бы было бесконечность времени и желания, все было бы вылизано и причесанно.
Но, времени вполне конечно, и то, что я делал для себя 5 лет назад, сейчас для меня представляет ностальгическую ценность разве что.
И «надо» все же тут не применимо. Еще куда не шло, сказать «было бы полезно на будущее», но уж никак не надо.
Ведь у многих программистов выходит примерно так — на выходных сели что-то подколбасили, получили еле работающий (или не работающий) прототип. А потом отвлеклись или времени не стало и оно уходит на антрисоли.
Это тоже самое, что сказать, что все что кладется на реальные антрисоли обязательно должно быть чистое, выглажженое и продезадорированное. Вроде, таки да, так и должно быть, но чаще всего закидывают туда старый зонтик, который просто больше некуда приткнуть и о чистоте и выглажженности и речи не идет.
Я тоже за такой подход т.к. на мой взгляд он позволяет вполне объективно оценить возможности испытуемого. При таком подходе можно проверить:
* насколько качественный и безопасный код пишет человек. Например если в задании чётко сказано что надо вводить не более 20 символов в поле, то стоит задуматься когда человек не сделал проверку на это.
* как человек оформляет код. Например немало копий сломано из за того что люди применяют разные стили оформления
* насколько хорошо он может протестировать свой код когда написал его.
* какими источниками информации он пользуется когда возникают затруднения. Это вобще я заметил проблема для многих т.е. люди элементарно боятся задавать вопросы на форумах(даже на русских, не говоря об иностранных) или искать там возможные решения возникших ранее у кого либо проблем.
* какими инструментами, библиотеками и фреймворками он пользуется. Обычно на рабочем столе несколько ярлыков к разным IDE и утилитам которые могут понадобиться. Иногда человек может поинтересоваться, а нет стоит ли у вас «аддон-Х». Или если реализуя алгоритм со стеком он пишет свой класс для работы с ним, хотя фреймворк имеет готовый класс для этого. Из всего этого тоже можно сделать выводы.
И я тоже против написания прогрвммы на бумажке т.к. за компом я чувствую себя более уверено по причине того что пишу программы на нём постоянно и если и использую бумагу то только для рисования каких либо диаграмм или проектирования UI. Но никак не для написания кода. Если же надо набрасать какой либо нетривиальный алгоритм, то я предпочитаю сделать это сначала используя комментарии в коде ИМХО так намного удобнее.
P.S.
При приёме на предыдущую работу я проходил тест в котором надо було проверить парность скобок. И отведённых 2-х часов хватило вполне на то чтобы написать алгоритм, сделать UI и протестировать приложение в соответствии с поставленной задачей.
Общаясь с HR позже я узнал что некоторые люди не могут уложится в 2 часа. Такие люди отсеиваются т.к. опыт HR-ов и менеджеров проекта показывет что с такими людьми позже бывают проблемы.
Ну даже и не знаю.
Честно говоря, я бы еще нормально подошел к тому, чтобы у меня оценивали один пункт — алгоритм или качество кода или протестированность и т.п.
Но взять все это и ужимать в 2 часа — это жестоко. В конце концов, в среднем программисту приходится ориентироваться на 2-3 дневные задачи, а не на 2-3 часовые.
Но ты ведь когда код пишешь стараешься и алгоритм хороший придумать или код качественно написать или протестированность 🙂 т.е. непроизвольно делаешь всё это одновременно. Поэтому вполне логично предположить что и в рамках короткой задачи ты будешь действоватьточно так же. И именно так и происходит.
Вот пример из собственного опыта: довольно часто работая над большим приложением возникает необходимость проверить работу какой либо мелочи например вот что я нашел у себя на диске:
class Program
{
static void Main(string[] args)
{
string directoryName = Path.GetDirectoryName(typeof (Program).Assembly.Location);
string fileName = Path.Combine(directoryName, «Sleep1mCon.exe»);
Process process = Process.Start(fileName);
process.WaitForExit();
Console.WriteLine(«HasExited:» + process.HasExited);
Console.WriteLine(«ExitCode:» + process.ExitCode);
Console.ReadLine();
}
}
Часть простенкой програмки для проверки того чему будет равен ExitCode и HasExited если закрыть приложение по Ctrl+Alt+Del.
Смотря на неё понятно что даже пиша что либо за пределами основного проекта я придерживаюсь правил форматирования, использую выработанные приёмы которые использую в основном приложении заместо хардкода (Path.GetDirectoryName(typeof (Program).Assembly.Location)), стараюсь писать максимально надёжный и безопасный код (Path.Combine), знаю особенности работы консольных приложений (Console.ReadLine();). Ну и естественно есть недостатки, например Console.WriteLine можно записать элегантнее 🙂 Вроде бы мелочи, но эти мелочи о многом говорят. 🙂
т.е. даже на задаче решение которой займёт 2-3 часа вместо 2-3 дней можно вполне будет увидеть что знает и умеет человек её написавший и что будет если взять его на работу.
Форматирования мы похоже не увидим 🙂 прийдётся поверить мне на слово 🙂
Буду как Станиславский…… Не верю… ;)))
В целом согласен, но проверяющий должен быть в разумной мере лояльным. Если отдать проверять кому-то просто по табличке:
а) Проверены ли все возвращаемые значения на NULL
б) Названия всех переменных в венгерской нотации
в) Отсутствие дублирующегося кода
и т.п.
То можно получить абсолютно идиотские результаты.
Ведь, человек который проходит тест изначально не знает, является ли его задача решить задачу или получить все галочки по какой-то таблице.
Например, работая с теме же программистами, по ходу работы я пытаюсь подкорректировать, то что мне у них не нравиться. Чаще всего после пару месяцев совместной работы, человек (если он более менее умелый) приходит к желаемому мной стилю.
Итого имеет 2 месяца постепенно подтачивания и 2 часа с проверкой по табличке. Это совсем разные вещи.
Мой друг устраивался на работу (PHP). На собеседовании попросили написать код на бумажке.
У парня реально было мало опыта в разработке и пробовался он как Junior. Естетвенно, всех библиотечных функций он не знал и не мог знать, это приходит со временем.
Результат — отсутствие вменяемого кода. Взглянув на который поняли, что разбирается в алгоритмах, но многого (если ничего) не знает.
В реальных условиях, он либо погуглил бы, либо взглянул на документацию, а не пытался бы писать сотни строк, переписывая стандартные функции… И результат был бы!
Как по мне, то либо писать код в IDE (пусть даже на чужой машине), либо не писать вообще… Это касательно новичков в отрасли.
А профи и так видно…
Ну честно говоря я даже после многих лет опыта на память тоже многие функции не помню, что мне кажется не так и важно.
Функцию я найду за 5 минут в инете, а вот правильное понимание архитектуры в инете не найдешь.
В своей жизни помню два таких собеседования: первое я безнадежно завалил, и завалил именно по нехватке опыта и неумению строить алгоритмы и понимать задачу.
Второе было уже спустя несколько лет, на выполнение давалось несколько часов. Сначала нервничал, но когда сел за комп и никто не висел над душой — беспокойство быстро ушло и задача решалась легко и приятно. Если у человека действительно есть опыт и практика, то беспокойство и неудобство быстро проходит.
Люди, которые отказываются проходить такие тесты… Мне кажется, что это первые признаки звездной болезни, впоследствии такие люди начнут отказываться писать какую-то программу потому что она скучная или не амбициозная и т.д.
Примерно полгода назад набирал людей, давал им задания с одного сайта на котором есть много sql задач и интерфейс для их решения. Давал полчаса на решение задач у нас и потом предлагал продолжить дома — если было желание.
Такой подход очень хорошо помогает отсеивать людей, которые выдают желаемое за действительное. Было несколько людей, которые очень уверенно общались, но на практике ничего из себя не представляли.
Мое мнение — если есть из чего выбирать — то такие тесты на собеседовании должны применяться однозначно, а если по конкретному кандидату возникают сомнения, дескать может он все таки хороший или просто глаза у него горят — то ему всегда можно дать дополнительный шанс в виде испытательного срока.
>Если у человека действительно есть опыт и практика, то беспокойство и неудобство быстро >проходит.
Не совсем с этим согласен. Есть очень беспокойные люди и бъюсь об заклад у них оно не уходит.
>Люди, которые отказываются проходить такие тесты… Мне кажется, что это первые признаки >звездной болезни
Да, согласен, если человек отказывается что-то делать, это достаточно плохой признак.
Да не обязательно звездная болезнь. Если человек принес показать свой код, например. И если он подобное задание уже делал — то зачем ему давать его делать? И зачем ему соглашаться и тратить свое и ваше время? Код ведь с вероятностью 99% будет выброшен. И какой интерес программировать несколько часов «на выброс», чтобы только показать, как ты это делаешь?
Если человек отказывается, то это говорит только о том, что вы ему менее нужны, чем он вам. Не более. И может быть, стоит присмотреться?
>Если человек отказывается, то это говорит только о том, что вы ему менее нужны, чем >он вам. Не более. И может быть, стоит присмотреться?
Скажем так, если человек разумно аргументировал — то может и присматриваться.
Если человек, просто отказался — то это фигня какая-то.
Когда я устраивался в компанию, в которой сейчас работаю, мне дали тестовое задание на дом — написать простенькую игру. Зная язык и имея опыт работы выполнить его можно за три дня. Но поскольку язык для меня был новый, опыта работы программистом не было абсолютно никакого я провозился с этим заданием целый месяц. В итоге мной была написана самостоятельная игровая библиотека с различными наворотами и с перспективой на дальнейшее развитие. В то время мне очень хотелось заполучить эту работу и было много свободного времени. А если порассуждать — ведь достаточно было бы и простого пятиминутного задания — это хорошо, что у меня есть время и желание. А хороший специалист просто не станет тратить свое бесценное время на рутинную оперцию по приему на работу.
Та да, если задание на 2 дня, то вероятнее всего это уж черезчур. Так как таким образом для того, чтобы сходить на 5 собеседований надо будет пол месяца потратить.
Да и вообще, я не совсем понимаю, что проверяют именно домашние задачи.
Имеет смысл задавать мини-задачки, которые требуют две-три строчки кода. Например, написать функцию которая определит является ли число степенью двойки. Писать же полноценный код или приложения утомительны и могут быть пустой тратой времени как для интервьюируемого, так и для интервьювера. Иногда я прошу кандидатов завершить мой код, если задача требует больше 7 строк кода.
Тогда вопрос, что соответственно проверяется такой задачей.
Например проверка является ли число степенью двойки — это проверка
а) алгоритмического мышления (если человек пошел делить на 2 и смотреть, что там у него постоянно в остатке)
б) знания, как хранятся в памяти числа (если он пошел биты считать)
Проблема таких задач, что они как луч лазера — хорошо проверяют, но очень узкую область.
Я бы так не сказал — алгоритмическое мышление это как раз широкая область.
М… Да, алгоритмическое мышление, пожалуй не как луч лазера, но все таки и не как мощный прожектор тоже.
Я за проверку мышления, но не только алгоритмического, но и логического.
Мы практиковали такой подход. Т.е. давали 2-3 часа и 5 заданий. Например:
— сделайте отдельное законченное приложение, показывающее работу с Master-Detail
— сделайте отдельное законченное приложение, показывающее работу с Lookup-полями
Все задания делать НЕ обязательно. Использование help не лимитировалось.
Что мы проверяли, по итогу:
— работает/ не работает
— умеет ли чел найти в хэлпе нужный топик
— насколько он понимает задания (В задании сказано — «отдельное приложение в отдельном каталоге», а сделаны 5 заданий в одном приложении)
Результат был эффективен.
Ха! Вот это в точку. Некоторые кандидаты просто не умеют пользоваться помощью и поисковиками. Я всегда спрашиваю у кандидатов базовые знания пользоваться гуглом.
Кстати, похоже добавлю ка я в собеседование задачу по поиску в Googl’е — это сейчас становится, чуть ли не одно из ключевых умений.
Ага. Причём лучше не давать ему прямую наводку по типу «ищи в Гугле», а «непроизвольно» спровоцировать его воспользоваться поиском. 🙂
Кстати раз уж пошла такая пьянка 🙂 То Яски затронул ещё одну интересную тему на которую не всегда обращают внимание при подборе персонала:
> «…что при приеме человека в коллектив нужно рассматривать не столько его профессиональные, самостоятельные качества в отрыве от коллектива, сколько его будущее влияние на коллектив в целом.»
т.е. при приёме на работу обращать не только насколько хорошо человек прошарен в IT, но и ещё на то «впишется» ли он в существующую комманду и станет ли он со временем её неразрывной частью.
И я согласен с Яски что этот пункт доминирует над профессиональными навыками. Потому как действует старое народное правило если(в вольной траковке): смешать килограмм говна и 4 килограм павидла получится пять килограмма говна 🙂
кстати, тему эту уже обсуждали у меня вот тут:
http://victorronin.com/2008/06/06/brat-li-slozhnogo-no-umelogo-cheloveka/
Кстати, не согласен с этим применением народного правила.
Ситуация такова, что даже при тщательному отборе, коллектив скажем больше чем 10-15 человек начинает подразбиватся на различные подколлективы. Поэтому гомогенного павидла ожидать нечего.
А если ожидать его нечего, то можно и орехи брать и ягоды и еще что-то. Постепенно рассортировывая (да оно и само рассортируется).
Единственное, что правда, нельзя брать откровенное говно. Правда говоря честно, я еще не встречал хороших программистов, которые одновременно являются откровенным говном. Видал только достаточно сложных людей.
Да и вообще, еще в одной статье писал:
http://victorronin.com/2008/07/15/biznes-eto-vam-ne-xixanki-xaxanki/
Это из программистских и проджект менеджерских мечт вырастают надежды на добрый/вечный/слаженный коллектив. Побыв владельцем, мечты что-то разбиваются о реальность.
Получается остается основным принцип — брать профессиональных людей, а бизнес сам попрет в гору.
В целом, да — брать профессиональных лучше, чем не профессиональных.
Увы, это не единственная переменная влияющая на удачность бизнеса, так что только на этом в гору он еще не попрет.
М… Спорная техника.
Точнее она хорошо выберет определенный тип людей и с треском отсеит остальных.
И в эти остальные могут попасть люди
а) Не идеально внимательные
Да это не лучшая программистская черта, но тем не менее и не самая худшая
б) Людей, которые волнуются и не могут сосредоточиться
Особенно это актуально для постановки задачи — 5 задач, решайте, что хотите.
в) Люди с медленным стартом.
Все таки, законченное приложение, а не дай бог еще и пару приложений можно в 2-3 часа и не уложиться, если не привык с места в карьер писать.
А зачем нам постянно волнующиеся, невнимательные, ленивые работники? Там где они нужны можно обойтись вообще без теста.
Я бы сказал, что валятся в кучу совсем разные вещи.
Волнующиеся работники — это даже может быть неплохо. Особенно если они волнуются насчет качества.
Невнимательные работники — это хуже. Хотя опять же, я например проблемо-ориентированный разработчик и могу решить сложную проблему. Да при этом может я забуду о какой-нибудь «шелухе» вокруг. Но эту шелуху могут добить и менее умелые люди (при том, что ключевую проблему они не могут добить).
А вот ленивые работники — действительно нужно не слишком. Точнее, нужны люди умно-ленивые. Которые ленятся делать глупую работу два раза и пытаются решить проблемы наперед.
Вы правы, есть категории, которые несмотря на минусы являются вполне профпригодными.
Мои мысли по этой теме, что при приеме человека в коллектив нужно рассматривать не столько его профессиональные, самостоятельные качества в отрыве от коллектива, сколько его будущее влияние на коллектив в целом. Положительные его качества должны влиять положительно на всю работу и при этом отрицательные качества не должны тормозить остальных. Первое, что я считаю необходимо применить это то, что участвовать в собеседовании должна вся команда. Тестового задания вообще не нужно, достаточно провести общую беседу на профессиональную тему, из нее попытаться определить как человек действует для решении задач, как реагирует на возникающие проблеммы. Решение же принимать или нет должен после этого сообща весь коллектив. Сомнений быть не должно или да или нет.
>…есть категории, которые несмотря на минусы являются вполне профпригодными.
Идеальных людей не бывает :), так что такой вариант не исключен. Но есть и исключения, например поставте себя на место человека который создал свою компанию или отвечает за подбор персонала. Если он ошибётся то ему скорее всего прийдётс туго. Так что тут ИМХО если после общения с человеком появляется хотя бы маленькое сомнение в нем, то лучше сказать «Нет». И ничего в этом зазорного нет. Не возьмут здесь, так возьмут в другом месте.
Для приведённых вами трёх категорий мои ответы были бы:
а) Нет (Во первых нет в жизни слова — идеально, во вторых если в 5 строчках задания он может что либо упустить, то что же будет с реальной задачей? )
б) Твёрдое Нет. Проверено на самом себе что самое главное в нашей профессии это — «отсутствие страха и уверенность в себе». Если ты спокоен и ничего не боишься то всё у тебя получится и сложный баг отловишь и зарефакторишь как надо и т.п., но если нет этого, то всё как правило идёт на перекосяк.
в) Возможно дал бы шанс. НО при условии что у человека развита коммуникация. Был случай когда я общался c человеком принятым на работу(!) и на вопрос к которому приходилось ждать респонса от него по 20-30 сек.
>…участвовать в собеседовании должна вся команда
Не соглашусь с предложеным решением т.к. это идеальный вариант. А идеальные варианты трудноосуществимы или неосуществимы вовсе. В данном случае есть существенная проблема: вся команда должна N часов тратить на собеседование одного человека и руководствуясь своим опытом и правилом 80-20 скорее всего в 80% случаев человек неподойдёт.
Вторая проблема: что должна делать комманда? Сидеть и слушать? Или задавать вопросы? Все члены командв должны задать свои вопросы или только чать? Как организовать общение? Как собрать их всех вместе в конце концов? :)… Понимаете к чему я клоню? После 2-3 таких собеседований большинство членов комманды будут стараться увильнуть от этой обязанности 🙂
НО тем неменее такой способ вполне имеет право на сушествование, НО ИМХО только в момент когда формируется «ядро комманды» (как правило в недавно образованных компаниях) когда при приеме нового человека стораются найти не просто программиста, а найти Высококласного Профессионала.
Я думаю «вся команда должна общаться» — то, что несколько человек из команды поочередно общаются.
Кстати, поддерживаю, что важнее такие массовые собеседования при формировании ядра команды. При «набивании» команды, дополнительными не ключевыми сотрудниками, 2-3 интервьюирующих по очереди — вполне достаточно.
Это вообще сложная тема профессиональность против сложности характера.
Я не помню, принимали ли вы участие в обсуждение:
http://victorronin.com/2008/06/06/brat-li-slozhnogo-no-umelogo-cheloveka/
Я зачастую предпочитаю принять более профессионального, хоть и более сложного человека.
В общем-то я за слаженность коллектива, но как показывает практика, чем больше коллектив, тем меньше шансов в общей слаженности.
Скорее, как начальнику, нужно подбирать подчиненных, которые подходят начальнику.
Вообще главное думать- а там все будет уже!