>Автор фактически этим утверждает, что компания не способна нанять нормальных сотрудников, ибо следующий интервьюер D просто побеседует с кандидатом на тему фалоимитаторов и наймёт его. Получается, что интервьюеры А и B считают друг друга некомпетентными. То, что наняли их самих, является везением чистой воды, абсурдом мирового масштаба, и не факт, что каждый из них нанял бы интервьюера С. Да это же полный бедлам в процессе найма персонала!
Это в корне неверно.
Далее немного сумбурно и пафосно, но просьба не судить
Цель собеседования — найти того, кто
1. будет решать дела
2. будет окупать себя
3. будет способствовать работе других
... можно продолжить
Т.е. имеем своего рода портрет по вакансии — требования.
Результат собеседования это портрет кандидата, т.е. результаты проверки требований.
Достижение цели — соответствие портретов кандидата и вакансии с определенной степенью.
Достижимость — возможность составления портретов оных
Напрямую это сложно вычилить портрет, нельзя спросить — "Хороши ли вы решите дела, окупите ли себя и тд"
Нужно по каждому требованию готовить перечень вопросов, которые помогут выявить результат.
Требования отрасли известны, требования к вакансии известны. Соответсвтенно имеем некоторый граф, в котором узлами являются одной стороны знания, с другой стороны задачи в отрасли, связи суть влияния знаний/умений на задачи/знания/умения в отрасли.
Возьмем например умение писать шустрый код.
Например, если человек не знает что такое GetHashCode, Equals то можно даже ожидать, что для этого человека не будет разницы между List.Contains и Dictionary.ContainsKey. Следовательно то от него крайне странно ожидать шустрого кода. Даже если ктото ему скажет ,что Dictionary.ContainsKey будет работать быстрее, то из за дефолтного GetHashCode все это может сойти на нет.
И наоборот — если человек знает это, то можно считать определеный минимум уже есть.
Разумеется все это можно обыграть разными способами, в явном и неявном виде:
1. попросить написать Equals, Dispose
2. дать кусочек кода и дать дописать недостающее, при том, что вся логика будет уже готова
3. погонять по Hashtable, Dictionary
4. дать написать контейнер и попросить объяснить выбор структур данных
продолжать можно до беспамятства
5. попросить написать Hashtable
или, например требование как понимание ООП/ООД,
начинать как правило нужно с виртуальных методов, ибо если кандидат это не осилил, то вряд ли он сможет это использовать.
Опять же обыгрывается несколькими способами, в явном и неявном виде.
Еще пример — понимание распределения памяти.
Начинать нужно например с IDisposable, структур и заканчивать представлением объектов в памяти и GC.
При этом IDisposable дополнительно показывает, как человек относился к разработке компонентов.
После того, как выявили результаты по знаниям/умениям, нужно смотреть, насколько выполняется конкретное требование. Я например использую шкалу -1,0, +1.
Очевидно, вопросы должны быть таким, что бы покрывать как можно бОльшие области.
например виртуальные методы, вопросы про итераторы, эвенты именно такими и являются.
Естественно компания должна следить за тем, какие вопросы задаются на собеседовании.
M>Апогеем всего этого является то, что в свою очередь контора держит специальных "людей-собеседователей". Как правило они не прикреплены ни к одному проекту, а весь их день состоит из регулярного штудирования фолиантов Фаулера, Рихтера, Волдеморта (упс), алгоритмов, структур данных да выискиванию и запоминанию логических задач, которые они сами, естественно, не решали, а просто тупо посмотрели в конце книги ответы
Люди-собеседователи, я например, в некоторой степени им являлся последние пять лет, должны понимать ответы собеседуемого.
Вот придет суровый девелопер и на вопрос "что есть ооп" вместо "инкапсуляция, наследование, полиморфизм" начнет рассказывать про стейты, сообщения, бехевиор, то человек без спецподготовки спокойно может забраковать как фантазёра.
Задача собеседователя — получить ответы и понять их, даже если пришел человек уровнем выше.
Не нужно отбраковывать по определенным критериям, не нужно играть в крутого спеца, нужно собрать информацию — всех делов, и не растерять её.
...
M>Джоэл пишет и другое, например, нет смысла давать логические задачки — максимум, что вы узнаете, это то, что знал человек ответ заранее или нет.
Это колокольня Джоэла.
Логические задачи нужно давать студентам. И опытным тоже следует давать, мало ли, не растеряли ли они гибкость.
Тут сразу вагон особенностей вскрывается — как человек ищет рещение, готовит алиби и тд.
M>Джоэл уже давно скорректировал свою точку зрения. А вы?
Я её постоянно пересматриваю.
M>Некоторые спрашивают сегодня в 21 веке основы геометрии, формулу длины пениса и окружности. Накой!
В ряде проектов это имеет смысл. Например если есть привязка к математике в каком либо виде.
Поздно осваивать математику в 30 лет.
> Сейчас же человек должен просто быть усидчивым и любить познавать.[/b] Этого достаточно для работы в среднестатистической компании. Есть исключения, например, работа в команде по разработке DirectX-а, но это скорее исключение.
Если человек усидчивый и интересующийся, то это всегда проявляется например в том, что он добился результатов усидчивостью или раскопал, узнал много вещей.
Нельзя спросить: "Интересуетесь ли вы новым ?" нужно спрашивать косвенно, нгапример "что нового попробовали, что понравилось" и разумеется проверить степень углубления в это новое.
Разумеется, для этого самому надо хотя бы читать кое что.
Если человек интересующийся, то вполне возможно он интересовался не совсем в той облати, что нужна тебе.
Например нужны знания в Linq, WPF, а человек раздраконил Winforms в пух и прах. Это нормально — интерес можно направить в нужное русло, как мне кажется.
Естественно, нужно проверить, интереовался ли человек чем то кроме Wingforms.
M>Да и вообще на кой ляд при исправлении багов в Рефлекторе знать длину окружности?! С таким же успехом можно знать длину ножек и размер сисек тестерши напротив. Но ведь это не спрашивают?!
Чем большы ты знаешь и умеешь, тем больше, быстрее твое сознание будет вбрасывать вариантов решение и тем быстрее, качетсвеннее будут получаться ответы.
Как правило, те, у кого проблемы с математикой, думают медленнее нежели те у кого с математикой все хорошо.
M>Всё-таки мне неясно, зачем программистам 90 процентов которых пишут что-то типа "d = new Dictinary; d.Sort();" и то даже не каждую неделю, а то и реже, знать теорию алгоритмов и структур.
Всю теорию не спрашивают на собеседовании. Имеет смысл спрашивать базовые вещи, это нампример показывает и интерес, и матподготовка, и самообразование и тд и тд. А алгоритмы, структуры проявляются в умении реализовывать фреймворки, кеширование и тд.
Разумеется, просто-девелоперам-которые-умеют-кликать-в-дизайнере это ненужно.
Но контора обычно ищет тех, кто посильнее, потому бОльшинству тех, кто послабее приходится отвечать на такие же вопроы.
M>Самое удивительное, что эта самая работа собеседовать действительно становится неблагодарной, особенно, когда интервьюер живёт в своём придуманном мире розовых грёз и, соответственно, собеседует абстрактного гуру в абстрактный "сферический" проект.
Если контора не управляет поиском кандидатов, если такие интервьюеры не заняты в реальном проекте то так и будет.
M>Про базы данных ничего! Сложилось впечатление в итоге, что собеседники, вызубрив свои заранее заготовленные вопросы, сами плавали в том, что касалось отступления от их сценария, но сидели с таким видом, как будто я беседую с богами программинга, гуру всея кода и Вселенной.
Тут как в Шреке — у людоедов есть слои. У девелоперов тоже есть слои
Если человек не знает основ, например боксин-анбоксинг это одна из таких основ, то эти пробелы будут вылазить постоянно до тех пор, пока не будут исправлены.
По проществии времени эти пробелы приводят к привычке писать дрянной код.
При чем это уже будет проявлятья и в SQL.
M> Он же сделал вывод, что я не читал МСДН Какой прок компании от его собеседования? Только отрицательный.
У меня вот тоже появилось ощущение, что МСДН ты не любишь читать Если конечно писал честно, без желания потроллить
M>Иными словами, в некоторых организациях интервьюер — это некий университетский экзаменатор, не имеющий реальной цели собеседования, его цель — отсобеседовать "студента" на знание "ВСЕЙ физики", всего(!) программирования, вообще ВСЕГО!
В некоторых — да.
M>Не знает, не работал с ремоутингом? Разберётся за пару часов для текущей задачи, а в дальнейшем либо ремоутинг вообще не понадобится, либо прочитает подробней о нём позднее.
Что бы сказать, чт чел разберется или нет, нужны основания.
Ели нигде ни в чем не разбирался, не пробовал разбираться а только говорит, что разберется, то скорее таки не разберется.
M>Сейчас именно нужны компетентные люди, способные выполнить как правило несложную, зачастую неинтересную, но важную для организации задачу, требующую время и упорство!
Не понял, а зачем нужны компетентные для решения несложных задач ?
Дважды два и привлекать профессора математики ?
M>Если же хотите взять персонажа с опытом, то поспрашивайте про опыт, побеседуйте. Где-то уйдя в детали технологий, а кое-где в особенности архитектуры.
Вопрос в том, как спрашивать про опыт.
Если спросить например челвоека, какие архитектурные задачи были, какие он принимал архитектурные решения, как подходил к выбору решения, то это часто ничего не даст.
Ты то в его проекте ничего не знаешь и проверить его ответы не сможешь + в терминологии чуточку разница. Например я на собеседовании прокололся так — View в приложении на самом деле выродился во ViewModel, но в силу ряда причин сохранил название класса View. Соответственно собеседующие были в недоумении, почему некто биндится ко вьюшке
Самое главное — все задания должны быть легко проверяемыми.
Спрашивай сколько угодно про опыт — это крайне сложно проверить.
Дело ведь не в том, насколько логично человек описывает выбор решения.
Нужно выяснить, насколько правильным, полным было это решение.
Если тебе оно кажется логичным, правильным, то это вовсе не значит, что оно таким и является.
Очень часто в разных случаях одна и таже задача, решается прямо противоположными методами. Или, наоборот, различные задачи, но решаются одним и тем же методом.
Спрашивать про опытым можно и нужно, но сводить только к такому разговору не стоит. Так например можно выявить как человек настроен на решение проблем, на принятие решений и тд и тд.
Так можно например выявить интерес, но нужно ведь выявлять и природу, степень интереса.
M>Сообщите о своём проекте, что надо делать. Устраивает вас и его? Отлично! Берите! Не имеет смысла собеседовать ещё сто кандидатов. Вы только потеряете деньги организации на проведении собеседований и на простаивающем проекте.
Это чисто формула счастья Как бы и так известно, только за "Устраивает вас и его?" должны стоять конкретные действия а из твоего сообщения до конца не ясно, что же это за действия.
по собеседованиям. надо помнить кого мы нанимаем — студента или профи.
если студента — то все правильно, надо гонять и в хвост и в гриву, давать задания, на дом, на собеседовании.
если профи — давать задания студенческие это оскорбление у профи надо лишь поглядеть бэкграунд, спросить про то, что делал. и надо четко понимать — если он в предыдущих конторах проработал по году и более — то ясно понятно что не просто так сидел. значит скорее всего не врет в резюме
а еще, почему то "экзаменаторы" забывают про тестовый период который обычно 2-3 месяца. если уж так хорошо погоняли на "экзамене" — так зачем тестовый период тогда? а он то как раз и нужен, чтобы подтвердилась квалификация человека!
то есть оптимальное собеседования профи — пригласить, обсудить резюме, поговорить про прошлый опыт, поглядеть какой у него характер (часто видел вспыльчивых или надменных типов на собеседовании ). все подумать чуть чуть, и брать на тестовый период. в этот тестовый период он то и покажет себя.
оценить результаты работы — как код пишет. видно же будет
(у нас манагер-тимлид-архитект (да да, в одном лице) — пишет такой нечитабельный код, просто ужас. и ему пофиг на различные внутрикомпанийные коде стайл соглашения — хз почему но бороться с его мировоззрением написания кода бесполезно, ибо субординация )
кодестайл, ладит ли со всей командой, как много багов допускает, часто ли приходится куски его кода править — все это в тестовом периоде, а не в процессе "экзамена"
I>Результат собеседования это портрет кандидата, т.е. результаты проверки требований. I>Достижение цели — соответствие портретов кандидата и вакансии с определенной степенью. I>Достижимость — возможность составления портретов оных I>Напрямую это сложно вычилить портрет, нельзя спросить — "Хороши ли вы решите дела, окупите ли себя и тд"
Уважаемый, это не к собеседуемому вопрос. Это к Вам вопрос, а точнее к его начальнику — хорошо ли можно будет с помощью его умений решить ту или иную задачу, можно ли будет с его помощью заработать лишнее бабло.
I>Возьмем например умение писать шустрый код. I>Например, если человек не знает что такое GetHashCode, Equals то можно даже ожидать, что для этого человека не будет разницы между List.Contains и Dictionary.ContainsKey. Следовательно то от него крайне странно ожидать шустрого кода. Даже если ктото ему скажет ,что Dictionary.ContainsKey будет работать быстрее, то из за дефолтного GetHashCode все это может сойти на нет.
знание, какая из 2 ф-ий работает быстрее — это не есть умение писать шустрый код. Умение писать шустрый код — это умение проанализировать тот или иной вариант уже имеющегося кода, найти его слабые места и или найти более шустрый аналог, или разработать что то свое. Знание того, что pshufd работает быстрее movdqu само по себе не сделает код шустрее. Но понимание алгоритмов — с абсолютным незнанием конкретных команд — даст гораздо более лучший результат.
Здравствуйте, Dog, Вы писали:
I>>Три месяца платить ЗП а потом снова начать собеседования ? Dog>А в чём проблема, жалко денег? Или у вас там проекты по 2$/час ?
Проблемы нет. Не вижу необходимости разбазаривать деньги.
I>>По такой методике только за два последних месяца я бы пропустил более 10 человек, которые ни в зуб ногой в ООП и не могут писать код, зато очень толково и уверенно расказывают про проект Dog>Ну кто ж виноват что вы не умеете задавать правильные вопросы ?
Я — умею. Помнится ты приходил к нам и попал на собеседование к людям, у который это было в первый раз. Так шта не надо делать мега-выводы.
I>>Для этого лучше дать написать код на собеседовании, а не платить ЗП три месяца. Dog>Вы готовы предоставить ноут со студией и решарпером ? Или как обычно, на бумажке
На бумажке, ибо
во-первых, кода надо около десяти строчек
во-вторых люди с ноутом, студией и решарпером пока приладятся к чужому рабочему месту, пока привыкнут к клавиатуре, то пройдет час другой
в-третьих ни один из тех, что пришел с ноутом не показал ничего стоящего
Задача на бумажке достаточно простая, вдобавок можно ошибаться в синтаксисе и можно ошибаться даже в алгоритме
Здравствуйте, fgrdn, Вы писали:
F>если профи — давать задания студенческие это оскорбление у профи надо лишь поглядеть бэкграунд, спросить про то, что делал. и надо четко понимать — если он в предыдущих конторах проработал по году и более — то ясно понятно что не просто так сидел. значит скорее всего не врет в резюме
Ясно что не врет. Но сути это не меняет. У человека могут быть взгляды на работу отличные от моих.
F>а еще, почему то "экзаменаторы" забывают про тестовый период который обычно 2-3 месяца. если уж так хорошо погоняли на "экзамене" — так зачем тестовый период тогда? а он то как раз и нужен, чтобы подтвердилась квалификация человека!
Три месяца платить ЗП а потом снова начать собеседования ?
F>то есть оптимальное собеседования профи — пригласить, обсудить резюме, поговорить про прошлый опыт, поглядеть какой у него характер (часто видел вспыльчивых или надменных типов на собеседовании ). все
По такой методике только за два последних месяца я бы пропустил более 10 человек, которые ни в зуб ногой в ООП и не могут писать код, зато очень толково и уверенно расказывают про проект
F>оценить результаты работы — как код пишет. видно же будет
Для этого лучше дать написать код на собеседовании, а не платить ЗП три месяца.
F>(у нас манагер-тимлид-архитект (да да, в одном лице) — пишет такой нечитабельный код, просто ужас. и ему пофиг на различные внутрикомпанийные коде стайл соглашения — хз почему но бороться с его мировоззрением написания кода бесполезно, ибо субординация )
Странно, что ты работаешь у такого начальства
F>кодестайл, ладит ли со всей командой, как много багов допускает, часто ли приходится куски его кода править — все это в тестовом периоде, а не в процессе "экзамена"
Ладит ли со всей командой — вот это можно проверить только на испытательном. Все остальное — на собеседовании.
F>>а еще, почему то "экзаменаторы" забывают про тестовый период который обычно 2-3 месяца. если уж так хорошо погоняли на "экзамене" — так зачем тестовый период тогда? а он то как раз и нужен, чтобы подтвердилась квалификация человека! I>Три месяца платить ЗП а потом снова начать собеседования ?
А в чём проблема, жалко денег? Или у вас там проекты по 2$/час ?
F>>то есть оптимальное собеседования профи — пригласить, обсудить резюме, поговорить про прошлый опыт, поглядеть какой у него характер (часто видел вспыльчивых или надменных типов на собеседовании ). все I>По такой методике только за два последних месяца я бы пропустил более 10 человек, которые ни в зуб ногой в ООП и не могут писать код, зато очень толково и уверенно расказывают про проект
Ну кто ж виноват что вы не умеете задавать правильные вопросы ?
F>>оценить результаты работы — как код пишет. видно же будет I>Для этого лучше дать написать код на собеседовании, а не платить ЗП три месяца.
Вы готовы предоставить ноут со студией и решарпером ? Или как обычно, на бумажке
Здравствуйте, Ikemefula, Вы писали:
I>Не нужно отбраковывать по определенным критериям, не нужно играть в крутого спеца, нужно собрать информацию — всех делов, и не растерять её.
+1 I>Логические задачи нужно давать студентам. И опытным тоже следует давать, мало ли, не растеряли ли они гибкость. I>Тут сразу вагон особенностей вскрывается — как человек ищет рещение, готовит алиби и тд.
Часто наиболее быстрый способ оценить квалификацию — это именно простые задачи. Чем больше поток соискателей — тем больше простых задач.
Увы.
Эх, вспомнилось как преподствовал у себя в универе. Нужно было за пару делать кучу разного, а также оценивать качество выполнения лабы у каждого из группы.
5 мин на человека.
Вначале пробовал вести задушевные беседы и погружаться во внутренний мир каждого студента.
Времени не хватало...
Пошел другим путем. Пример: пусть в лабе надо было считать символы, введенные из клавиатуры на низком уровне. Человек притаскивал кучу кода на ассемблере. Я спрашивал тупые вещи, типа "какова разрядность регистра ax". "что такое xor cx,cx".
Спрашивал не по существу, ибо цель лаб — не изучения ассемблера. Но такой подход позволяет за минуту отбраковать тех, кто не зная стырил чужое решение.
С точки зрения студентов я был дебильным преподом, ибо заваливал на основании левых вопросов.
Но эти левые вопросы, тем не менее, позволяли оценить уровень студента с максимальным соотношением скорость/качество.
Может, и на собеседованиях то же самое?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, jakor, Вы писали:
J>Уважаемый, это не к собеседуемому вопрос. Это к Вам вопрос, а точнее к его начальнику — хорошо ли можно будет с помощью его умений решить ту или иную задачу, можно ли будет с его помощью заработать лишнее бабло.
I>>Возьмем например умение писать шустрый код. I>>Например, если человек не знает что такое GetHashCode, Equals то можно даже ожидать, что для этого человека не будет разницы между List.Contains и Dictionary.ContainsKey. Следовательно то от него крайне странно ожидать шустрого кода. Даже если ктото ему скажет ,что Dictionary.ContainsKey будет работать быстрее, то из за дефолтного GetHashCode все это может сойти на нет.
J>знание, какая из 2 ф-ий работает быстрее — это не есть умение писать шустрый код.
Я про это и говорю: "...даже если ктото ему скажет ,что Dictionary.ContainsKey будет работать быстрее"
Здравствуйте, Gradient, Вы писали:
G>Часто наиболее быстрый способ оценить квалификацию — это именно простые задачи. Чем больше поток соискателей — тем больше простых задач. G>Увы.
Единственное что мне не нравится в этом, кандидаты частенько растраиваются если им не задать мега вопрос.
G>С точки зрения студентов я был дебильным преподом, ибо заваливал на основании левых вопросов.
А ты, коварный
G>Но эти левые вопросы, тем не менее, позволяли оценить уровень студента с максимальным соотношением скорость/качество. G>Может, и на собеседованиях то же самое?
На собеседовании нужно уложиться где то в час, ну, от силы, полтора.
Здравствуйте, Ikemefula, Вы писали:
I>По такой методике только за два последних месяца я бы пропустил более 10 человек, которые ни в зуб ногой в ООП и не могут писать код, зато очень толково и уверенно расказывают про проект
это смотря как спрашивать про предыдущий опыт. конечно если попросить картину как бы в целом — то да, про ООП/ООД и прочее — не будет ни слова. но если спросить конкретно — то будет ясно. (как пример — попросить рассказать про конкретные участки кода, выполненные разработчиком лично; какие классы реализованы; ..вобщем все то, что вам интересно узнать в том числе и про ООП/ООД выяснится все).
вобще, какбы и тот и другой метод (метод экзамена и метод разборки бэкграунда) не дают 100% удачи в поиске кандидата. тут еще фактор есть — кто собеседует (имеется ли опыт собеседований и прочее).
просто один метод собеседований выматывает кандидата (не гуманный), а второй нет (более гуманный ).
ЗЫ: начальство у меня не шик конечно но до недавнего времени хотя бы интересные задачи были..
13.07.2010 12:09, Ikemefula пишет: > > Ясно что не врет. Но сути это не меняет. У человека могут быть взгляды > на работу отличные от моих.
Ну и все, значит не берете, ибо не сможете работать вместе.
Здравствуйте, fgrdn, Вы писали:
F>это смотря как спрашивать про предыдущий опыт. конечно если попросить картину как бы в целом — то да, про ООП/ООД и прочее — не будет ни слова. но если спросить конкретно — то будет ясно. (как пример — попросить рассказать про конкретные участки кода, выполненные разработчиком лично; какие классы реализованы; ..вобщем все то, что вам интересно узнать в том числе и про ООП/ООД выяснится все).
Ну так все равно приходится углубляться в детали
F>вобще, какбы и тот и другой метод (метод экзамена и метод разборки бэкграунда) не дают 100% удачи в поиске кандидата. тут еще фактор есть — кто собеседует (имеется ли опыт собеседований и прочее).
F>просто один метод собеседований выматывает кандидата (не гуманный), а второй нет (более гуманный ).
Я недавно сам прошел цепочку собеседований, вобщем то не могу сказать, что мой метод какой то особенный. Все серьезные конторые проводили собеседования примерно в таком же духе.
Здравствуйте, Vzhyk, Вы писали:
>> Ясно что не врет. Но сути это не меняет. У человека могут быть взгляды >> на работу отличные от моих. V>Ну и все, значит не берете, ибо не сможете работать вместе.
Не все так просто. Разные взгляды это как раз таки нормально. А вот разные ценности — это уже совсем другое.
Меня вобщем не пугает, если у человека мнение отличное от моего.
Здравствуйте, Ikemefula, Вы писали:
I>Ну так все равно приходится углубляться в детали
без деталей — никуда. просто выяснение деталей должно быть "по теме" то, что нужно действительно в работе. ну а в перспективе если чтото понадобится, то достаточно просто выяснить — обучаем ли кандидат или не очень (это из резюме и из беседы можно выяснить легко).
Здравствуйте, fgrdn, Вы писали:
I>>Ну так все равно приходится углубляться в детали
F>без деталей — никуда. просто выяснение деталей должно быть "по теме" то, что нужно действительно в работе. ну а в перспективе если чтото понадобится, то достаточно просто выяснить — обучаем ли кандидат или не очень (это из резюме и из беседы можно выяснить легко).
Каким образом это можно выяснть из беседы или резюме ?
Здравствуйте, Ikemefula, Вы писали:
I>Каким образом это можно выяснть из беседы или резюме ?
какие книги читал последнее время; какие библиотеки/фреймворки/движки последнее время пробовал; пишет ли чтото дома; интересуется ли новостями соответствующими..
вобщем вопросы зависеть будут от специфики работы, куда нанимается кандидат.
13.07.2010 13:18, Ikemefula пишет: > > Меня вобщем не пугает, если у человека мнение отличное от моего.
Мне совсем неинтересно, что тебя пугает, а что нет. Но если ты видишь,
что вы не сможете работать вместе (вне зависимости от уровня кандидата),
то кандидата на работу брать нельзя.
Здравствуйте, fgrdn, Вы писали:
F>если профи — давать задания студенческие это оскорбление у профи надо лишь поглядеть бэкграунд, спросить про то, что делал.
Для начала нужно узнать, что это профи, а не просидевший 15 лет "архитектор", который написала много красивых букв в резюме, но с уровнем джуниора, как только дело касается хоть что-то написать сложнее asp.net странички с стандартными контролами.
I>>>Для этого лучше дать написать код на собеседовании, а не платить ЗП три месяца. Dog>>Вы готовы предоставить ноут со студией и решарпером ? Или как обычно, на бумажке I>На бумажке, ибо I>во-первых, кода надо около десяти строчек I>во-вторых люди с ноутом, студией и решарпером пока приладятся к чужому рабочему месту, пока привыкнут к клавиатуре, то пройдет час другой
Рыдалъ. Как часто вы пишите код на бумажке? Как часто вы вообще пользуетесь ручкой? Вы можете написать этих "десять строчек" с первого раза без ошибок и памарок, а со второго, а с третьего?
Или у вас проходят такие отмазки?
"Простите, я сегодня ничего не делал, привыкал к клавиатуре"
"Простите, я сегодня ничего не делал, моя задница привыкала к чужому рабочему месту"
"Простите, я сегодня ничего не делал, я никогда не работал на ноуте"
I>в-третьих ни один из тех, что пришел с ноутом не показал ничего стоящего
Что, к вам ещё на собеседование с ноутом приходить ??? Неужели такие бедные, что не можете выделить машину для собеседований ?
F>>если профи — давать задания студенческие это оскорбление у профи надо лишь поглядеть бэкграунд, спросить про то, что делал. O>Для начала нужно узнать, что это профи, а не просидевший 15 лет "архитектор", который написала много красивых букв в резюме, но с уровнем джуниора, как только дело касается хоть что-то написать сложнее asp.net странички с стандартными контролами.
Дада, ему ещё повезло, было это по C++ ваще спросили бы про виртуальныей деструктор.
Здравствуйте, Dog, Вы писали:
I>>во-вторых люди с ноутом, студией и решарпером пока приладятся к чужому рабочему месту, пока привыкнут к клавиатуре, то пройдет час другой Dog>Рыдалъ. Как часто вы пишите код на бумажке? Как часто вы вообще пользуетесь ручкой? Вы можете написать этих "десять строчек" с первого раза без ошибок и памарок, а со второго, а с третьего?
Ты невнимательно читаешь. Было сказано, что
1 можно ошибаться в синтаксисе
2 можно ошибаться в алгоритме
кроме того, на задачи, которые я в свое время решил за минуты 2, дается 20 минут и где то три попытки на исправления.
Все задачи, которые я даю на собеседовании, предваритель отрабатываются на людях что работают рядом со мной.
Сколько помарок — дело десятое, главное что бы худо-бедно решение просматривалось.
Как правило, те, кто справляется с задачей, могут рассказать много чего интересного.
Те, кто не справляется, бумага ли, карандаш не устраивает, ровным счетом ничем порадовать не могут.
Ве по одной простой причине — 20 минут на задачу в 10 строк вместе со скобками да три попытки + можно ошибаться чуть не как угодно это вполне комфортные условия.
Dog>Или у вас проходят такие отмазки?
... Dog>
Как правило на чужом рабочем месте люди могут показать еще меньше чем на бумаге.
Проверено не единожды.
I>>в-третьих ни один из тех, что пришел с ноутом не показал ничего стоящего Dog>Что, к вам ещё на собеседование с ноутом приходить ??? Неужели такие бедные, что не можете выделить машину для собеседований ?
Можно, конечно, только скорее всего на моем компе к слову, или ноуте, ты и за час ничего не сделаешь.
Как правило, человеку будет удобно только на своем рабочем месте.
Здравствуйте, Dog, Вы писали:
Dog>Дада, ему ещё повезло, было это по C++ ваще спросили бы про виртуальныей деструктор.
Боюсь вопрос был бы не понят, т.к. понятие деструктор отсутствовало в мозгу.
