Comments 220
Скажите, пожалуйста, какие есть варианты ответа на эти вопросы и какие Вы бы сделали из них выводы:
Что можете рассказать о вашем самом успешном проекте? Что считаете своим наивысшим профессиональным достижением?
Очень интересные вопросы, но мне всегда очень сложно отвечать на них. Своим наивысшим профессиональным достижением считаю постоянное обучение. И следовательно то, что достиг год назад сегодня уже вовсе и не достижение.
Спасибо!
Что можете рассказать о вашем самом успешном проекте? Что считаете своим наивысшим профессиональным достижением?
Очень интересные вопросы, но мне всегда очень сложно отвечать на них. Своим наивысшим профессиональным достижением считаю постоянное обучение. И следовательно то, что достиг год назад сегодня уже вовсе и не достижение.
Спасибо!
Отличный вопрос, который я задаю и сам.
Тут важно узнать, что именно ты тогда считал важным.
Тут важно узнать, что именно ты тогда считал важным.
А что делать, если ответы на это вопросы NDA, NDA?
Это что за NDA такое, что вы не сможете сказать, что вашим самым большим успехом было, например; «Построение нейронной сети для поиска книг на <Ваш язык программирования> с использованием <Другие Технологии»>?
Кстати по тому NDA, которое я, в силу обстоятельств, таки не подписал — «для поиска книг» я бы сказать не смог точно. Другой вопрос, что обычно на NDA в личном разговоре у нас многие кладут.
Кстати, мне вот интересно, а как к нарушению NDA на собеседовании относятся собеседующие?
Кстати, мне вот интересно, а как к нарушению NDA на собеседовании относятся собеседующие?
Реакция будет такая же, как если на вашу просьбу рассказать про проект на котором придется работать, вы получите ответ — только после трудоустройства, ибо NDA.
Если я честно скажу работодателю, что я считаю своим самым успешным проектом, он, наверное, испугается.
Заинтриговали.
Всего лишь головоломка. Семимерный кубик Рубика.
Обычно, получив подобный вопрос, я рассказываю вот эту историю.
Что-то с кодиировками не то db.tt/rW4lPBdA
Надеюсь, описанные методы помогут и мне найти классных программистов :)
Спасибо! Отличный метод, коротко и чётко описан. Это одна из немногих дельных статей на эту тему
Мне кажется, основная мысль, которую нужно иметь в виду идя на собеседование, это «собеседование — это не экзамен!». К сожалению, об этом часто не знают и собеседующие. В самом деле, очень многие компании (или их HR-ы) воспринимают сей процесс именно в качестве экзамена на профпригодность. Отсюда автоматически исходит и пагубная модель построения беседы в стиле «здесь спрашиваю я» и формат «конкретный вопрос — конкретный ответ». Не знание конкретного ответа не означает ровным счетом ничего, тогда как беседа на тему этой технологии, инициированная соискателем может быть куда более информативной. Просто доселе ему не довелось столкнуться именно с такой проблемой.
Соискателя заваливают техническими вопросами и всевозможными тестами, но зачастую даже не пытаются поинтересоваться его проектами. За всю мою практику откровенно заинтересовались и сами спрашивали об этом только две компании. Остальным приходилось на это намекать, дабы развить беседу. Дайте человеку рассказать о себе, и вы возможно услышите гораздо больше, нежели хотели спросить. В статье правильно упомянуто про стресс. Человеку гораздо проще рассказать о том что, он знает лучше всех присутствующих (свои проекты), нежели второпях пытаться что-то придумать. Правильно ведя беседу, можно задать гораздо больше точных вопросов и получить адекватные ответы. Техническому специалисту, присутствующему на собеседовании это даст много полезной информации.
Соискателя заваливают техническими вопросами и всевозможными тестами, но зачастую даже не пытаются поинтересоваться его проектами. За всю мою практику откровенно заинтересовались и сами спрашивали об этом только две компании. Остальным приходилось на это намекать, дабы развить беседу. Дайте человеку рассказать о себе, и вы возможно услышите гораздо больше, нежели хотели спросить. В статье правильно упомянуто про стресс. Человеку гораздо проще рассказать о том что, он знает лучше всех присутствующих (свои проекты), нежели второпях пытаться что-то придумать. Правильно ведя беседу, можно задать гораздо больше точных вопросов и получить адекватные ответы. Техническому специалисту, присутствующему на собеседовании это даст много полезной информации.
Недавно мой товарищ собеседовался в Микрософт, дважды. Первый раз просто пропали и не ответили. Во второй раз отказали под предлогом того, что товарищ за время между первым и вторым собеседованиями не достаточно вырос профессионально.
Интересная тенденция мерять людей по производной их роста. А не только знаниями или искрами в глазах.
Интересная тенденция мерять людей по производной их роста. А не только знаниями или искрами в глазах.
Возможно, это означает что первое собеседование было завалено (с т.з. собеседующего), а на втором собеседуемый не зажёг?
Уже не говоря о том что мерять людей по производной их роста это вполне хороший подход в зависимости от того куда и на какую должность нанимать.
Уже не говоря о том что мерять людей по производной их роста это вполне хороший подход в зависимости от того куда и на какую должность нанимать.
У них там конвейер потому что, вникать в детали каждого кандидата нет времени и желания, поэтому херачат по предписанным паттернам.
На мой взгляд, один из лучших подходов к собеседованию. Это по сути разговор двух специалистов о том, что их интересует, что волнует, чем они живут, а не попытка одного доказать, насколько он крут, а второго оправдаться, что он не дурак. Причем кандидат в любом случае в слабой позиции — чужая территория, незнакомые люди, напряжение от того, что от твоих слов зависит результат и тд. При этом просто разговор умных людей позволяет забыть обо всех негативных факторах. Ведь программисты такой народ, они больше всего на свете любят рассказывать о своих творениях понимающим людям.
В некоторых случаях, хотелось бы увидеть, как человек кодит. Но если человек уверенно рассказывает о тех задачах, которые он решал в другой компании и толково отвечает на дополнительные уточняющие вопросы, то, как правило, за его код не стоит переживать.
Как жаль, что такой подход используют очень редко. Из большого количества собеседований, которые проходил, только несколько было похожих на описанное выше. Сам всегда пытался проводить собеседования подобным образом, но обычно получал замечания от старших коллег, что надо «больше гонять по теории», «давать больше практических заданий» и все в таком духе.
В некоторых случаях, хотелось бы увидеть, как человек кодит. Но если человек уверенно рассказывает о тех задачах, которые он решал в другой компании и толково отвечает на дополнительные уточняющие вопросы, то, как правило, за его код не стоит переживать.
Как жаль, что такой подход используют очень редко. Из большого количества собеседований, которые проходил, только несколько было похожих на описанное выше. Сам всегда пытался проводить собеседования подобным образом, но обычно получал замечания от старших коллег, что надо «больше гонять по теории», «давать больше практических заданий» и все в таком духе.
Увы, принимали на работу — энтузиазма было хоть отбавляй, а со временем его становится всё меньше и меньше. «Интересные задачи» оказываются на самом деле никому не нужными рутинными. Такое тоже бывает.
По моему опыту, от самого человека зависит, будут его задачи интересными или нет. Но многие почему-то считают, что работодатель их должен на поводке вести от одной интересной задачи к другой. А качественная инициатива обязательно будет замечена и отмечена. Даже в такой гнуси как демонтирование легаси-говна можно нехило поднять свой профессиональный уровень в куче областей: коммуникации, аналитика, документация, разминирование, миграция. Причём делать это так, что будет самому очень интересно.
Но, повторюсь, это именно что самостоятельная работа, включающая, в том числе, некоторую «дрессировку» работодателя.
Но, повторюсь, это именно что самостоятельная работа, включающая, в том числе, некоторую «дрессировку» работодателя.
Так нет, я имел в виду буквально — задачи, которые приходится решать, никому не нужны. Решения сделаны качественно, требованиям заказчика удовлетворяют, успешно внедряются; вот только не пользуется продуктами никто, потому что придуманы они «для галочки». Заказчик в лице «шишки Боба» доволен, а люди на местах — нет. Им это не нужно. И от этого становится грустно.
Полгода я потратил на внедрение системы контроля версий («а чем вам не нравится копирование на флешку вчерашней версии?»), функционирующий баг-трекер, юнит-тесты хотя бы критически важного кода; старался делать свою работу хорошо. И вот система готовится к внедрению, она в целом более качественна и функциональна чем до того, как я начал участвовать в её разработке. Интересны были эти задачи? Да, интересны. Стал ли я (или кто-то) счастливее от того, что эти задачи решены? Увы, нет. Это очень сильно демотивирует.
Полгода я потратил на внедрение системы контроля версий («а чем вам не нравится копирование на флешку вчерашней версии?»), функционирующий баг-трекер, юнит-тесты хотя бы критически важного кода; старался делать свою работу хорошо. И вот система готовится к внедрению, она в целом более качественна и функциональна чем до того, как я начал участвовать в её разработке. Интересны были эти задачи? Да, интересны. Стал ли я (или кто-то) счастливее от того, что эти задачи решены? Увы, нет. Это очень сильно демотивирует.
размера компенсации
Чем обусловлено использование этого слова? Это так модно сейчас? От многих его слышу, но так и не понял в чем его смысл в данном разрезе.
Ты отдаешь работадателю свое время, невосполнимый ресурс.
это не компенсация а заработная плата. Скорей речь о нервных клетках и т.п. — то что не связано непосредственно с работой.
Имеется ввиду что компенсация может быть не только материальной. Многие компании предоставляют еще и так называемые «benefits». Например ДМС, оплату спортзала, или бесплатные обеды.
А вот как все это отразить в ответе, когда спрашивают «размер компенсации»?
В нашей компании после успешного прохождения интервью вручают крассивую бумажку, на которой в числе прочего написано.
Компенсационный пакет включает в себя:
И еще просто чтобы пояснить свою позицию я не настаиваю на англицизмах ни в коем случае. Меня самого передергивало особенно в начале от слова «митинг», вместо совещание.
Но как сказать «компенсационный пакет» по другому тоже не знаю. Всетаки это более шерокое понятие, чем просто оклад.
Компенсационный пакет включает в себя:
- Оклад ....
- Премии...
- Полис ДМС....
- и т.д. ....
И еще просто чтобы пояснить свою позицию я не настаиваю на англицизмах ни в коем случае. Меня самого передергивало особенно в начале от слова «митинг», вместо совещание.
Но как сказать «компенсационный пакет» по другому тоже не знаю. Всетаки это более шерокое понятие, чем просто оклад.
Это уже когда успешно прошли интервью. А вот когда на интервью у соискателя спрашивают «на какой размер компенсации вы расчитываете?», то что ему отвечать?
На вопросы о желаемой зарплате всегда тяжело отвечать. Я просто смотрел среднюю зарплату по рынку и накидывал 5-10%. Один раз со мной торговались, сошлись на средней. Один раз просто приняли мои условия. Про остальные плюшки я уже узнал потом =)). К слову сказать в первой компании их и не было.
Однако при оценку средней зарплаты по рынку нужно учитывать, что позиция Ведущий разработчик может означать абсолютно разный уровень. Поэтому прходится еще и обращать внимание на размер и проэкты компании.
В общем вопрос это тяжелый и я бы рекомендовал подумать о нем до похода на интервью, а там уже посути просто выдать «заготовки».
Однако при оценку средней зарплаты по рынку нужно учитывать, что позиция Ведущий разработчик может означать абсолютно разный уровень. Поэтому прходится еще и обращать внимание на размер и проэкты компании.
В общем вопрос это тяжелый и я бы рекомендовал подумать о нем до похода на интервью, а там уже посути просто выдать «заготовки».
Если на то пошло, то я продаю свое время. Не пойму, чем не подходят слова «оклад» и «заработная плата».
«Оклад» и «заработная плата» — это часть компенсации, но не всегда единственная. Например, ежегодная (ежеквартальная) премия — это не зарплата и не оклад. Ну и так далее.
Возможно, поэтому и появилось слово «компенсация»
Возможно, поэтому и появилось слово «компенсация»
Окай, тогда получается, что при ответе на этот вопрос надо так же включать бонусы, оплату овертаймов и т.д.?
Насколько я привык, регулярные бонусы в это включаются. Оплата переработки обычно нет — возможно, потому что она в моем случае не предполагается (ну или предполагается нерегулярно — в таком случае говорят, что переработка оплачивается так-то и так-то).
Кстати, соцпакет при рассказе о компенсации тоже обычно упоминается.
Кстати, соцпакет при рассказе о компенсации тоже обычно упоминается.
компенсации за стрессовость работы, необычный график работы и т.д.
Человек тратит свое здоровье, время и нервы. Работодатель просто обязан это компенсировать!
А как по мне это просто уловка HR, что-то вроде «Мы не просто платим вам зарплату, а компенсируем вам потраченные время/здоровье/нервы».
Мне наоборот режет слух «компенсация». Поэтому уловкой назвать это сложно. Но вообще, обычно речь идет не только о зарплате. Так к примеру многие компании предлагают льготные или вообще бесплатные походы в спорт залы, бесплатные обеды, и тп и тп. это можно отнести к компенсациям, имхо
Для меня «компенсаця» слово, которое показывает отношение работодатель-работник не как Начальник-Подчиненный, а как партнеры, где один использует знания второго для достижения поставленных задач
Тогда почему не доход или прибыль? Если как партнеры.
Потому что он пользуется прибылью проекта, а тебе как раз компенсируется время, которое ты потратил на него.
Как бы так — ты партнер который участвует в проекте без риска но со стабильным доходом.
Как бы так — ты партнер который участвует в проекте без риска но со стабильным доходом.
мм… получается как бы партнер за деньги. ;) если притягивать терминам не свойственные им смыслы всегда какая-то пошлятина получается. давайте так больше не будем делать, а? слова работодатель и работник вполне нормально характеризуют этот тип отношений.
давайте так больше не будем делать, а?
Простите, а в каком мы с вами виде отношений, что бы заключать соглашение так не делать? оО
К тому же, не нужно выдергивать мою фразу из контекста. Я логической цепочкой пытаюсь показать свои рассуждения, почему люблю термин «компенсация».
Другими словами, для меня работа в первую очередь лишь помощь работодателю по решению его задач. Он же в свою очередь компенсирует потраченное на него моё время.
Это называется — заработная плата — плата за работу (труд, службу и т.п.).
Эвфемизм «компенсация» — плох, по определению. Определение простое — он не отражает, что деньги заработаны трудом, а лишь выданы в качестве компенсации… Компенсируют использование личного автомобиля, ноутбука, телефона, но не конкретный труд.
Либо назвать «гонорар» — красиво звучит.
Эвфемизм «компенсация» — плох, по определению. Определение простое — он не отражает, что деньги заработаны трудом, а лишь выданы в качестве компенсации… Компенсируют использование личного автомобиля, ноутбука, телефона, но не конкретный труд.
Либо назвать «гонорар» — красиво звучит.
Гонорар — это разовая оплата.
Сказал, как отрезал :)
С чего вдруг компенсация плоха по определению?
Когда я просто общаюсь с работодателем/заказчиком, но не работаю, я трачу на него своё время, но все равно получаю денежное возмещение за это. Я могу просто сидеть и ждать, пока он освободиться и опять же получать за это деньги.
Никакой работы я не произвожу в данный момент.
Эвфемизм «компенсация» — плох, по определению. Определение простое — он не отражает, что деньги заработаны трудом, а лишь выданы в качестве компенсации… Компенсируют использование личного автомобиля, ноутбука, телефона, но не конкретный труд.
С чего вдруг компенсация плоха по определению?
Когда я просто общаюсь с работодателем/заказчиком, но не работаю, я трачу на него своё время, но все равно получаю денежное возмещение за это. Я могу просто сидеть и ждать, пока он освободиться и опять же получать за это деньги.
Никакой работы я не произвожу в данный момент.
Когда я просто общаюсь с работодателем/заказчиком, но не работаю <...>
Никакой работы я не произвожу в данный момент.
Сомневаюсь. Даже если вы просто рассказываете работодателю, что происходит в текущем проекте, или наоборот, он рассказывает, чего хотят потенциальные клиенты и рассуждает, чем бы их лучше привлечь — это работа. Может быть, она не выражается в строчках кода или исправленных ошибках, но она точно так же идёт на пользу компании. А что ещё надо от работы (с точки зрения работодателя)?
Ну, в трудовом договоре указано, что является моими должностными обязанностями, нет?
К тому же, просто ожидание уж точно не является работой.
Ладно, это всё патетика на самом деле. Просто для меня «компенсация» более широкое понятие чем заработная плата, которая включает в себя не только второе, но и дополнительные плюшки, которые могут быть не только денежными.
Ну и конечно же, мне морально приятно воспринимать что мне компенсируют потраченное время на работодателя, а не платят ЗП за некую фиксированную работу.
К тому же у разработчиков(везде где я работал) компенсация была не фиксированной суммой, а плавающей в зависимости от отработанного времени в месяц. Естественно было ограничение на минимальное количество отработанного времени с временными рамками. когда ты точно должен присутствовать в офисе. Например, с 11 до 18 ты должен быть.
К тому же, просто ожидание уж точно не является работой.
Ладно, это всё патетика на самом деле. Просто для меня «компенсация» более широкое понятие чем заработная плата, которая включает в себя не только второе, но и дополнительные плюшки, которые могут быть не только денежными.
Ну и конечно же, мне морально приятно воспринимать что мне компенсируют потраченное время на работодателя, а не платят ЗП за некую фиксированную работу.
К тому же у разработчиков(везде где я работал) компенсация была не фиксированной суммой, а плавающей в зависимости от отработанного времени в месяц. Естественно было ограничение на минимальное количество отработанного времени с временными рамками. когда ты точно должен присутствовать в офисе. Например, с 11 до 18 ты должен быть.
компенсируют потраченное время на работодателя, а не платят ЗП за некую фиксированную работу
А если работа не фиксирована, как в примере со строителями? Сегодня монтажник делает фундамент, завтра коммуникации…
Возможно я сужу больше с другой стороны, там где компенсация это нечто такое, что платится дополнительно к заработанному и является необязательной частью, а бонусом, хоть и почти обязательным в некоторых местах.
Сказал, как отрезал :)
Да, категоричен, водится за мной такое :).
Не компенсация плоха, а определение. Приучает к тому, что работник — не заработал эти деньги, а получил компенсацию. Возможно, сказывается опыт вне IT-сферы, в частности физический труд или беготня для оказания услуг, где «труд» и «работа» в изначальном смысле. Нет, я не считаю, что айтишники сидят и нифига не делают. Отличие работы, например строителя — её можно показать кому угодно и ценность — видна любому, в отличие от труда айтишников, ценность которого видна не всякому. Именно поэтому трудозатраты могут и, зачастую, так и происходит… не оцениваться по достоинству, чтоли.
А в плане «сижу, а деньги капают», ну это называется ставка/оклад и так далее, в отличие от сдельной оплаты труда, где мало поработал — мало заработал.
UFO just landed and posted this here
Ой-ой! Сколько комментов из-за одного слова! Не нравится слово компенсация? Просто мысленно замените его на зарплата с плюшками.
Вот, к примеру, что может входить в «пакет» и что можно спрашивать или оговаривать при устройстве на работу в Штатах:
1. Размер зарплаты.
2. Размер бонуса (ежегодной премии).
3. Участие компании в дополнительных пенсионных накоплениях работника.
4. Акции компании для работника либо их покупка работником на льготных условиях.
5. Медицинская страховка и количество больничных дней в году.
6. Размер отпуска на старте и как он будет расти с годами.
7. Количество праздничных дней в году.
8. Возможность в какие-то дни работать из дома, если сильно понадобится, или, допустим, работать из дома по пятницам.
Мелкие плюшки:
9. Компенсации за устройства, покупаемые для дома и которые могут иметь прямое или косвенное отношение к работе: принтер, сканер, кресло и т.п. Некоторые фирмы могут частично погашать расходы на личные устройства, например, раз в 3 года — $1000 при покупке личного компьютера или гаджетов.
10. Кроме рабочего компьютера компания может предоставлять мобильный телефон с интернетом и т.п.
11. Оплата спортзала, частичная оплата членства в каком-нибудь спортклубе и т.п.
12. Если предполагаются частые командировки, то — размеры и способы покрытия расходов, уровень гостиниц, траты на еду и т.п.
1. Размер зарплаты.
2. Размер бонуса (ежегодной премии).
3. Участие компании в дополнительных пенсионных накоплениях работника.
4. Акции компании для работника либо их покупка работником на льготных условиях.
5. Медицинская страховка и количество больничных дней в году.
6. Размер отпуска на старте и как он будет расти с годами.
7. Количество праздничных дней в году.
8. Возможность в какие-то дни работать из дома, если сильно понадобится, или, допустим, работать из дома по пятницам.
Мелкие плюшки:
9. Компенсации за устройства, покупаемые для дома и которые могут иметь прямое или косвенное отношение к работе: принтер, сканер, кресло и т.п. Некоторые фирмы могут частично погашать расходы на личные устройства, например, раз в 3 года — $1000 при покупке личного компьютера или гаджетов.
10. Кроме рабочего компьютера компания может предоставлять мобильный телефон с интернетом и т.п.
11. Оплата спортзала, частичная оплата членства в каком-нибудь спортклубе и т.п.
12. Если предполагаются частые командировки, то — размеры и способы покрытия расходов, уровень гостиниц, траты на еду и т.п.
Чем обусловлено использование этого слова? Это так модно сейчас?Это калька с американского термина compensation and benefits, он же total reward: тут фокус в чем — при подписании контракта зачастую зарплата (которая base salary) — всего лишь один из пунктов выплат, причем далеко не самая большая (емнип, пару лет назад натыкался на информацию о том, что самая большая именно зарплата в США — без учета годовых и отпускных бонусов, опционов и т.д. составляла что-то около девятисот тысяч в год грязными). Опять же — в компенсационные планы прописываются схемы некоторых вещей, которые у нас регулируются общим КЗоТ-ом: размеры отпускных, выплат при болезни, выплат при увольнении и т.д., т.к. они совершенно не обязаны быть привязаны к base salary и далеко не обязательно (особенно выплаты при увольнении) выплачиваются деньгами.
Правильные вопросы свидетельствуют об опытности специалиста.
Опытности в умении менять работу?
Захотелось сходить на собеседование к автору =)
Приятно целиком и полностью быть согласным с тем, что Вы написали. Особенно в сравнении с тем как тут описывались извраты при тестировании работников в некоторые крупные компании. Главное это оптимизм, желание учиться и коммуницировать с людьми. Будь приветлив, не бойся выглядеть глупым, проявляй инициативу, не ленись помогать коллеге (не только в работе но и если надо в остальной жизни), учись учись и ещё раз учись, люби учёбу и все у тебя получится а люди к тебе потянутся.
Т.е. вы только лидеров набираете? И как, не грызутся между собой? Не пытаются свалить после каждой драмы?
В мире полно специалистов, вполне успешных при наличии «надзирателя с палкой». Стоят они, кстати, дешевле, не воротят нос от малоприятной работы и реже меняют работодателя.
PS. Вот за это зачёт:
В мире полно специалистов, вполне успешных при наличии «надзирателя с палкой». Стоят они, кстати, дешевле, не воротят нос от малоприятной работы и реже меняют работодателя.
PS. Вот за это зачёт:
Помним, что ведете переговоры с потенциальным партнером по бизнесу, а не пытаемся сторговать на рынке товар подешевле.
Т.е. вы только лидеров набираете?
Да. Мы набираем проактивных людей, которые прежде всего стали лидерами своей собственной судьбы.
И как, не грызутся между собой?
Грызутся. Но исключительно по поводу того, как лучше выполнить боевую задачу.
Не пытаются свалить после каждой драмы?
Нет. Некоторые бойцы работают со мной уже 15 лет. Правда, компании приходилось менять.
В мире полно специалистов, вполне успешных при наличии «надзирателя с палкой».
Вроде история уже показала, что рабский труд менее эффективен?
У разных людей в интервью разные фокусы — это очевидно зависит от целей и контекста. Важно только понимать, что нет правильного/неправильного фокуса — есть подходящий/не подходящий лично вам (как человеку — ведущему интервью), вашей конкретной компании (т.е. пропускающий кандидатов эффективных с точки зрения вложения в них денег), этому кандидату (с точки зрения того, может/не может он такое интервью пройти, и насколько оно ему будет комфортно ощущаться).
Фокусироваться на мотивации в ущерб навыкам — это, безусловно, интересная стратегия. Я вижу ее плюсы лично для меня как будущего коллеги — с мотивированными, «горящими» людьми работать приятно (и весело). Но я так же вижу ее и недостатки: далеко не все технические навыки могут быть изучены за разумный период времени. Например: изучить новый язык программирования можно за месяц. Но научиться свободно им пользоваться, интуитивно и лаконично переводя свои ментальные модели сразу в его синтаксические конструкции — нужно несколько лет минимум (и определенный склад ума — некоторые люди и на родном русском-то не могут научиться ясно выражать свои мысли). Как нанимать «за энтузиазм» человека, который не имеет этих нескольких лет опыта? Какая вероятность, что внутренне-мотивированный сотрудник продержится в компании несколько лет, прежде чем его компетенция, наконец, достигнет нужного уровня?
На мой взгляд, ориентироваться на энтузиазм тем эффективнее, чем меньший порог вхождения в вашу область работы. Скажем, на рынке есть 20% сотрудников, которые подходят вам по навыкам, и 10% подходящих по уровню мотивированности и активности жизненной позиции — очевидно, эффективнее фильтровать по жизненной позиции. А если вам подходят 5% сотрудников по навыкам, и те же 10% по горючести — эффективнее отбирать по навыкам. Простейший принцип «сначала фильтруем по признаку с наивысшей селективностью»
Фокусироваться на мотивации в ущерб навыкам — это, безусловно, интересная стратегия. Я вижу ее плюсы лично для меня как будущего коллеги — с мотивированными, «горящими» людьми работать приятно (и весело). Но я так же вижу ее и недостатки: далеко не все технические навыки могут быть изучены за разумный период времени. Например: изучить новый язык программирования можно за месяц. Но научиться свободно им пользоваться, интуитивно и лаконично переводя свои ментальные модели сразу в его синтаксические конструкции — нужно несколько лет минимум (и определенный склад ума — некоторые люди и на родном русском-то не могут научиться ясно выражать свои мысли). Как нанимать «за энтузиазм» человека, который не имеет этих нескольких лет опыта? Какая вероятность, что внутренне-мотивированный сотрудник продержится в компании несколько лет, прежде чем его компетенция, наконец, достигнет нужного уровня?
На мой взгляд, ориентироваться на энтузиазм тем эффективнее, чем меньший порог вхождения в вашу область работы. Скажем, на рынке есть 20% сотрудников, которые подходят вам по навыкам, и 10% подходящих по уровню мотивированности и активности жизненной позиции — очевидно, эффективнее фильтровать по жизненной позиции. А если вам подходят 5% сотрудников по навыкам, и те же 10% по горючести — эффективнее отбирать по навыкам. Простейший принцип «сначала фильтруем по признаку с наивысшей селективностью»
…далеко не все технические навыки могут быть изучены за разумный период времени. Например: изучить новый язык программирования можно за месяц. Но научиться свободно им пользоваться, интуитивно и лаконично переводя свои ментальные модели сразу в его синтаксические конструкции — нужно несколько лет минимум
Разумеется, но разве не эти вещи должна прояснить нормальная беседа «по душам»? Гораздо вероятнее, что человек начитается книг и постов навроде «10 скользких мест С++» и запомнит, что delete для массива надо вызывать со скобками, что такое точки следования, почитает про исключения в деструкторе например и прочую ересь. Да, про эти места он сможет что-то рассказать на собеседовании и даже может их понимать. Но разве дадут такие ответы нормальное представление о человеке как об архитекторе? Покажут ли как он мыслит? Мне кажется что нет. А раз нет, то их вполне можно обсудить среди прочего. А если и окажется что человек с этим не сталкивался, так лучше объяснить некоторые моменты и посмотреть на реакцию. Понял ли он опасность? Или смог ли по намеку дать верное предположение, что может быть «не так»?
«По душам» может быть беседа на любую тему. Именно поэтому мне странно слышать, что «10 скользких мест С++» вам как тема для беседы по душам не подходит — где же ваш эмоциональный интеллект? :-Р
Я, между прочим, серьезно: мой опыт показывает, что совершенно не важно о чем спрашивать, если копать достаточно глубоко, и слушать достаточно внимательно. «Когда человек входит в комнату — вместе с ним входит вся его жизнь» (с) Можно хоть о политической ситуации в стране говорить — и на примере этого понять, умеет ли человек вообще мыслить, в каких масштабах он способен мыслить, сколько влияющих факторов он способен учитывать в своих ментальных моделях, насколько он склонен подгонять модель под желаемый ответ, и так далее. В этом, как мне кажется, и был исходный смысл гугловских головоломок — который сейчас уже потерян из-за их заезженности, и гугл прав, что от них отказался — но идея-то по прежнему работает.
Единственная проблема возникает если человек вообще на эту тему не хочет говорить — поэтому технические вопросы спрашивать, в среднем по больнице, удобнее — к ним кандидат более-менее готов, и обычно заливается соловьем.
Я не знаю С++ головоломок, но в свое время я очень любил расспрашивать про контракт .equals() в яве (сейчас это уже не актуально, потому что многие тупо выучили) — потому что с небольшими подсказками можно догадаться, и на одном маленьком примере проявляются сразу несколько важных вещей про инженерное дело. Мне было важно видеть реакцию человека.
А в остальном — тонкость в том, что у каждого свой способ ведения интервью, который ему, очевидно, подходит, т.е. позволяет нанимать нужных людей. И это понятно: свести к минимуму процент ложно-положительных исходов можно просто перебирая разные фильтры один за одним, за счет долгого опыта. Гораздо интереснее было бы задаться комплиментарным вопросом: какой у конкретного способа процент ложно-отрицательных результатов? Сколько подходящих людей конкретный способ отсеивает? Еще одна интересная метрика качества: насколько способ воспроизводим? Можете ли вы объяснить свой метод новому коллеге, и быть уверенным, что он будет набирать плюс-минус тех же людей, что и вы?
Мне кажется, что сравнивать методы имеет смысл как раз по этим характеристикам — потому что с точки зрения бизнеса они могут оказаться гораздо важнее.
Я, между прочим, серьезно: мой опыт показывает, что совершенно не важно о чем спрашивать, если копать достаточно глубоко, и слушать достаточно внимательно. «Когда человек входит в комнату — вместе с ним входит вся его жизнь» (с) Можно хоть о политической ситуации в стране говорить — и на примере этого понять, умеет ли человек вообще мыслить, в каких масштабах он способен мыслить, сколько влияющих факторов он способен учитывать в своих ментальных моделях, насколько он склонен подгонять модель под желаемый ответ, и так далее. В этом, как мне кажется, и был исходный смысл гугловских головоломок — который сейчас уже потерян из-за их заезженности, и гугл прав, что от них отказался — но идея-то по прежнему работает.
Единственная проблема возникает если человек вообще на эту тему не хочет говорить — поэтому технические вопросы спрашивать, в среднем по больнице, удобнее — к ним кандидат более-менее готов, и обычно заливается соловьем.
Я не знаю С++ головоломок, но в свое время я очень любил расспрашивать про контракт .equals() в яве (сейчас это уже не актуально, потому что многие тупо выучили) — потому что с небольшими подсказками можно догадаться, и на одном маленьком примере проявляются сразу несколько важных вещей про инженерное дело. Мне было важно видеть реакцию человека.
А в остальном — тонкость в том, что у каждого свой способ ведения интервью, который ему, очевидно, подходит, т.е. позволяет нанимать нужных людей. И это понятно: свести к минимуму процент ложно-положительных исходов можно просто перебирая разные фильтры один за одним, за счет долгого опыта. Гораздо интереснее было бы задаться комплиментарным вопросом: какой у конкретного способа процент ложно-отрицательных результатов? Сколько подходящих людей конкретный способ отсеивает? Еще одна интересная метрика качества: насколько способ воспроизводим? Можете ли вы объяснить свой метод новому коллеге, и быть уверенным, что он будет набирать плюс-минус тех же людей, что и вы?
Мне кажется, что сравнивать методы имеет смысл как раз по этим характеристикам — потому что с точки зрения бизнеса они могут оказаться гораздо важнее.
«10 скользких мест С++» вам как тема для беседы по душам не подходит
Ну почему же :) Вполне себе тема. Другое дело, что зачастую собеседующие к этому относятся как «так. это знает. идем дальше» или «не знает. минус в карму. идем дальше». То есть, даже не пытаются поддержать беседу на эту тему. Бывали и курьезы, когда потом выяснялось, что человек по сути сам только запомнил правильные ответы и оценить может только по приницпу «услышал знакомые слова».
А так вы все верно говорите, конечно.
Всё классно в статье кроме вот этого:
Вместо повторения очередных аргументов и отсылок к гуглу, который перестал задавать подобные вопросы, я просто крайне рекомендую прочитать эту заметку от одного из главных архитекторов языка C#.
Предлагаем некорректную задачу (которая при заданных условиях имеет множество решений). Например, определить количество бензоколонок в Москве (“Как сдвинуть гору Фудзи”).
Вместо повторения очередных аргументов и отсылок к гуглу, который перестал задавать подобные вопросы, я просто крайне рекомендую прочитать эту заметку от одного из главных архитекторов языка C#.
Мне кажется, подобные вопросы нужны не для того, чтобы на них получить какой-то конкретный ответ (кого реально волнует количество бензоколонок?). Здесь интересно как кандидат начинает решать задачу, как реагирует на неопределенность требований, как строит диалог. Умение вникнуть в суть задачи, проанализировать условия, обнаружить и выяснить недостающие требования и ограничения в постановке, противоречия, — это такой же важный навык для разработчика, как и умение разбираться в технической документации. Приходит с опытом. Ведь реальной работе подобные ситуации возникают весьма часто.
В реальной работе вас часто просят решить задачу к которой вы вообще отношения не имеете? Что вы планируете услышать в ответ на подобный вопрос? Да, в реальной работе часто нужно выполнить задачу с плохо-оговоренными требованиями или даже не выполнимую, но это одна из ваших профильных задач и вы можете с этим работать. Вы можете порассуждать, и дать какой-то ответ на основании реальных данных, которыми вы владеете. А на такой вопрос я вообще не знаю как бы отреагировал. Наверное, попрощался бы. Я склонен думать, что умение с умным видом рассуждать на любую тему и убедительно «впаривать» кому-то цифры с потолка (с притянутым за уши объяснением) нужно политикам, в крайнем случае менеджерам.
возможно поэтому гугл и отказался от подобных задачек — слишком высокая степень неопределенности в задаче, слишком серьезный настрой кандитата, — все это играет злую шутку, превращая челенж в тест на стресоустойчивость. :) не нужен ответ. важен процесс. говорите не способны эффективно решить задачу? — на практике это может сэкономить кучу средств, чем если кандидат берется за любую предложенную работу. «почему вы обратились именно к специалисту по C# для подсчета бензоколонок, а не допустим в Министерство промышленности и энергетики?» прощальная истерика в качестве реакции это тоже ответ.
Да вот как-то не знаю. Когда я впервые прочитал главу об умениях быстро прикидывать (в какой это книге было?..), на меня это произвело должное впечатление. Но теперь мне кажется, что тут, скорее, дело в складе личности. Я вряд ли начну высасывать из пальца какие-то теории о количестве бензоколонок. Если вам нужен ответ, я его получу с достаточной степенью точности в течение пары часов, а к чему вам прикидки, которые, ко всему прочему, очень трудно оценить? Иными словами, мой собственный опыт не научил меня вот такому способу мышления, потому что у меня не было повода его натренировать. А в игры вида «нужна быстрая прикидка вот прямо сейчас, после обеда будет поздно» играть не приходилось.
Повсеместно цитируют пример, когда Ферми во время тестового взрыва бомбы подбросил какие-то бумажки и быстро определил по их смещению от ударной волны силу взрыва. Оно красиво, конечно, но на испытаниях присутствовало множество крайне толковых людей, но лишь у Ферми возникло желание сделать такую прикидку. Видимо, обусловлено личными склонностями.
Повсеместно цитируют пример, когда Ферми во время тестового взрыва бомбы подбросил какие-то бумажки и быстро определил по их смещению от ударной волны силу взрыва. Оно красиво, конечно, но на испытаниях присутствовало множество крайне толковых людей, но лишь у Ферми возникло желание сделать такую прикидку. Видимо, обусловлено личными склонностями.
Ок, вы объяснили, почему не спрашиваете у программистов о программировании. Однако интересно, а сможете спросить то? Не слишком ли Вы уже менеджер?
Текст выглядит как компиляция отличной статьи Джоэля Спольски (десятилетней давности) и оправданий, почему мне не нужно задать программерский вопрос разработчику а вместо этого поразмышлять о высоком.
Текст выглядит как компиляция отличной статьи Джоэля Спольски (десятилетней давности) и оправданий, почему мне не нужно задать программерский вопрос разработчику а вместо этого поразмышлять о высоком.
Это в начале, когда только начинаешь проводить интервью, хочется спросить «что-нибудь этакое», потому что еще сам как интервьюер не состоялся и хочется самоутверждения. А когда за сутки через тебя проходит по 8 кандидатов, ты понимаешь, что все эти люди не такие уж и уникальные. На ум приходит только одно сравнение — все кандидаты с большего одинаковые, как китайцы. И в этот момент приходит осознание, что умения-умениями, но если перед тобой «тяжелый», конфликтный, незнающий чего хочет от карьеры и жизни, без четкой жизненной позиции человек, не обладающий живостью ума, брать его не стоит ни при каких условиях.
У меня не такой большой опыт, как у автора статьи. Я за свою карьеру набрал около 30 разработчиков и провел около сотни собеседований. Мне кажется, 8 собеседований в день — это много. Чтобы хоть что-то узнать о человеке и что-то дать ему понять о себе, мне нужно около полутора часов. Все эти полтора часа у меня в голове ровно два вопроса Джоэля: толковый ли и доводит ли дело до конца?
И чтобы понять, толковый ли он программист, мне В ТОМ ЧИСЛЕ нужно спрашивать его о программировании.
Иногда встречаюсь с заблуждением, что все вопросы о программировании являются лишь отражением текущих знаний. Типа кандидат может их случайно знать или не знать, что ничего не говорит о качестве кандидата.
Считаю, это не так. Если человек — программист, он просто наполнен знаниями, т.к. его внутреннее любопытство — мощный двигатель узнать что-то новое. На собеседовании полтора часа можно многое что «эмулировать», но только не накопленный багаж знаний.
Просто, считаю, собеседование нужно поставить так, чтобы кандидат мог раскрыть свои знания.
И чтобы понять, толковый ли он программист, мне В ТОМ ЧИСЛЕ нужно спрашивать его о программировании.
Иногда встречаюсь с заблуждением, что все вопросы о программировании являются лишь отражением текущих знаний. Типа кандидат может их случайно знать или не знать, что ничего не говорит о качестве кандидата.
Считаю, это не так. Если человек — программист, он просто наполнен знаниями, т.к. его внутреннее любопытство — мощный двигатель узнать что-то новое. На собеседовании полтора часа можно многое что «эмулировать», но только не накопленный багаж знаний.
Просто, считаю, собеседование нужно поставить так, чтобы кандидат мог раскрыть свои знания.
Я конечно никакой не руководитель, но все же не согласен с таким подходом. Нужно как минимум не меньше внимания уделять знаниям кандидата, чем всему остальному. Ведь часто на словах он Лев Толстой, а на деле… Я бывал на некоторых собеседованиях, на которых у кандидатов были определенные пробелы в знаниях, но вроде бы огромное желание, жизненная позиция и далее по списку из статьи. Я тогда своему начальнику посоветовал дать тестовое задание. Он не послушал, «повелся» на желание и рассказы. Ничего хорошего из этого не вышло. Много идей, но мало возможностей их реализовать и сделать что-то осмысленное. В результате была набрана целая команда вот таких товарищей, которые идеи генерировали в гораздо большем количестве, чем работающий код. Бывало такое что они делали 2 недели одно, потом у них возникала другая «идея» и 2 недели работы пропадали, потому что нужно было переделывать по-другому.
Не следует брать людей, которые знают и умеют, а потом заниматься промыванием их мозгов и пытаться мотивировать их на эффективную работу. Их знания и умения ничего не будут стоить уже через полгода или год.
Коллега, кто-то отменил правило 10'000 часов? Почему я об этом не знаю? :(
В идеале, конечно, следует стараться привлечь и знающих, и умеющих, и подходящих по своим жизненным позициям. Но если приходится выбирать, то правильнее выбрать жизненную позицию. Ищем тех, кто хочет развиться и расти, а затем, если необходимо, помогаем им получить требуемые технические навыки. Предлагаем не работу, а возможности.
Правильно ли я понимаю, что вы предлагаете, чтобы сотрудники обучались за счет компании? А если не получится? «Правильное отношение к делу», по моему опыту, сабо коррелирует с умением делать программное обеспечение. Бывает, что человек хороший — а композиция, или регекспы, или базы данных, или потоки — ему не даются.
Коллега, кто-то отменил правило 10'000 часов? Почему я об этом не знаю? :(
Сугубо, ИМХО. Это правило — очередная сказка про золушку, которую так любя американцы.
10'000 чааов — это 5 лет опыта. Но опыт — он разный. Можно 5 лет поддерживать банковскую ситему. А можно за 5 лет реализовать 5 успешных проектов для разных заказчиков и на разных технологиях.
Кого будем хантинть, коллега?
Правильно ли я понимаю, что вы предлагаете, чтобы сотрудники обучались за счет компании?
Обязательно. Люди — это капитал компании и его надо наращивать.
Бывает, что человек хороший — а композиция, или регекспы, или базы данных, или потоки — ему не даются.
Помним, что «программист — не профессия, а образ мышления».
Я всегда говорил, в российском сегменте основной принцип выбора при найме — главное что бы человек был хороший, а работа не волк, в лес не убежит.
Больше хороших людей, больше псевдодеятельности у HR, все счастливы, а работа… да кому это нужно, работать…
Больше хороших людей, больше псевдодеятельности у HR, все счастливы, а работа… да кому это нужно, работать…
Мне кажется, вы немного туманно описали некоторые пункты процесса собеседования, которые могли бы дать о вас представление, как о работодателе в этом посте или быть правильно понятыми и помочь другим проводить собеседование.
Например
Что вы имеете ввиду? Под этот пункт подойдет огромный список вариантов, который заставит встать и уйти очень шокированного кандидата или это:
во-первых под этот круг задач попадает тоже огромное количество, которые могут восприниматься по-разному. А во-вторых (ИМХО) это совсем лишнее
Например
Пробуем посомневаться в чем-то очевидном для кандидата и завязать с ним дискуссию
Что вы имеете ввиду? Под этот пункт подойдет огромный список вариантов, который заставит встать и уйти очень шокированного кандидата или это:
Предлагаем некорректную задачу (которая при заданных условиях имеет множество решений). Например, определить количество бензоколонок в Москве
во-первых под этот круг задач попадает тоже огромное количество, которые могут восприниматься по-разному. А во-вторых (ИМХО) это совсем лишнее
>Целеустремленность. Если кандидат не знает, что он хочет, его не стоит брать.
Ответ «набраться опыта/знаний/связей и свалить через полгодика на зарплату побольше или в свой проект» вас устроит?
Воистину целеустремленный человек же.
Ответ «набраться опыта/знаний/связей и свалить через полгодика на зарплату побольше или в свой проект» вас устроит?
Воистину целеустремленный человек же.
По вашему, большая целеустремленность, это просиживать штаны десятилетя на одном месте в надежде на повышение? Покажите сотрудника, который не хочет повышения.
Добавлю ещё ложку про студентов. Как правило, преобладающее число студентов не знают, чего они хотят, т.к. слишком широкий выбор привлекательных областей. Выкидывать человека просто из-за того, что он ещё не определился, считаю, глупо.
На личном опыте наблюдал как студент приходил работать тестировщиком, а в итоге стал отличным менеджером. Или, наоборот, приходили на менеджера, а в итоге становились высококлассными разработчиками.
Ещё раз подведу итог: на мой взгляд, это не верный шаг: не брать, если человек ещё не определился.
На личном опыте наблюдал как студент приходил работать тестировщиком, а в итоге стал отличным менеджером. Или, наоборот, приходили на менеджера, а в итоге становились высококлассными разработчиками.
Ещё раз подведу итог: на мой взгляд, это не верный шаг: не брать, если человек ещё не определился.
del
В той же книге МЧМ, было интересное наблюдение. Успешные проекты бывают двух типов:
Финансово успешные
Технически успешные
И они не всегда коррелируют.
Я встречал людей, которые ждут в резюмэ программиста, список финансово успешных проектов.
Финансово успешные
Технически успешные
И они не всегда коррелируют.
Я встречал людей, которые ждут в резюмэ программиста, список финансово успешных проектов.
За эти годы мне пришлось провести более тысячи интервью и посчастливилось захантить больше сотни классных программистов
Можно сделать вывод что около 10% людей вам подходили? Это либо невероятная удача, либо программисты не очень то и классные, по моему опыту 2-3% уже практически недостижимое счастье.
Пособеседовав как-то нескольких не слишком удачных кандидатов, я чуть
было не пришёл к следующему алгоритму собеседований:
1. Спрашиваем кандидата, каково двоичное представление числа 255
2. Получив ответ типа «не знаю» или «7 единиц», сразу бьём в табло
3. В случае правильного ответа продолжаем беседу
Это, конечно, очень неправильно, да и по-хорошему от этого помогает
phone screening, но как-то уж совсем утомили люди, которые даже не знают,
что такое байт, и при этом хотят немало денег…
было не пришёл к следующему алгоритму собеседований:
1. Спрашиваем кандидата, каково двоичное представление числа 255
2. Получив ответ типа «не знаю» или «7 единиц», сразу бьём в табло
3. В случае правильного ответа продолжаем беседу
Это, конечно, очень неправильно, да и по-хорошему от этого помогает
phone screening, но как-то уж совсем утомили люди, которые даже не знают,
что такое байт, и при этом хотят немало денег…
И каково двоичное представление числа 255?
Сами догадайтесь. Подсказывать не буду.
Да ладно, я же на работу к вам не набиваюсь )
11111111, только не говорите никому. 0b11111111, если в терминах C.
Хорошо, я облажался, первой мыслью было 8 бит и единицы не хватает до 256.
Вы сразу в табло бьёте, как только человек заикнулся про 7 единиц?
Вы сразу в табло бьёте, как только человек заикнулся про 7 единиц?
Ну, что Вы. Мы общаемся с людьми предельно вежливо. Насчёт «в табло» — это лишь грустная шутка о моих внутренних переживаниях по этому поводу. Но вот как вы думаете, стоит 100k+, например, платить человеку, который не знает про байты, никогда в жизни не слышал слова «граф» (не считая Дракулы), не знает, чем Subversion отличается от Github (не git, а именно система контроля версий от сервиса github) и т.д? Каковы будут Ваши чувства, когда такой человек начинает бурно возмущаться, получив предельно вежливый отказ?
Никому не говорить… а если вдруг спросят… на собеседовании? Можно на вас ссылаться?)
а 255 это в какой системе исчисления? :)
>сразу бьём в табло
Название компании пожалуйста, чтобы не дай Б-г к Вам не зайти, мне мое «табло» знаете ли еще дорого.
>но как-то уж совсем утомили люди, которые даже не знают, что такое байт, и при этом хотят немало денег
Это рынок. Есть спрос, предложение, цена. Если человек не устраивает — идите мимо и не утомляйтесь. Если в магазине на прилавке лежит ненужный Вам товар за «немало денег», Вы идете бить в табло продавцу или просто проходите мимо/идете в другой магазин? Если первое, то у меня для Вас плохие новости, проблема не в «не слишком удачных кандидатах».
Название компании пожалуйста, чтобы не дай Б-г к Вам не зайти, мне мое «табло» знаете ли еще дорого.
>но как-то уж совсем утомили люди, которые даже не знают, что такое байт, и при этом хотят немало денег
Это рынок. Есть спрос, предложение, цена. Если человек не устраивает — идите мимо и не утомляйтесь. Если в магазине на прилавке лежит ненужный Вам товар за «немало денег», Вы идете бить в табло продавцу или просто проходите мимо/идете в другой магазин? Если первое, то у меня для Вас плохие новости, проблема не в «не слишком удачных кандидатах».
Хм, я где-то сказал, что это всерьёз практикуется? Поясню, "я чуть было не пришёл" к такой практике — означает лишь мои личные чувства по отношению к таким кандидатам. Если Вы придёте к нам, не зная элементарных вещей, мы поговорим с Вами вполне вежливо, никто не будет бить Вас стулом или отправлять в нецензурной форме. Просто это как-то немного нехорошо, тратить своё и чужое время; всё-таки в вакансии сказано «программист», а не «оператор ПК». Беда в том, что, действительно, рынок. Есть конторы, которые готовы платить большие деньги подобным «гениям». Хуже того, подозреваю, немало таких контор, которые не видят разницы между такими «гениями» и людьми, которые действительно умеют программировать; и всё это, боюсь, весьма отрицательно влияет на саму вероятность найти приличных разработчиков.
Удивляет почему вполне здравая позиция собеседующего при выборе того или иного шлак-фильтра вызывает негативную реакцию.
С другой стороны — в IT и в программировании много людей, а выбрать не из кого — либо человек плотно женат на своей работе, либо он и почти даром не нужен (думаю не надо пояснять, что это квинтэссенция мнения, а не формат общения с таким кандидатом). И не важно, как садится с кандидатом на собеседовании — через стол или рядом и за ручку его держать, тем более, если кандидат должен быть проактивный, то ему не страшны такие микрострессы. В противном случае у меня такое поведение кандидата вызывает когнитивный диссонанс.
Т.е казалось бы концентрация и высокая, да температура этого it-газа мала.
С другой стороны — в IT и в программировании много людей, а выбрать не из кого — либо человек плотно женат на своей работе, либо он и почти даром не нужен (думаю не надо пояснять, что это квинтэссенция мнения, а не формат общения с таким кандидатом). И не важно, как садится с кандидатом на собеседовании — через стол или рядом и за ручку его держать, тем более, если кандидат должен быть проактивный, то ему не страшны такие микрострессы. В противном случае у меня такое поведение кандидата вызывает когнитивный диссонанс.
Т.е казалось бы концентрация и высокая, да температура этого it-газа мала.
Я думаю, негативную реакцию вызывает скорее использованная фигура речи. Видимо, у кого-то она могла всколыхнуть скрытые фобии, связанные со стрессом от экзаменов и собеседований, и шутку приняли всерьёз. А может быть, здесь действительно много людей, которые считают нормальным незнание подобных азов. Сказать об этом многие стесняются, а вот анонимно минус поставить — это не стыдно, это в самый раз.
В полушутку у нас был шлак-фильтр, который применил только один раз, когда кандидат стал кичиться своим почти красным дипломом — посчитать определитель матрицы 2x3.
Мы выделили три принципиальных ответа:
— начинает считать — таких до свидания
— его нельзя посчитать — с такими можно дальше общаться и потенциально он пройдет все этапы
— кандидат бьет сразу в табло — потенциально кандидат в нашу команду.
Не воспринимайте серьёзно и буквально.
Мы выделили три принципиальных ответа:
— начинает считать — таких до свидания
— его нельзя посчитать — с такими можно дальше общаться и потенциально он пройдет все этапы
— кандидат бьет сразу в табло — потенциально кандидат в нашу команду.
Не воспринимайте серьёзно и буквально.
Володя, опомнись — хватит уже все секреты-то выдавать! И так ты уже половину наших секретных техник всем раструбил — как теперь жажду власти удовлетворятьсобеседовать-то?
Не могу даже представить, как реагировать на такой вопрос. Либо рассмеяться, либо мрачно сказать «очень смешно»? Или решить, что это они спрашивают серьёзно, а я ошибся адресом?
Вот когда тебе такого типа вопрос на собеседовании задают — не знаешь, как реагировать. А вот когда ты сам в роли собеседующего, и видишь кандидата с высшим техническим, с неплохим резюме, который сидит перед тобой, и уже третью минуту не может посчитать 2500 * 200 (я не специально арифметику спрашивал, просто нужно было что-то оценить по ходу решения задачи), причем он уже выдал два варианта, которые даже по порядку не сходились — тут тоже не знаешь, как реагировать. Правда, очень неловко было — я совершенно не представлял, как человеку здесь можно помочь, потому что не представлял, в чем здесь может быть затык вообще. Ну не учить же мне выпускника технического вуза счету в уме?
Отсюда и растут ноги всяких странных вопросов — повидаешь несколько таких случаев, и начинаешь на молоко дуть.
Отсюда и растут ноги всяких странных вопросов — повидаешь несколько таких случаев, и начинаешь на молоко дуть.
UFO just landed and posted this here
В самом деле, интересно. Если человек приходит на вакансию, в которой указано «требуется ВО по специальности математика или физика», а на собеседовании не может решить даже обыкновенное дифференциальное уравнение, объясняя это тем, что после универа ему не приходилось этим заниматься — это слишком плохо?
Это не просто плохо. это смертельно плохо.
UFO just landed and posted this here
Если в вакансии написано что требуется какие-то специальные знания, то они наверняка ожидают кандидата который не когда-то там знал их, а знает в настоящий момент и использует т.е. в теме.
Если вы уже давно не считали определители матриц, то явно для этих целей используете специальные программы и на вопрос «как» отвечать тогда «с помощью такой-то программы», если работодателя это не устроит — пусть тогда ищет дальше кандидатов умеющих вручную обсчитывать матрицы 10x10 и выше. Если у вас действительно математическое образование и оно актуально то думаю довольно сложно забыть такие вещи как вычисление определителя матрицы для 2x2 или 3x3, чего будет достаточно для демонстрации работодателю.
Если вы уже давно не считали определители матриц, то явно для этих целей используете специальные программы и на вопрос «как» отвечать тогда «с помощью такой-то программы», если работодателя это не устроит — пусть тогда ищет дальше кандидатов умеющих вручную обсчитывать матрицы 10x10 и выше. Если у вас действительно математическое образование и оно актуально то думаю довольно сложно забыть такие вещи как вычисление определителя матрицы для 2x2 или 3x3, чего будет достаточно для демонстрации работодателю.
>1. Спрашиваем кандидата, каково двоичное представление числа 255
Со знаком или без?
Со знаком или без?
Больше похоже на подъебку, а не на вопрос на собеседовании по вакансии «программист».
Возможно мне просто сложно представить, что на собеседование могут приходить такие персонажи.
Таки поделитесь опытом, какой у вас реальный алгоритм собеседования, хотя бы на первых этапах.
Возможно мне просто сложно представить, что на собеседование могут приходить такие персонажи.
Таки поделитесь опытом, какой у вас реальный алгоритм собеседования, хотя бы на первых этапах.
Вопрос почти тот же, что и здесь blog.gamedeff.com/?p=64
Ну, вот приходят. Причём когда-то я дотнетчиков собеседовал, полно таких было. Как сейчас помню решение тестового задания по ASP.NET, в котором MessageBox для подтверждения на сервере рисовался (т.е. надо было зайти на сервер по RDP/VNC/etc. для подтверждения удаления записи) — автор просто этого не осознал, т.к. разрабатывал локально, а чёткой границы между GUI и веб-страницами не чувствовал. Сейчас вот собеседуем по Python'у, линухам, etc. — и здесь «умных» столько же, хотя лет 6-10 назад часто сам интерес к опенсорсу означал, что человек «в теме», сейчас уже таких гарантий нет… Видимо, Linux как платформа действительно дозрел до своей популярности.
Собственно, исходя из предварительных знаниях о кандидате (резюме, тестовое задание, если отправляли, или github account, etc.) в той или иной степени детально рассказываю о системе, над которой человеку предстоит работать. Если заранее есть ощущение, что товарищ не очень, много времени на это тратить не стоит, как говорится в известном высказывании насчёт бисера. Если же есть вероятность, что перед нами — приличный разработчик, то лучше рассказать поподробнее (но чтобы не утомлять), акцентируя интересные моменты. Далее обычно интересуюсь у кандидата, чем ему приходилось заниматься последнее время (если это не секрет), и почему он больше этим заниматься не хочет. Также, по возможности, интересуюсь более ранней работой.
Далее, собственно, технические вопросы. Начинаем с идиотских. Затем — про особенности используемого языка программирования; по алгоритмам и структурам данных. Сильно глубоких знаний в этой области обычно мы не требуем, но какое-то представление должно быть. Ок, если человек сможет придумать какое-то годное решение для задач, стандартных решений которых он не знает/не помнит (топологическая сортировка, например — хотя её уж и знать то совсем не грех, но, по крайней мере, за неё в табло бить не стоит). Спрашиваем обычные вещи про паттерны (какие знаете и что про них можете сказать), базы данных, etc. Говорим про используемые в разработке инструменты — IDE или не-IDE (vim/emacs/etc.), системы контроля версий, багтрекеры etc. Разумеется, во всех случаях делается скидка на то, что человек может волноваться и из-за этого тупить на собеседовании; тем не менее, в некоторых случаях ясно, что человек именно ноль по тем или иным обширным разделам программерских знаний. Бывает много вопросов, на которые человек с более-менее адекватным программерским опытом в интересующей нас сфере отвечает сразу и не задумываясь — такие вопросы особенно показательны.
Обычно я себя спрашиваю — сколько лет назад мой уровень знаний был как у данного кандидата (или сколько лет пройдёт, прежде чем я достигну уровня кандидата — но это, к сожалению, реже, чем хотелось бы), бывает, это тоже помогает принять решение.
Сейчас хороший показатель, мне кажется, наличие в резюме github'а с приличным содержимым + интерес к Лиспам, Эрлангам, ФЯ и тому подобным немейнстримовым технологиям (в меру, видимо). Обычно это означает, что кандидату интересно программирование само по себе, и он не считает его лишь одним из возможных способов заработка и не более того. Сколько приходилось общаться с приличными разработчиками — почти все в той или иной степени интересовались подобными «необщепринятыми» вещами.
Насчёт компенсации и прочих условий — в конце собеседования (если в этом есть смысл).
Собственно, исходя из предварительных знаниях о кандидате (резюме, тестовое задание, если отправляли, или github account, etc.) в той или иной степени детально рассказываю о системе, над которой человеку предстоит работать. Если заранее есть ощущение, что товарищ не очень, много времени на это тратить не стоит, как говорится в известном высказывании насчёт бисера. Если же есть вероятность, что перед нами — приличный разработчик, то лучше рассказать поподробнее (но чтобы не утомлять), акцентируя интересные моменты. Далее обычно интересуюсь у кандидата, чем ему приходилось заниматься последнее время (если это не секрет), и почему он больше этим заниматься не хочет. Также, по возможности, интересуюсь более ранней работой.
Далее, собственно, технические вопросы. Начинаем с идиотских. Затем — про особенности используемого языка программирования; по алгоритмам и структурам данных. Сильно глубоких знаний в этой области обычно мы не требуем, но какое-то представление должно быть. Ок, если человек сможет придумать какое-то годное решение для задач, стандартных решений которых он не знает/не помнит (топологическая сортировка, например — хотя её уж и знать то совсем не грех, но, по крайней мере, за неё в табло бить не стоит). Спрашиваем обычные вещи про паттерны (какие знаете и что про них можете сказать), базы данных, etc. Говорим про используемые в разработке инструменты — IDE или не-IDE (vim/emacs/etc.), системы контроля версий, багтрекеры etc. Разумеется, во всех случаях делается скидка на то, что человек может волноваться и из-за этого тупить на собеседовании; тем не менее, в некоторых случаях ясно, что человек именно ноль по тем или иным обширным разделам программерских знаний. Бывает много вопросов, на которые человек с более-менее адекватным программерским опытом в интересующей нас сфере отвечает сразу и не задумываясь — такие вопросы особенно показательны.
Обычно я себя спрашиваю — сколько лет назад мой уровень знаний был как у данного кандидата (или сколько лет пройдёт, прежде чем я достигну уровня кандидата — но это, к сожалению, реже, чем хотелось бы), бывает, это тоже помогает принять решение.
Сейчас хороший показатель, мне кажется, наличие в резюме github'а с приличным содержимым + интерес к Лиспам, Эрлангам, ФЯ и тому подобным немейнстримовым технологиям (в меру, видимо). Обычно это означает, что кандидату интересно программирование само по себе, и он не считает его лишь одним из возможных способов заработка и не более того. Сколько приходилось общаться с приличными разработчиками — почти все в той или иной степени интересовались подобными «необщепринятыми» вещами.
Насчёт компенсации и прочих условий — в конце собеседования (если в этом есть смысл).
Да, раньше я даже в случае слабых кандидатов старался поподробнее рассказать об ответах на все вопросы, с которыми кандидат не справился. Как правило, люди даже в случае отказа уходили довольными, т.к. узнавали много полезного. Сейчас тоже бывает, но уже, к сожалению, в заметно меньшей степени — времени жалко, да и озверел несколько, наверное. Но, мне кажется, в принципе практика неплохая.
Вопрос из разряда «назовите мне целочисленный остаток от деления 89238742 на 17».
Понимаете, исходя из введения празднования Дня Программиста, можно предположить, что с неплохой вероятностью ответ на мой вопрос знает даже бывший президент Медведев. Ну, если не двоичное представление 255, то хотя бы то, что 256 — это 28. А уж если даже Медведев знает, при том, что он не программер, то уж, наверное, программерам-то это знать совсем не грех?
Как только я пойму, зачем это, я сразу соглашусь с вашими аргументами. Зачем программеру знать английский, уметь гуглить — я знаю. Зачем ему иметь кругозор в алгоритмах и парадигмах разработки — тоже. Знаю даже, зачем ему нужно быть нормальным компанейским парнем. Но вот зачем ему может понадобится банальная арифметика, при том, что калькуляторы никто не отменял — понять никак не могу. Это какой-то атавизм традиционной системы образования (когда знание = набор фактов), а не полезное умение. А уж всерьез устраивать из этого критерий при отборе — ну извините…
Например, может потребоваться быстро понять, что означает какое-то число, которое вдруг выдала программа. Переменная вдруг приняла значение 255. Вычисленное расстояние отличается от правильного в 1.00029 раза. Или в 5280 раз. Время — на 86400 больше, чем надо. Или вылезло какое-нибудь 0.866… Как поможет калькулятор узнать константу? Да, гугл или вольфрамовская альфа могут ответить. Но обращение к ним — лишнее сознательное действие, которое явно повредит интуитивным этапам поиска ошибки…
Попробуйте целочисленное переполнение на фоне незнания степеней двух и тому подобной никому не нужной мути. Ну, скажем, в каком-то протоколе 16-битовым беззнаковым целым кодируется некое значение. Вдруг вместо 65536 получаем 0 — вот блин, что бы это могло значить? Мистика какая-то. Если, конечно, не знать, как оно могло произойти на уровне интуиции. А подобные косяки с переполнениями, которых человек без знаний битов-байтов может наделать несознательно и не только в разного рода низкоуровневых приложениях, могут быть и дырами в безопасности, и причиной потери данных… Как-то даже был случай, что подобная ошибка была одной из причин сбоев, приведших к смертям — см. Therac-25. Конечно, большинство программистов вряд ли имеет возможность напортачить так, чтобы кто-то умер, но вот чтобы пропало много денег и времени — это без проблем.
Будучи студентом, я как-то прогулял пару семинаров по матмоделированию, по возвращению меня ждал 4х мерный аттрактор Лоренца — на резонный вопрос — wat! мне преподаватель рассказал, как Лоренц в докомпьютерную эпоху исследовал трехмерные аттракторы — он просто переходил в n+1 мерное пространство, прокалывал его и получал точку в 3х мерном пространстве
Интуиция на уровне чувствовать байт каждым битом, способностью понять что же пошло не так в считанные секунды в 3 часа ночи не важно в каком состоянии вы были накануне — я слышал куда более волнующие истории от отцов советско-российской космической программы.
Негоже устраивать истерики серьезным донам.
Интуиция на уровне чувствовать байт каждым битом, способностью понять что же пошло не так в считанные секунды в 3 часа ночи не важно в каком состоянии вы были накануне — я слышал куда более волнующие истории от отцов советско-российской космической программы.
Негоже устраивать истерики серьезным донам.
Собеседование на должность, требующую написания кода без, собственно, написания кода в каком-либо виде — не очень хорошая идея. Такой подход, наверное, хорош для кадровых агенств, которым достаточно «протолкнуть» кандидата и забыть про него. Считаю тестовое задание (возможно «домашнее») обязательным. Красиво вешать лапшу на уши, уж извините за такое выражение, можно научиться менее чем за неделю. А навыки кодирования очень хорошо всплывают даже на пустяковых задачах, требующих 5-15 минут времени на реализацию.
Да, это здорово, когда кандидат целеустремлен, успешно поучавствовал в десятке стартапов и расфоркал 15 проектов на гитхабе, но при всем этом он может оказаться языкастым балластом в команде.
Да, это здорово, когда кандидат целеустремлен, успешно поучавствовал в десятке стартапов и расфоркал 15 проектов на гитхабе, но при всем этом он может оказаться языкастым балластом в команде.
У меня относительно недавно было несколько кандидатов с очень пхорошо подвешенным языком и, явно, с опытом прохождения интервью. Всё выглядело замечательно, пока человека не просили написать простейший кусок кода (ну, что-то на уровне развернуть массив задом наперёд). После этого становилось очевидно: человек общаться умеет, а программировать — нет. Так что без проверки уровня умений у меня никак не получится.
Я кстати никогда не понимал. Почему, например, production server — это по-нашему обычно «боевой сервер». С кем-то всё воюем :) Архитекторы домов, интересно, тоже воюют постоянно, или это психология только в программировании почему-то прижилась?
Не у всех, у кого-то обычно зовётся «продом» или «промом», сокращениями. Очень было не привычно, на прошлых местах тоже звали боевыми.
А на мой взгляд, в термине «боевой» есть несколько приятных моментов:
1. Продажа ПО (да и вообще продажи) во многом похожа на войну, ведь конкурентов никто не отменял. И тут у нас есть кмб (тестовый сервер) и боевая обстановка, где всё может меняться достаточно быстро и нужно реактивно принимать решения.
2. Этот пункт, лично мне, даже более дОрог: просто весёлое скрашивание и без того скучного мира терминов, преобладающее число которых навязывается из-за бугра. Я люблю игры, очень. И мне приятнее работать, принимая всё как игру (не в буквальном смысле) — просто веселее и охотнее работать. Т.е. на самом-то деле совершенно всё-равно как вы назовёте розу (по мотивам Шекспира) — в данном случае, главное, чтобы было понятно команде и приятно использовать принятое название.
p.s. Каждый день война (Собаки Качалова)
1. Продажа ПО (да и вообще продажи) во многом похожа на войну, ведь конкурентов никто не отменял. И тут у нас есть кмб (тестовый сервер) и боевая обстановка, где всё может меняться достаточно быстро и нужно реактивно принимать решения.
2. Этот пункт, лично мне, даже более дОрог: просто весёлое скрашивание и без того скучного мира терминов, преобладающее число которых навязывается из-за бугра. Я люблю игры, очень. И мне приятнее работать, принимая всё как игру (не в буквальном смысле) — просто веселее и охотнее работать. Т.е. на самом-то деле совершенно всё-равно как вы назовёте розу (по мотивам Шекспира) — в данном случае, главное, чтобы было понятно команде и приятно использовать принятое название.
p.s. Каждый день война (Собаки Качалова)
С пользователями воюет… часто в неравной борьбе.
Если по-занудствовать, то не всё боевое участвует в войне — многое для случая войны. Т.е. если будет война — будет использоваться, если не будет, то не будет.
А если более по делу:
production server — скучно
боевой сервак — веселее (:
Проще ко всему относиться надо.
А если более по делу:
production server — скучно
боевой сервак — веселее (:
Проще ко всему относиться надо.
Статья хорошая.
Однако, я не считаю, что отсутствие экзамена на собеседовании это хорошо.
Безусловно, без разговора с кандидатом по вопросам, приведенным в статье, собеседование будет однобоким.
Есть высокий риск взять не того человека. Но текущий уровень знаний (или опыт) все же сильно влияет на начальный
уровень компенсации. Наличие «олимпиадных» задачек, позволяет проверить IQ кандидата.
Да, 50% успеха в работе зависит от EQ, но вторые-то 50% от IQ!!! ;-)
Беседа «за жизнь» обязательна, кандидат прежде всего должен хотеть работать.
И на собеседовании нам нужно понять хотим ли мы с ним работать, как с человеком.
Второе — проверка знаний и соображалки, которая позволяет вычислить размер компенсации и наших ожиданий.
Я на собеседовании всегда предлагаю решить тестовые задачи. Причем, кандидаты сначала решают их, а потом мы общаемся.
Начинаем с обсуждения решений. Если по задачам все тухло, то общение «за жизнь» укорачивается.
P.S. Был один кандидат (из полутора сотен), который отказался решать задачи. Но я не жалею — я не потратил время.
Сама его «несговорчивость» говорит против него — в работе он тоже от чего-то отказался бы, посчитав зазорным.
Зачем компании такой привередливый сотрудник? Да, я уважаю его позицию, он может быть владельцем или руководителем
компании, а сотрудники такие не нужны.
Однако, я не считаю, что отсутствие экзамена на собеседовании это хорошо.
Безусловно, без разговора с кандидатом по вопросам, приведенным в статье, собеседование будет однобоким.
Есть высокий риск взять не того человека. Но текущий уровень знаний (или опыт) все же сильно влияет на начальный
уровень компенсации. Наличие «олимпиадных» задачек, позволяет проверить IQ кандидата.
Да, 50% успеха в работе зависит от EQ, но вторые-то 50% от IQ!!! ;-)
Беседа «за жизнь» обязательна, кандидат прежде всего должен хотеть работать.
И на собеседовании нам нужно понять хотим ли мы с ним работать, как с человеком.
Второе — проверка знаний и соображалки, которая позволяет вычислить размер компенсации и наших ожиданий.
Я на собеседовании всегда предлагаю решить тестовые задачи. Причем, кандидаты сначала решают их, а потом мы общаемся.
Начинаем с обсуждения решений. Если по задачам все тухло, то общение «за жизнь» укорачивается.
P.S. Был один кандидат (из полутора сотен), который отказался решать задачи. Но я не жалею — я не потратил время.
Сама его «несговорчивость» говорит против него — в работе он тоже от чего-то отказался бы, посчитав зазорным.
Зачем компании такой привередливый сотрудник? Да, я уважаю его позицию, он может быть владельцем или руководителем
компании, а сотрудники такие не нужны.
Да, 50% успеха в работе зависит от EQ, но вторые-то 50% от IQ!!! ;-)
А вот и не так!
Эффективность E = IQ*EQ^2
Соглситесь, что по этой формуле EQ уже не 50, а где-то уже 80% успеха.
ЗЫ. Говорю о наболевшем. У самого IQ — сверхвысокий, а EQ — чуть выше среднего. Но! Плохая новость — IQ формируется где-то к 14 годам и дальше не растет. Хорошая новость — EQ можно увеличивать всю жизнь.
Прежде чем согласиться с результатом, полученным по этой формуле, неплохо бы понять, откуда вы вообще эту формулу взяли, какая модель эффективности за ней стоит, и какова статистическая значимость ее экспериментальных подтверждений. А так же пару-тройку альтернативных моделей, с их экспериментальными подтверждениями.
Например, по моему опыту в команде достаточно одного-двух человек с хорошими коммуникативными талантами — они легко компенсируют традиционный недостаток таких талантов у остальных. Причем эту роль вполне может занимать «играющий менеджер»
Например, по моему опыту в команде достаточно одного-двух человек с хорошими коммуникативными талантами — они легко компенсируют традиционный недостаток таких талантов у остальных. Причем эту роль вполне может занимать «играющий менеджер»
Если принять эту формулу за истину, то выходит, что IQ нужно обязательно тестировать, т.к. его прокачать нельзя :)
А раз EQ можно прокачать, то сгодится кандидат со средним EQ, но с потенциалом роста этого EQ ;-)
А раз EQ можно прокачать, то сгодится кандидат со средним EQ, но с потенциалом роста этого EQ ;-)
Отвечу цитатой. Тестировать IQ, имхо, нет необходимости. Поскольку
А CBOSS такое тестирование было, Из практики отдельный бойцы с IQ=110 были полезнее, чем бойцы с IQ=125.
… уровень IQ и эффективность левого полушария, возможности которого подтверждены, как правило, дипломом о высшем образовании и всем успешным опытом предыдущей работы.
А CBOSS такое тестирование было, Из практики отдельный бойцы с IQ=110 были полезнее, чем бойцы с IQ=125.
О, оказывается аналогии типа программисты-бойцы — не только в той фирме где я работаю. У нас был начальник, которой реально заканчивал совещания громогласным «ну, бойцы, в атаку!». Теперь начальник сменился, но и этот оказался непрост — он думает, что мы команда полётной подготовки и пилоты, а наш продукт — это лайнер, который мы готовим к отлёту и начинает митинги вопросами типа «ну как, можно объявлять посадку?» Я всё ему хочу видео показать, где самолёт достраивают прямо в воздухе, но, боюсь обидится. У Касперского, небось, программисты работают как на трассе формулы-1. Оказывается такое не так уж редко встречается.
Вот читаешь такие статьи, в которых все слаааааденько-сладенько — кандидат — это партнер по бизнесу, каждый человек уникален, о боже — пятнышко на бренде компании, мы предоставляем возможность стать победителями, бла-бла-бла. А потом смотришь — автор менеджерил в таких эпических компаниях как CBOSS, Luxoft и PWC и какое-то другое впечатление складывается…
Может быть именно поэтому и менджерил, но больше нет желания там быть? (это мое личное предположение)
Возможно. Но вот это как раз и самое интересное — то, как и почему реальные люди, которые знают, что вообще-то каждый человек уникален, приходят к тому стилю управления, который принят в этих компаниях. И как они от него уходят.
А просто декларация того, что «нуууу, надо не забывать, что для собеседуемого это стресс и помнить, что цель — отобрать эффективного бойца» малополезна для реального мира.
А просто декларация того, что «нуууу, надо не забывать, что для собеседуемого это стресс и помнить, что цель — отобрать эффективного бойца» малополезна для реального мира.
Ну вообще-то в большинстве крупных компаний официально именно такие ценности и провозглашаются. Другое дело, что для российских компаний (я бы сказал — для составляющих их людей) такого рода ценности — это, пока что, не выстраданная ими самими реальность, а купленная у западных коучей модная тряпка, про которую толком никто не понимает, за что там вообще деньги-то заплачены, и что именно в ней такого хорошего, кроме того, что модно.
Куда слать резюме?!
Потрясающе!
После многих лет собеседования и тестирования кандидатов у нас сейчас есть очень простой тест в нашем офисе. После предварительного телефонного разговора я заранее уведомляю кандидата об этом тесте и его условиях, чтобы он мог подготовится и взять с собой флешки со всем необходимым. Готовиться к тесту он может сколько угодно.
Как проходит сам тест:
Кандидат приходит в начале рабочего дня, в отдельном кабинете ему предоставляется абсолютно «голая» с отформатированным винтом, мощная рабочая станция с двумя мониторами, подключенная к сети, а так же листок бумаги на котором есть все необходимые данные о подключении к интернету, доступ к репозитарию очень простого тестового проекта, тестовому аккаунту в системе управления проектом и т.д.
Его задача ВСЕ СДЕЛАТЬ САМОСТОЯТЕЛЬНО: установить со своей флешки свой любой линукс, установить свою любимую IDE для PHP и JS + минимальный набор программ. Сконфигурировать локальный веб сервер и БД, подключится к репо и развернуть локальную копию тестового проекта и показать как он будет решать пару простых задач из тестового багтрекера — навыки отладки PHP и JS и базовые практические знания верстки. В процессе этого теста кандидату можно сколько угодно раз выходить из офиса и возвращаться если он что-то забыл дома.
Если он закончит в течении первого дня и покажет в конце дня необходимые навыки — однозначно берем на высокую зарплату, если справится на второй день — тоже берем, но с оговорками. Если на выполнение этой задачи требуется больше времени, скорее всего кандидат не может это сделать в принципе и такой человек нам не подходит.
Этот тест не требует от нас много времени, разве что только завести/вывести кандидата из офиса и посмотреть на его результаты (если они есть).
После ознакомления с условиями теста примерно две трети отказываются сразу, еще одна треть отсеивается на прохождении.
К сожалению этот тест за последние два года прошли всего трое человек (т.е примерно один из пятидесяти) и успешно работаю у нас.
мне пришлось провести более тысячи интервью и посчастливилось захантить больше сотни классных программистовТ.е. примерно каждый десятый кандидат вам подходит — мне бы так!
После многих лет собеседования и тестирования кандидатов у нас сейчас есть очень простой тест в нашем офисе. После предварительного телефонного разговора я заранее уведомляю кандидата об этом тесте и его условиях, чтобы он мог подготовится и взять с собой флешки со всем необходимым. Готовиться к тесту он может сколько угодно.
Как проходит сам тест:
Кандидат приходит в начале рабочего дня, в отдельном кабинете ему предоставляется абсолютно «голая» с отформатированным винтом, мощная рабочая станция с двумя мониторами, подключенная к сети, а так же листок бумаги на котором есть все необходимые данные о подключении к интернету, доступ к репозитарию очень простого тестового проекта, тестовому аккаунту в системе управления проектом и т.д.
Его задача ВСЕ СДЕЛАТЬ САМОСТОЯТЕЛЬНО: установить со своей флешки свой любой линукс, установить свою любимую IDE для PHP и JS + минимальный набор программ. Сконфигурировать локальный веб сервер и БД, подключится к репо и развернуть локальную копию тестового проекта и показать как он будет решать пару простых задач из тестового багтрекера — навыки отладки PHP и JS и базовые практические знания верстки. В процессе этого теста кандидату можно сколько угодно раз выходить из офиса и возвращаться если он что-то забыл дома.
Если он закончит в течении первого дня и покажет в конце дня необходимые навыки — однозначно берем на высокую зарплату, если справится на второй день — тоже берем, но с оговорками. Если на выполнение этой задачи требуется больше времени, скорее всего кандидат не может это сделать в принципе и такой человек нам не подходит.
Этот тест не требует от нас много времени, разве что только завести/вывести кандидата из офиса и посмотреть на его результаты (если они есть).
После ознакомления с условиями теста примерно две трети отказываются сразу, еще одна треть отсеивается на прохождении.
К сожалению этот тест за последние два года прошли всего трое человек (т.е примерно один из пятидесяти) и успешно работаю у нас.
А много желающих проходить 1-2 дня тест (это не считая собеседования)? Или зарплата ДЕЙСТВИТЕЛЬНО такая, причем оговаривается заранее, что кандидаты готовы на вас убить столько времени?
Т.е, сама по себе идея имеет право на жизнь наверное, но с оговорками.
Т.е, сама по себе идея имеет право на жизнь наверное, но с оговорками.
Или зарплата ДЕЙСТВИТЕЛЬНО такая, причем оговаривается заранее, что кандидаты готовы на вас убить столько времени?Все именно так и обстоит, зарплата действительно высокая и оговаривается заранее. Условия теста тоже как видите четкие и прозрачные, никакого обмана или попытки заработать на тестовом задании. Что же касается времени, то при соотв. подготовке установить и сконфигурировать систему и остальное ПО + развернуть тестовый проект я и да и любой другой из нашего коллектива сможет и за более короткое время. Недавно я сделал подобную работу на «выезде» после выхода из строя компа у заказчика часа за три. А рекорд нашего офиса именно по этому тесту — 57 минут на все, причем это в основном ограничения по скорости работы железа — ну нельзя быстрее все необходимое скопировать на диск и выкачать по сети!
Да нет, развернуть систему дело не такое уж мудрёное.
Там упоминалось ещё правка багов в проекте, это вряд ли бы в 57 минут впихнуть удалось бы.
Там упоминалось ещё правка багов в проекте, это вряд ли бы в 57 минут впихнуть удалось бы.
Про баги — просто требуется показать, что умеешь установить и использовать любой PHP дебагер в своей IDE и любой на выбор набор инструментов разработчика в любом браузере чтобы дебажить JS.
Т.к. большинство кандидатов несмотря на вполне себе уверенные теоретические знания не умеют использовать например такую элементарную, но очень полезную вещь при отладке как условный брейкпоинт, т.е. все еще хуже — они даже понятия не имеют о такой возможности!
Т.к. большинство кандидатов несмотря на вполне себе уверенные теоретические знания не умеют использовать например такую элементарную, но очень полезную вещь при отладке как условный брейкпоинт, т.е. все еще хуже — они даже понятия не имеют о такой возможности!
А вы знаете коллега, чем кустарное производство отличается от промышленного?
При кустарном производстве ремесленник приходит со своим инструментом и делает продукт от начала до конца самостоятельно.
При промышленном производстве — существует разделение труда. Программист /= системный администратор.
Может поэтому и отсев такой большой?
При кустарном производстве ремесленник приходит со своим инструментом и делает продукт от начала до конца самостоятельно.
При промышленном производстве — существует разделение труда. Программист /= системный администратор.
Может поэтому и отсев такой большой?
Какое кустарное производство — о чем вы вообще?
Вот к примеру вы думаете Шумахер только ездить умеет? Нет, он может сам по винтику разобрать и собрать свой болид — иначе бы он не смог им эффективно «пользоваться». Техники просто экономят его время, позволяя сконцентрироваться на главном — тренировках, выработке стратегии прохождения трассы, тактики гонки и т.д. Т.к. если он будет сам сутками напролет возится с машиной — на остальное его просто не хватит.
Точно также и здесь, один раз требуется показать умение настраивать всю систему самостоятельно, а следовательно и понимание того как все устроено. В дальнейшем ничего такого больше не потребуется. Этот тест показывает что на самом деле умеет кандидат. И да — в моем понимании веб-программист должен понимать все то же самое, что и системный администратор + еще многое другое, ибо без понимания как устроена сеть, как работает веб-сервер и сервер базы данных — он ничего не сможет толкового написать. Он должен понимать как устроены его инструменты. А лучший способ продемонстрировать это понимание — показать, что он может все это сам установить и сконфигурировать.
Еще мой опыт показывает, что человек который умеет полностью сам эффективно конфигурировать систему и среду разработки намного ценнее, чем любой знаток паттернов и алгоритмов и прочих теоретических знаний. Мне намного важнее чтобы он умел эффективно дебажить средствами браузера и IDE любой код и искать на Stack Overflow решения, чем любые теоретические знания например про конечные автоматы, алгоритмы сортировки и т.д.
Вот к примеру вы думаете Шумахер только ездить умеет? Нет, он может сам по винтику разобрать и собрать свой болид — иначе бы он не смог им эффективно «пользоваться». Техники просто экономят его время, позволяя сконцентрироваться на главном — тренировках, выработке стратегии прохождения трассы, тактики гонки и т.д. Т.к. если он будет сам сутками напролет возится с машиной — на остальное его просто не хватит.
Точно также и здесь, один раз требуется показать умение настраивать всю систему самостоятельно, а следовательно и понимание того как все устроено. В дальнейшем ничего такого больше не потребуется. Этот тест показывает что на самом деле умеет кандидат. И да — в моем понимании веб-программист должен понимать все то же самое, что и системный администратор + еще многое другое, ибо без понимания как устроена сеть, как работает веб-сервер и сервер базы данных — он ничего не сможет толкового написать. Он должен понимать как устроены его инструменты. А лучший способ продемонстрировать это понимание — показать, что он может все это сам установить и сконфигурировать.
Еще мой опыт показывает, что человек который умеет полностью сам эффективно конфигурировать систему и среду разработки намного ценнее, чем любой знаток паттернов и алгоритмов и прочих теоретических знаний. Мне намного важнее чтобы он умел эффективно дебажить средствами браузера и IDE любой код и искать на Stack Overflow решения, чем любые теоретические знания например про конечные автоматы, алгоритмы сортировки и т.д.
craft_brother, кстати, прав. Кустарное производство — это то, что у вас сейчас и для чего вы набираете сотрудников. Ничего ругательного в этом нет, просто особенность конкретного бизнеса. Для быстрого делания CRUD сайтов на PHP+JS+SQL такие люди нужны, а для какого-нибудь другого направления могут требоваться люди с совершенно другими навыками.
Вряд ли Шумахер хоть раз разбирал или собирал свой болид по винтику. Тем более вряд ли он знает режим термообработки пружин подвески или язык, на котором написана программа контроллера впрыска топлива.
Вряд ли Шумахер хоть раз разбирал или собирал свой болид по винтику. Тем более вряд ли он знает режим термообработки пружин подвески или язык, на котором написана программа контроллера впрыска топлива.
Ну уж если следовать вашей аналогии с режимом термообработки пружин и контроллером впрыска, то мы тоже не требуем от кандидата знания литографических процессов производства микросхем применяющихся в его рабочей станции или технологии производства неодимовых магнитов из блока управления головками винчестера, ну или там микрокода процессора.
Вполне достаточно т.с. «крупноузлового» представления об устройстве компьютера.
Вполне достаточно т.с. «крупноузлового» представления об устройстве компьютера.
Я бы взял с собой live-версию со всем настроенным софтом. Неужели никто так не сделал?
Этого не нужно, т.к. по условию теста надо именно показать собственные навыки конфигурирования рабочей станции и ПО в требуемом объеме, т.е. что вы это можете сделать сами, без посторонней помощи. А то ведь образ live флешки можно было скачать откуда-то готовый, или вам кто-то «помог» ее сделать и т.д.
По-моему, плохой вариант собеседования. Хотя верно, вы же ищете похожих по менталитету, вы и барин.
«Нет «горения» — минус» и «Зрелость личности» — несовместимые вещи. Студентам огня в глазах хоть отбавляй.
Когда компания на собеседованиях давит на то, что им нужны амбициозные люди, с огнем в глазах, у меня сразу же появляется перевод: компания ищет раба за небольшие деньги. На чем еще можно играть, урезая бюджет? На мифических нематериальных бонусах, вроде получения бесценного опыта в интереснейшем проекте лучшей в мире компании.
Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.
Когда слышу слово «воля», «успех» и тому подобное, возникают те же стойкие ассоциации, что либо хотят нанять студента, либо просто общаюсь с человеком с другой по сравнению с моей планетой. Воля нужна для того, чтобы что-то преодолевать. Что-то преодолевать нужно, если есть внутренние барьеры. Внутренние барьеры к работе возникают, только если человек не самоорганизован. Несамоорганизованность появляется от безделья.
Успех — это вообще жесткий мем. Современная промывка мозгов. Как-то без конца слышал про успех, успешность, успешных людей. Ни разу не говорилось, что это успешный хирург (не по баблу, а по знаниям), или успешный физик (10 лет изучал физику и обрел знания). Нет, сейчас успех — это самостоятельное слово. Как бы настолько нагло промывают мозги, мол «вы же сами понимаете, что значит успех».
«Нет «горения» — минус» и «Зрелость личности» — несовместимые вещи. Студентам огня в глазах хоть отбавляй.
Когда компания на собеседованиях давит на то, что им нужны амбициозные люди, с огнем в глазах, у меня сразу же появляется перевод: компания ищет раба за небольшие деньги. На чем еще можно играть, урезая бюджет? На мифических нематериальных бонусах, вроде получения бесценного опыта в интереснейшем проекте лучшей в мире компании.
Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.
Когда слышу слово «воля», «успех» и тому подобное, возникают те же стойкие ассоциации, что либо хотят нанять студента, либо просто общаюсь с человеком с другой по сравнению с моей планетой. Воля нужна для того, чтобы что-то преодолевать. Что-то преодолевать нужно, если есть внутренние барьеры. Внутренние барьеры к работе возникают, только если человек не самоорганизован. Несамоорганизованность появляется от безделья.
Успех — это вообще жесткий мем. Современная промывка мозгов. Как-то без конца слышал про успех, успешность, успешных людей. Ни разу не говорилось, что это успешный хирург (не по баблу, а по знаниям), или успешный физик (10 лет изучал физику и обрел знания). Нет, сейчас успех — это самостоятельное слово. Как бы настолько нагло промывают мозги, мол «вы же сами понимаете, что значит успех».
Позволю пофилософствовать. ИМХО, успех — это возможность самореализовываться. Знания, как и деньги, это лишь средство достижения своих целей. У меня, хочу надеяться, хотя сильно давно не студент, по-прежнему есть азарт. Азарт сделать комплексную программу проектов общим объемом 6000 чел.*мес. Для меня это вызов. «Горят глаза», когда я читаю лекции и передаю свой опыт более молодым коллегам. Я получаю от этого удовольствие. И, полагаю, делаю свои проекты с максимальной эффективностью.
успех — это возможность самореализовываться
Это то же самое, только в профиль. Т.е. «стать известным» в какой-то сфере. Когда всё, что надо, есть, еще бы славы )))
По моему, это не коррелирует даже с желанием знать побольше, делать работу качественнее, интересом и любовью к программированию. По крайней мере, я не встречал много людей, которые искренне желают быть известными. Но если хотят, то пусть добиваются. Тем не менее, я не вижу причин на собеседованиях ставить это во главу угла.
Получать от работы удовольствие, конечно, важно. Но, ИМХО, эмоции — лишнее.
Хотя бы потому, что если Вы сделаете
комплексную программу проектов общим объемом 6000 чел.*мес. Для меня это вызов., после этого за подобную задачу не будет интересно браться. А как быть опытному программисту, когда он уже поучаствовал в нескольких десятках проектов, многие сделал сам, и они охватывают уже все интересные для него сферы? Бросать работу и идти в космонавты ))
Ну, что-же, продолжим философствовать. Самореализация — это совсем не про славу и известность. Это про достичь то, что еще никто не достиг. Это про достичь цель, которую никто еще не видит.
А вы были в горах? Я был. На всю жизнь запомнилось чувство. Забравшись на ближайшую самую высокую вершину, видишь новые вершины еще более высокие и прекрасные. Но! Только забравшись на ближайшую самую высокую.
Самореализация это мотив, который не насыщается.
после этого за подобную задачу не будет интересно браться.
А вы были в горах? Я был. На всю жизнь запомнилось чувство. Забравшись на ближайшую самую высокую вершину, видишь новые вершины еще более высокие и прекрасные. Но! Только забравшись на ближайшую самую высокую.
Самореализация это мотив, который не насыщается.
Понятно. Спорить в общем-то нечего, у нас разные мировоззрения.
Я не утверждаю, если что, что работа должна быть ненавистной и надо ее выполнять с настроением мытья посуды. Просто думаю, что должен приносить удовлетворение процесс, а не результат. Мотивировать себя на результат — это на слишком короткие дистанции. Никто так не становится чемпионом в спорте. Никто не станет хорошим программистом, желая всего лишь взять эту высоту. Только привычка работать и только работа, долгосрочная к этому приводит. А выбрать себе деятельность, которая еще и приносит удовольствие как процесс (в моем случае программирование) — это вообще удача.
Я не утверждаю, если что, что работа должна быть ненавистной и надо ее выполнять с настроением мытья посуды. Просто думаю, что должен приносить удовлетворение процесс, а не результат. Мотивировать себя на результат — это на слишком короткие дистанции. Никто так не становится чемпионом в спорте. Никто не станет хорошим программистом, желая всего лишь взять эту высоту. Только привычка работать и только работа, долгосрочная к этому приводит. А выбрать себе деятельность, которая еще и приносит удовольствие как процесс (в моем случае программирование) — это вообще удача.
«что не нравилось на предыдущем месте работы»
В принципе понимаю причину вопроса, но, к сожалению, за все собеседования, что провёл, слышал всегда примерно одинаковое (причём у совершенно разных по опыту, заинтересованности и профессионализму людей). Поэтому к этому вопросу теперь отношусь скептично.
за всех и сразу отвечу: практически всегда уходят по одной из двух причин или двум сразу — первое, хотят больше зп, второе — напряженные отношения в коллективе (часто с начальством). Ни первое ни второе на собеседованиях никто в своем уме озвучивать не будет.
Первое мне вполне себе озвучивало процентов 10-15 собеседуемых (из нескольких сотен).
Второе — нет, но при этом упоминались варианты «пошел нудный саппорт», «пошел слабооплачиваемый раш по ночам»
Второе — нет, но при этом упоминались варианты «пошел нудный саппорт», «пошел слабооплачиваемый раш по ночам»
Озвучить можно мягко, конечно. Честным быть хорошо.
Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.
Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.
Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
UFO just landed and posted this here
Приведённые цифры (более тысячи интервью и больше сотни классных программистов) ничего не говорят о пользе технического собеседования. Может, среди 900 отсеянных было 300 классных программистов. Я уж не говорю о том, что понятие «классный программист» — весьма расплывчивое.
Структуры данных и алгоритмы я бы не назвал узкоспециальными знаниями. Необязательно писать на доске имплементацию красно-черного дерева по памяти, но надо по крайней мере знать, что такое указатель, зачем нужен индекс и чем O(N) отличается от O(N^2).
Попытки давать кандидатам олимпиадные задачки совершенно не связаны с самоутверждением. Сильные программисты с высокой вероятностью уже знают решение, потому что простых но интересных задач, которые можно решить в рамках собеседования, не так много, и они передаются из уст в уста. А если они решение не знают, то видно разницу в отношении. Одни сразу начинают копать: «интересная задачка, я такую раньше не встречал, в лоб не решается, что если я попробую применить вот такой подход...» Другие теряются и тупо смотрят в пустой листок бумаги. Третьи начинают искать оправдания — «мне такого рода задачки не решать не приходилось, институт был давно, это не моя сильная сторона».
Есть задачки, специально подобранные для того, чтобы отсеивать нежелательных кандидатов. У них есть простое решение, которое сложно найти. Так вот сильные кандидаты зачастую могут решить даже их.
Структуры данных и алгоритмы я бы не назвал узкоспециальными знаниями. Необязательно писать на доске имплементацию красно-черного дерева по памяти, но надо по крайней мере знать, что такое указатель, зачем нужен индекс и чем O(N) отличается от O(N^2).
Попытки давать кандидатам олимпиадные задачки совершенно не связаны с самоутверждением. Сильные программисты с высокой вероятностью уже знают решение, потому что простых но интересных задач, которые можно решить в рамках собеседования, не так много, и они передаются из уст в уста. А если они решение не знают, то видно разницу в отношении. Одни сразу начинают копать: «интересная задачка, я такую раньше не встречал, в лоб не решается, что если я попробую применить вот такой подход...» Другие теряются и тупо смотрят в пустой листок бумаги. Третьи начинают искать оправдания — «мне такого рода задачки не решать не приходилось, институт был давно, это не моя сильная сторона».
Есть задачки, специально подобранные для того, чтобы отсеивать нежелательных кандидатов. У них есть простое решение, которое сложно найти. Так вот сильные кандидаты зачастую могут решить даже их.
Я не согласен с автором статьи по многим пунктам, но это и не означает, что я совсем не согласен с ним.
Прежде всего очень рад, что статья вызвала такое бурное обсуждение — все же я сторонник (на данный момент), что в вопросе собеседования нет единственного правильного решения и подхода.
Прежде всего очень рад, что статья вызвала такое бурное обсуждение — все же я сторонник (на данный момент), что в вопросе собеседования нет единственного правильного решения и подхода.
> Попытки давать кандидатам олимпиадные задачки по программированию, или задачки из книжки «Математические головоломки», у меня, как правило, ассоциируются со стремлением, возможно, не очень успешных вчерашних студентов к самоутверждению или с желанием продемонстрировать кандидату его несостоятельность, чтобы затем снизить предложение по зарплате.
Наконец-то кто-то выразил мою давно выработанную мысль. Я бы даже ещё снизил планку и всевозможные технические детали вида «а как называется функция, которой можно сделать то-то» записал в ту же сторону маразма.
Зачем вообще по жизни может пригодиться решение головоломок в коде? Вставил код по частям в отладчик — и всё очевидно.
Открыл мануал по языку и нашёл любую ф-цию за секунды.
Прозрачно намекаю, что если человеку и удасться успешно отвечать на подобного рода вопросы, то для практической работы эти навыки не несут никакого смысла.
Наконец-то кто-то выразил мою давно выработанную мысль. Я бы даже ещё снизил планку и всевозможные технические детали вида «а как называется функция, которой можно сделать то-то» записал в ту же сторону маразма.
Зачем вообще по жизни может пригодиться решение головоломок в коде? Вставил код по частям в отладчик — и всё очевидно.
Открыл мануал по языку и нашёл любую ф-цию за секунды.
Прозрачно намекаю, что если человеку и удасться успешно отвечать на подобного рода вопросы, то для практической работы эти навыки не несут никакого смысла.
Читать код и находить в нем ошибки без сторонних утилит и документации — незаменимое умение. По ряду причин, как то:
— code review: практика вообще целиком про это (у тех у кого это больше чем «тут маленькую букву надо заменить на большую»)
— post-mortem отладка: умения строго недостаточно но без него даже начинать бессмысленно
— собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Конечно, всегда есть скользкий момент, что именно спрашивать и как именно трактовать ответ — если человек пишет в резюме про С++ но не умеет сортировать встроенными средствами, это сразу «нет» или можно еще поговорить? А если не умеет выводить данные в файл? А если пишет про C но не знает что такое malloc?
Но если спрашивать много и разнообразно — то кругозор становится виден очень четко. Если человек в целом знает как пользоваться платформой но не в курсе в каком порядке идут аргументы memcpy то есть маленький шанс что он это выучит когда наймем, а если он путается в показаниях в каждом углу стандартной библиотеки то может лучше не надо?
— code review: практика вообще целиком про это (у тех у кого это больше чем «тут маленькую букву надо заменить на большую»)
— post-mortem отладка: умения строго недостаточно но без него даже начинать бессмысленно
— собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Конечно, всегда есть скользкий момент, что именно спрашивать и как именно трактовать ответ — если человек пишет в резюме про С++ но не умеет сортировать встроенными средствами, это сразу «нет» или можно еще поговорить? А если не умеет выводить данные в файл? А если пишет про C но не знает что такое malloc?
Но если спрашивать много и разнообразно — то кругозор становится виден очень четко. Если человек в целом знает как пользоваться платформой но не в курсе в каком порядке идут аргументы memcpy то есть маленький шанс что он это выучит когда наймем, а если он путается в показаниях в каждом углу стандартной библиотеки то может лучше не надо?
Схлестнёмся :)
> Читать код и находить в нем ошибки без сторонних утилит и документации — незаменимое умение.
Среди таковых причин вижу:
— программирование без компьютера и электричества, в условиях апокалипсиса, либо прочий форс-мажор (в виду низкой вероятности и неработоспособности всех систем в такой ситуации, навык не очень пригодится скорее всего)
— программирование для устаревших платформ (вместо читабельного кода видим набор нулей и единиц) — также сочту малополезным навыком в маловероятной ситуации
В целом я согласен с вами, что хоть какой-то навык чтения кода у программиста быть должен. Судя по моему опыту, достаточный навык внимательности имеется у любого умственно здорового программиста. Возможно, мой опыт излишне оптимистичен…
Почему я так негодую при виде слишком большого внимания по мелочам, т.к. это нерациональная трата времени. Большое внимание к мелким деталям при беседе с кандидатом можно сравнить со странным процессом чтения книги — вместо того, чтобы понять смысл, мы читаем отдельные слова из середины книги и пытаемся найти в них опечатки. Вы отлично ознакомитесь с «буквенным» составом книги, но не вынесите никакого реального опыта.
На мой взгляд правильнее не грузить людей деталями, а начать с общего — какие проекты делали и каким образом. Далее, если потребуется можно уточнить детали реализации и копнуть по мелочам — так хотя бы собеседование будет выглядеть относительно адекватным (говорю, как кандидат с большим опытом :)).
> — собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Забавно. Один и тот же пункт мы с вами совершенно по-разному оцениваем. В виду того, что copy+paste позволяет решить задачу в разы быстрее, а мозг оставить более свежим, я считаю copy+paste очевидным плюсом при работе. Конечно же при условии, что программа оттестирована и работает правильно.
> code review: практика вообще целиком про это
Имхо, более бессмысленная трата времени кроме codereview — совещания на общие темы.
Причем эмоционально codereview даже хуже пустых совещаний, т.к. codereview это заведомо эмоционально негативная процедура, при которой код некого автора подвергается глубокому досмотру с целью выявлений того, что наблюдатели могут счесть «проблемами» и скорее всего хотя бы одна «проблема» будет найдена. За время, потраченное на codereview время нескольких человек будет заморожено, кроме того сам исследуемый код не получит серьезных продвижений, будет лишь дан ответ на вопрос, устраивает ли он наблюдателей или нет :)
Наличие самой процедуры говорит о проблемах в организации работы, т.к. любые возникающие проблемы или спорные вопросы логично решить до написания кода, на не после. Если перенести сodereview в область самого программирование, то оно выглядит как строительство костылей вместо масштабного рефакторинга.
> Читать код и находить в нем ошибки без сторонних утилит и документации — незаменимое умение.
Среди таковых причин вижу:
— программирование без компьютера и электричества, в условиях апокалипсиса, либо прочий форс-мажор (в виду низкой вероятности и неработоспособности всех систем в такой ситуации, навык не очень пригодится скорее всего)
— программирование для устаревших платформ (вместо читабельного кода видим набор нулей и единиц) — также сочту малополезным навыком в маловероятной ситуации
В целом я согласен с вами, что хоть какой-то навык чтения кода у программиста быть должен. Судя по моему опыту, достаточный навык внимательности имеется у любого умственно здорового программиста. Возможно, мой опыт излишне оптимистичен…
Почему я так негодую при виде слишком большого внимания по мелочам, т.к. это нерациональная трата времени. Большое внимание к мелким деталям при беседе с кандидатом можно сравнить со странным процессом чтения книги — вместо того, чтобы понять смысл, мы читаем отдельные слова из середины книги и пытаемся найти в них опечатки. Вы отлично ознакомитесь с «буквенным» составом книги, но не вынесите никакого реального опыта.
На мой взгляд правильнее не грузить людей деталями, а начать с общего — какие проекты делали и каким образом. Далее, если потребуется можно уточнить детали реализации и копнуть по мелочам — так хотя бы собеседование будет выглядеть относительно адекватным (говорю, как кандидат с большим опытом :)).
> — собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Забавно. Один и тот же пункт мы с вами совершенно по-разному оцениваем. В виду того, что copy+paste позволяет решить задачу в разы быстрее, а мозг оставить более свежим, я считаю copy+paste очевидным плюсом при работе. Конечно же при условии, что программа оттестирована и работает правильно.
> code review: практика вообще целиком про это
Имхо, более бессмысленная трата времени кроме codereview — совещания на общие темы.
Причем эмоционально codereview даже хуже пустых совещаний, т.к. codereview это заведомо эмоционально негативная процедура, при которой код некого автора подвергается глубокому досмотру с целью выявлений того, что наблюдатели могут счесть «проблемами» и скорее всего хотя бы одна «проблема» будет найдена. За время, потраченное на codereview время нескольких человек будет заморожено, кроме того сам исследуемый код не получит серьезных продвижений, будет лишь дан ответ на вопрос, устраивает ли он наблюдателей или нет :)
Наличие самой процедуры говорит о проблемах в организации работы, т.к. любые возникающие проблемы или спорные вопросы логично решить до написания кода, на не после. Если перенести сodereview в область самого программирование, то оно выглядит как строительство костылей вместо масштабного рефакторинга.
Мне кажется вы либо паясничаете:
SODD (StackOverflow Driven Development) в своей массе характеризует, что разработчик не способен к исследованию проблемы/задачи в глубину.
Copy-n-Paste DD мало того, что занимает просто больше времени, так еще и способствует понижению качества кода и потенциально разносу ошибок по коду.
Про использование дебаггера и проверка корректности кода — каждый раз в дебаггере прогонять? Сколько же разработка длится? Годы? Не говоря уже про многопоточность.
Codereview это настолько полезная вещь, начиная от устранения мелких ачипяток до каких-то более концептуальных проблем, как, например, не полное понимание работы какого-то отдельного механизма взаимодействия системы, задачи и т.п.
Либо ваше программирование выглядит как костылестроительство — то, безусловно, вы все верно говорите — вам не нужно ни знание алгоритмов, библиотек, принципов работы и code review вам не поможет.
SODD (StackOverflow Driven Development) в своей массе характеризует, что разработчик не способен к исследованию проблемы/задачи в глубину.
Copy-n-Paste DD мало того, что занимает просто больше времени, так еще и способствует понижению качества кода и потенциально разносу ошибок по коду.
Про использование дебаггера и проверка корректности кода — каждый раз в дебаггере прогонять? Сколько же разработка длится? Годы? Не говоря уже про многопоточность.
Codereview это настолько полезная вещь, начиная от устранения мелких ачипяток до каких-то более концептуальных проблем, как, например, не полное понимание работы какого-то отдельного механизма взаимодействия системы, задачи и т.п.
Либо ваше программирование выглядит как костылестроительство — то, безусловно, вы все верно говорите — вам не нужно ни знание алгоритмов, библиотек, принципов работы и code review вам не поможет.
> SODD (StackOverflow Driven Development) в своей массе характеризует, что разработчик не способен к исследованию проблемы/задачи в глубину.
У вас какая конечная цель? Самоутвердится тем, что вы смогли найти решение своими умозаключениями или решить задачу правильно и в короткие сроки? Возможно, некоторые эти цели пытаются совместить, но я скорее больше ко второй. Я не говорю о том, что нужно применить абсолютный копипаст со stackoverflow, но ознакомиться с имеющимися там решениями и возможно позаимствовать наиболее подходящие — по-моему это логично. Очевидно, что если решение уже есть, выдумывание его с нуля никак не может быть эффективнее, чем просто позаимствовать.
> Про использование дебаггера и проверка корректности кода — каждый раз в дебаггере прогонять? Сколько же разработка длится? Годы? Не говоря уже про многопоточность.
Я использую PHP и Perl. Отладка одной ситуации занимает секунды. У вас похоже JAVA, сожалею :)
> Codereview это настолько полезная вещь, начиная от устранения мелких ачипяток до каких-то более концептуальных проблем, как, например, не полное понимание работы какого-то отдельного механизма взаимодействия системы, задачи и т.п.
Вещь может и полезная, но как я уже сказал, это выпадение из рабочего времени. Действительно ли время, потраченное на codereview эффективнее, чем плановая работа? В моем опыте таких codereview не было. А уж исправление опечаток — лично у меня этим занимается IDE и тесты. Это абсолютно автоматизированная часть, глупо тратить на нее человеческий ресурс.
> вам не нужно ни знание алгоритмов, библиотек, принципов работы и code review вам не поможет.
Знание алгоритмов нужно. А в чем принципиальное отличие библиотек от решений на stackoverflow? Библиотеки — это те же самые решения сторонних разработчиков. Вы почему-то их четко разделяете, прямо кодовый рассизм какой-то :)
У вас какая конечная цель? Самоутвердится тем, что вы смогли найти решение своими умозаключениями или решить задачу правильно и в короткие сроки? Возможно, некоторые эти цели пытаются совместить, но я скорее больше ко второй. Я не говорю о том, что нужно применить абсолютный копипаст со stackoverflow, но ознакомиться с имеющимися там решениями и возможно позаимствовать наиболее подходящие — по-моему это логично. Очевидно, что если решение уже есть, выдумывание его с нуля никак не может быть эффективнее, чем просто позаимствовать.
> Про использование дебаггера и проверка корректности кода — каждый раз в дебаггере прогонять? Сколько же разработка длится? Годы? Не говоря уже про многопоточность.
Я использую PHP и Perl. Отладка одной ситуации занимает секунды. У вас похоже JAVA, сожалею :)
> Codereview это настолько полезная вещь, начиная от устранения мелких ачипяток до каких-то более концептуальных проблем, как, например, не полное понимание работы какого-то отдельного механизма взаимодействия системы, задачи и т.п.
Вещь может и полезная, но как я уже сказал, это выпадение из рабочего времени. Действительно ли время, потраченное на codereview эффективнее, чем плановая работа? В моем опыте таких codereview не было. А уж исправление опечаток — лично у меня этим занимается IDE и тесты. Это абсолютно автоматизированная часть, глупо тратить на нее человеческий ресурс.
> вам не нужно ни знание алгоритмов, библиотек, принципов работы и code review вам не поможет.
Знание алгоритмов нужно. А в чем принципиальное отличие библиотек от решений на stackoverflow? Библиотеки — это те же самые решения сторонних разработчиков. Вы почему-то их четко разделяете, прямо кодовый рассизм какой-то :)
Не всегда чьё-то решение подойдет в конкретной ситуации, один фиг надо будет углублятся и до конца раскрутить скопированный алгоритм — экономия по времени лишь скорость набивки текста, и это в лучшем случае если решение на 100% подошло сразу без правок.
Библиотеки — это уже готовые решения, часто проверенные временем и имеют известные заранее условия использования и ограничения. Т.е. такие решения более надежны чем копи-паст т.к. можно заранее узнать подойдет оно или нет.
Библиотеки — это уже готовые решения, часто проверенные временем и имеют известные заранее условия использования и ограничения. Т.е. такие решения более надежны чем копи-паст т.к. можно заранее узнать подойдет оно или нет.
> Не всегда чьё-то решение подойдет в конкретной ситуации, один фиг надо будет углублятся и до конца раскрутить скопированный алгоритм — экономия по времени лишь скорость набивки текста, и это в лучшем случае если решение на 100% подошло сразу без правок.
Если вы пытаетесь найти в инете целиком проект под ваше ТЗ, чтобы вообще ничего не писать, то да скорее всего что-то да не подойдет по вашу ситуацию :)
Я постоянно ищу и заимствую мелкие решения, абсолютно решающие мои проблемы.
По XSLT, например, просто десятки решений было найдено.
Если вы пытаетесь найти в инете целиком проект под ваше ТЗ, чтобы вообще ничего не писать, то да скорее всего что-то да не подойдет по вашу ситуацию :)
Я постоянно ищу и заимствую мелкие решения, абсолютно решающие мои проблемы.
По XSLT, например, просто десятки решений было найдено.
> Библиотеки — это уже готовые решения, часто проверенные временем и имеют известные заранее условия использования и ограничения. Т.е. такие решения более надежны чем копи-паст т.к. можно заранее узнать подойдет оно или нет.
Библиотеки — это комплексные решения. Они состоят из мелких, которые и решаются на stackoverflow. После того, как решение найдено, можно вполне погуглить по его использованию и найти его сторонников и противников, а также оценить его «проверенность временем».
Библиотеки — это комплексные решения. Они состоят из мелких, которые и решаются на stackoverflow. После того, как решение найдено, можно вполне погуглить по его использованию и найти его сторонников и противников, а также оценить его «проверенность временем».
Спасибо за статью! Из всего что я читал здесь о собеседованиях этот подход кажется мне наиболее правильным и адекватным. Настолько что я зарегистрировался и прошел песочницу для того чтобы оставить здесь эту благодарность автору за то что он есть и имеет такой образ мыслей.
Если бы не географическая разница — с удовольствием сходил бы к вам на интервью.
Если бы не географическая разница — с удовольствием сходил бы к вам на интервью.
А не кажется ли он вам наиболее правильным и адекватным из-за того что его легче пройти?
Мне он тоже кажется каким-то слишком мягким, особенно это диссонирует с такими компаниями как Luxoft / CBOSS и опытом / навыками людей, которые там работали, точнее с теми с кем я сталкивался.
Но согласен с общими поведенческими вопросами — почему решили сменить работу, винит ли своих бывших коллег, целиком и полностью согласен, что на кандидата надо изначально смотреть как на коллегу.
Но согласен с общими поведенческими вопросами — почему решили сменить работу, винит ли своих бывших коллег, целиком и полностью согласен, что на кандидата надо изначально смотреть как на коллегу.
Он кажется мне наиболее правильным и адекватным по двум причинам:
1. Отношением к собеседуемому как к человеку пришедшему по вопросу возможного сотрудничества.
2. Пониманием того что мы живем во время информационных технологий, а сами айтишники вообще имеют гугл на кончиках пальцев.
Собеседования и способы проведения собеседования проводимые HRами заставляют задуматься о том что я пришел к ним с протянутой рукой, а они еще подумают. При этом во внимание не принимается ни стрессовость ситуации ни то что по факту они видят меня один час, а работать я буду каждый день.
Отсюда отношение к этому самому собеседованию как к экзамену. Зачем? Мы хотим нанять человека который хорошо проходит собеседования или человека который хорошо работает? Я помню экзамены в школе, в институте, они сдаются на хорошие оценки но далеко не всегда это является реальным показателем знаний. И совсем редко — показателем настоящего понимания того, как это работает.
Да, можно человека час гонять по энциклопедическим знаниям библиотек и алгоритмов, задавать зубодробительные запутанные задачи по ООП или заставлять написать на бумажке SQL из разряда «пойди туда не знаю куда достань то не знаю что и отсортируй». Но зачем? То что я смог ответить может означать что я знаю область, а может означать что именно о такой задаче я прочитал вчера, когда готовился. А что я не смог ответить абсолютно не означает что я не решу эту же задачу в обычной ненапряжной будничной обстановке за компьютером за пару минут, с помощью того же поисковика.
При этом задать вообще все вопросы точно не получится. А умение человека искать ответы на незнакомые ему вопросы никак не проверяется.
Не говоря уже о том что проходя такие жуткие интервью потом работаешь какую-то самую тривиальную работу, одинаковую из месяца в месяц и задаешься вопросом — а к чему все это было?
Мой ответ — HRы ищут оправдание своему существованию. Потому что то что раньше делал отдел кадров теперь может делать одна программка. А люди останутся без работы.
1. Отношением к собеседуемому как к человеку пришедшему по вопросу возможного сотрудничества.
2. Пониманием того что мы живем во время информационных технологий, а сами айтишники вообще имеют гугл на кончиках пальцев.
Собеседования и способы проведения собеседования проводимые HRами заставляют задуматься о том что я пришел к ним с протянутой рукой, а они еще подумают. При этом во внимание не принимается ни стрессовость ситуации ни то что по факту они видят меня один час, а работать я буду каждый день.
Отсюда отношение к этому самому собеседованию как к экзамену. Зачем? Мы хотим нанять человека который хорошо проходит собеседования или человека который хорошо работает? Я помню экзамены в школе, в институте, они сдаются на хорошие оценки но далеко не всегда это является реальным показателем знаний. И совсем редко — показателем настоящего понимания того, как это работает.
Да, можно человека час гонять по энциклопедическим знаниям библиотек и алгоритмов, задавать зубодробительные запутанные задачи по ООП или заставлять написать на бумажке SQL из разряда «пойди туда не знаю куда достань то не знаю что и отсортируй». Но зачем? То что я смог ответить может означать что я знаю область, а может означать что именно о такой задаче я прочитал вчера, когда готовился. А что я не смог ответить абсолютно не означает что я не решу эту же задачу в обычной ненапряжной будничной обстановке за компьютером за пару минут, с помощью того же поисковика.
При этом задать вообще все вопросы точно не получится. А умение человека искать ответы на незнакомые ему вопросы никак не проверяется.
Не говоря уже о том что проходя такие жуткие интервью потом работаешь какую-то самую тривиальную работу, одинаковую из месяца в месяц и задаешься вопросом — а к чему все это было?
Мой ответ — HRы ищут оправдание своему существованию. Потому что то что раньше делал отдел кадров теперь может делать одна программка. А люди останутся без работы.
Интересно сколько внимания привлекает статья, написанная типичным HR без умения нанимать продуктивных работников.
Собираются HR на межкорпоративную вечеринку:
— А мы вот не тестируем когда набираем программистов.
— Ух-ты!
— А мы даже не собеседуем.
— Да!
— А мы вот вообще круче всех, идем в порт и сразу нанимаем бригаду грузчиков.
— О-о-о! Крута!
Собираются HR на межкорпоративную вечеринку:
— А мы вот не тестируем когда набираем программистов.
— Ух-ты!
— А мы даже не собеседуем.
— Да!
— А мы вот вообще круче всех, идем в порт и сразу нанимаем бригаду грузчиков.
— О-о-о! Крута!
Мне кажется или первое предложение этой статьи не предполагает что автор — HR?
Да ну написать можно что угодно, но вот крайности типа гномиков или обратная крайность полное отсутствие тестирования, это вот как раз типичные HR которые не несут ответственности за свои действия. Ас с большим опытом может диагностировать человека просто собеседовав, но даже ас подстрахуется и заложит какую-нибудь объективную проверку в свой процесс, иначе какой же он ас. Опять же предположим ас и ему не жалко тратить миллионы на проверку и отсеивание на реальных проектах (много вы таких ситуаций видели?), такой ас обязательно упомянул бы этот этап.
Опять же зрелость, целеустремленность, всякое там про блеск в глазах, «зажечь», ну явно хрюшкины уши торчат. Какой нафиг зажечь? Я выполнил сотни проектов, для меня это давно уже рутина, меня не возьмут потому что я «не горю»? Да ну бред же, как можно не увидеть такую жирную хрюшку спрятавшуюся за кустиком?
Опять же зрелость, целеустремленность, всякое там про блеск в глазах, «зажечь», ну явно хрюшкины уши торчат. Какой нафиг зажечь? Я выполнил сотни проектов, для меня это давно уже рутина, меня не возьмут потому что я «не горю»? Да ну бред же, как можно не увидеть такую жирную хрюшку спрятавшуюся за кустиком?
Вообще, тестирование, это объективная необходимость и она везде. Вы приходите на прием к врачу, он направляет вас на анализы, а не ждет когда болезнь вылезет вам на нос. Вы учитесь в школе или вузе, вас периодически экзаменуют. Грузчиков проверяют, инженеров проверяют десять раз, продавцам делают инвентаризацию, курьеров просят отчитаться, бухгалтера проверяются при каждой операции, у программистов принимают работу.
То есть во всех сферах деятельности человека заложены объективные проверки. А найм программиста при их высокой зп это ответственность побольше чем у грузчика, курьера или у большинства продавцов. И риски велики ибо врут все. И если вам говорят что при найме не тестируют, значит этот человек только посредник или консультант, это просто и ясно.
То есть во всех сферах деятельности человека заложены объективные проверки. А найм программиста при их высокой зп это ответственность побольше чем у грузчика, курьера или у большинства продавцов. И риски велики ибо врут все. И если вам говорят что при найме не тестируют, значит этот человек только посредник или консультант, это просто и ясно.
Коллеги, ну с чего вы решили, что автор HR? Убедится, что это не так, можно здесь.
Испытательный срок три месяца никто не отменял.
Ну, убедительно врать с деталями, это мало кому доступно.
И смысл врать? Все вранье всплывет на испытательном сроке.
… заложит какую-нибудь объективную проверку в свой процесс.
Испытательный срок три месяца никто не отменял.
И риски велики ибо врут все.
Ну, убедительно врать с деталями, это мало кому доступно.
И смысл врать? Все вранье всплывет на испытательном сроке.
А могли бы хотя бы на не очень достоверные тесты для EQ ткнуть?
Ну, например, вот этот
А там шкала такая же, как в IQ, т.е. 90 — уровень «троечника»?
Совсем не психолог, но могу порассуждать. Думаю, что в EQ не так, как в IQ. Без определенного уровня IQ самостоятельно не выжить, поэтому среднее значение находится во второй половине шкалы. Многие до тестирования на IQ просто не добрались.
ИМХО. Смею предположить, что человек рождается с EQ = 0. Полным эгоистом, которому все обязаны, с никаким самосознанием и целеполаганием Дальше его EQ растет (если он к этому стремится) по логарифму (?). Если по тесту 138 максимум, то 90 это выше среднего. Некоторые с нулевым EQ доживают до солидных лет :)
Еще раз повторюсь адекватных тестов на EQ пока не нашел.
ИМХО. Смею предположить, что человек рождается с EQ = 0. Полным эгоистом, которому все обязаны, с никаким самосознанием и целеполаганием Дальше его EQ растет (если он к этому стремится) по логарифму (?). Если по тесту 138 максимум, то 90 это выше среднего. Некоторые с нулевым EQ доживают до солидных лет :)
Еще раз повторюсь адекватных тестов на EQ пока не нашел.
Sign up to leave a comment.
Почему мы не тестируем. Практика проведения технического интервью