Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Eugene_B, Вы писали:
A> Нигде еще сформулированного лучше A> я не видел.
Вы забыли свое IMHO приписать.
A>Требования там указанные вполне справедливы. A>И они не технические, их все можно выяснить A>просто спросив.
Классно! Тогда любые знания можно выяснить
просто спросив.
"Ты умеешь программировать на С++"
"О, да, я умею программировать на С++.
A>Ты согласен взять на работу человека который говорит A>я "офигенный C++ программист" но при этом не может себе A>поставить самостоятельно Visual Studio на машину? A>Или говорит "Извини а как ставится Windows95? A>а чем она отличается от Windows 2000"
Не надо подменять то, что написано в сообщении по
вашей ссылке своими словами. Там написано не только
про Windows 98, а еще про всякие почтовые клиенты
и прочее.
A>Извини но этот человек получает деньги за то A>что нанимает людей.
Ну и что? Если получает деньги, так сразу автоматически
умеет это делать? Мало кто за что деньги получает.
A>Если он занимается именно этим он A>должен делать это хорошо.
Не факт.
A>И практика показывает A>что люди которые только этим занимаются делают A>это хорошо.
Чтобы ссылаться на практику, надо привести хотя бы
один живой пример. И хорошо бы определить понятие
"хорошо" :)
A>Не важно что он сам не может программировать. A>Поверхностные знания у него есть.
Он даже не знает того, что ничего не знает. Это
хуже всего.
A>неплохие знания в психологии. Если сильно надо A>то можно рядом посадить программиста с просьбой невысовываться A>с задачей про лампочки, а просто послушать о чем A>говорят, а потом высказать свое мнение(вне присутсвия A>потенциального работника)
Вы не поняли, задачки про лампочки как раз от таких
людей с поверхностными знаниями, а не от программистов.
A>Что касается ошибок. Если твой предыдущий проект был неудачным.
Давайте оставим это "если ты..", "если у тебя.."
и будем говорить в третьих лицах.
A>И ты не можешь просто сформулировать почему именно(уже не говоря правильно A>или нет) то это говорит не в твою пользу.
Ну вы даете! Да это же задача (решить трудности больших
проектов в программировании), которую пытаюся решить
во всем мире и не могут пока.
A> Притом обычно причины провала проектов нетехнические A> и их способен понять не программист.
Категорически не согласен. Причины провала проектов,
непрограммисту не понять. Другое дело, может быть,
что для этого не достаточно быть просто программистом,
а надо иметь какие-то дополнительные знания, но
программистом быть обязательно.
EB>>Насчет задачек: EB>>были у нас в институте задачки по физике. Условие EB>>занимает одно или два предложения. Получить EB>>требуется, грубо говоря, одно числовое значение. EB>>Но если ты не прошел ВЕСЬ курс, который тебе EB>>читали, ты ПРАВИЛЬНО эту задачу не решишь.
A>Ключевое слово "Весь курс". Объясни A>мне что такое весь курс в программировании?
В моем сообщении понятие ВЕСЬ курс сразу четко
очерчено: "ВЕСЬ курс, который тебе читали".
Т. е. берется некая объем знаний и умений,
составляется по нему курс, и затем для
этого ИЗВЕСТНОГО набора строятся проверочные
задания. Так же можно поступить и для дисциплины
"программирование". Будем иметь некий перечисленный
набор знаний и умений и при условии грамотного,
талантливого составления тестового задания
уверенность с достаточной степенью вероятности,
что человек, правильно выполнивший это задание,
владеет перечисленными знаниями и умениями.
Конечно, человек, составляющий такие задания
должен обладать исчерпывающими познаниями в
данной области.
A>Никто тебе не согласится писать задачу A>которая покрывает даже малую часть того что A>нужно уметь программисту. Это работы A>должно быть на неделю-две. Я пошлю любого работодателя A>который мне предложит поработать бесплатно.
Я же сразу сказал, что задача может быть маленькой
но хитрой. Мне, например (да и многим другим IMHO)
было бы интересно решать такую задачу.
A>И все работадатели предлагают делать это за их A>деньги, что и называется испытательным сроком.
Пользу для работодателя от испытательного срока
я не отрицаю.
[skipped]
A>Вот именно об этом и нужно говорить на собеседовании. A>Чем занимался в прошлой фирме? Почему ушел? Какой бы A>последний проект? Был ли проект удачным? A>Если нет то чьи это были ошибки и что бы ты сделал A>если бы имел возможность?
[skipped]
А если человек сразу после института и нигде до этого не участвовал (по-серьезному)?
Здравствуйте Anatolix, Вы писали:
A>Да не может даже программист нормально оценить подготовку за 15 минут. Не стоит вообще на собеседовании задавать технические вопросы.
Стоит. Более того, это просто необходимо. Буквально в пятницу я интервьюировал двух орлов, китайца и индуса. Теперь я абсолютно уверен, что технические вопросы задавать необходимо, причём сразу. 15 минут как раз достаточно, чтобы понять знает человек хотя бы основы или нет. В конце концов, после несложного вопроса по основам языка и получения исчерпывающего ответа, можно и извиниться Ну типа мужик, ты ж понимаешь, я же должен тебя о чём-то спрашивать.
A>Надо это определять еще до собеседования. По резюме и переписке. Ну если человек писал 3 года на C++ и у него IQ больше 100 ну должен он понимать указатели.
У китайца на бумаге было 7 лет, у индуса 4 года. У обоих был вписан не один год опыта C++. Первый вообще с трудом понимал о чём речь, второй видимо не успел дочитать букварь.
A>А если не понимает вылетит на 3 день работы да и все.
Зависит от конторы. А если не вылетит, а скажут: ну ты его брал, давай теперь возись?
A>Ты вообще задумывался что именно надо определять на собеседовании? И вообще какие именно качества должны быть у программиста. Почитай вот это http://alexm.here.ru/mo.job.talk/novik-formal-req.txt например
Всё это здорово, я вот по этому списку в программеры не прохожу, т.к. не знаю что такое grep-ом и diff-ом.
Но, тем не менее, над тем что надо определять я задумывался. Определять нужно способность человека думать и решать проблемы. Кстати, об этом постоянно говорится между строк в "Искусство интервью". Но при этом человек должен ещё обладать и определённым технических навыками. Правда иногда бывают и юниорские позиции, на них с удовольствием берут новичков, т.к. зарплату им большую платить не надо и работёнка не очень сложная. Тот же индус, например, мог бы вполне подойти по всем параметрам в другой раз, но в этот нужны именно скильные ребята.
A>Вот именно об этом и нужно говорить на собеседовании. Чем занимался в прошлой фирме? Почему ушел? Какой бы последний проект? Был ли проект удачным? Если нет то чьи это были ошибки и что бы ты сделал если бы имел возможность?
Поговорить можно, только что из этого следует? Да и ответы на это уже давно есть стандарные. Это всё из серии:
— А какие у Вас есть недостатки?
— Да Вы знаете, я много работаю, совсем себя не жалею, отдыхать мне надо больше, а я всё работаю, работаю... Такие вот у меня недостатки.
A>И все. Нужно адекватность человека проверить. Это именно то чего нельзя определить по резюме.
Это и есть самое сложное. Вопрос — как?
Моё мнение такое. Для начала нужно задать несколько несложных/средней сложности вопросов на знание технологий, непосредственно указанных в резюме. Это нужно для того чтобы отсечь откровенное враньё и выяснить уровень на котором можно дальше беседовать с человеком. При этом заминка или не ответ не есть незнание. Я сам в своё время не знал что такое smart-pointer (ну не знал я этого термина ), всё что мне оставалось — это спросить у самого интервьювера что это такое. Он сам похоже не очень был в курсе, но вместе мы додумали это дело до конца, нашли кучу примеров из собственной практитки и вообще мило побеседовали. Но в случае индуса, например, я дважды переформулировал вопрос, затем просто написал кусок кода и спросил будет ли этот код работать. Он дал неправильный ответ и ещё объяснял почему так. Я сделал всё что мог, чтобы ему помочь. Дальнейшая беседа с ним не имела смысла, т.к. обсуждать было не то чтобы нечего, а непонятно на каком языке хотя, конечно, можно было спросить про лампочки...
Далее вполне подходит аналогия с иностранными языками. Если с человеком можно продолжать разговор на понятном обоим языке (о понятных технологиях), то можно уже поговорить и о проектах. Но здесь ни в коем случае не стоит говорить о том, чего у человека нет в резюме. Если у него нет того, что необходимо компании, то лучше его вообще не приглашать, иначе это будет похоже на банальные понты. Здесь можно поговорить и о прошлых проектах и о будущих. Если уровень собеседника вполне соответствует, то можно поспрашивать его о том, в чём сам сомневаешься. А может вы вместе найдёте гениальное решение? А что вам нужно от этого человека? Как раз умение находить гениальные решения. Если level собеседника пониже, то можно, даже объясняя ему какие-то истины, увидеть насколько человек способен к обучению.
Итого, всё просто. Первое — нужно прежде всего уважать собеседника, второе — если у него достаточный технический уровень, то беседу с ним нужно вести прежде всего как с будущим коллегой. Если что-то во всём этом не клеится — значит "не берём".
В общем, это я так... рассуждаю по причине того, что мне самому довелось побывать по ту сторону баррикад и зарубить двух отличных парней, поэтому всерьёз меня воспринимать не стоит
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>В общем, это я так... рассуждаю по причине того, что мне самому довелось побывать по ту сторону баррикад и зарубить двух отличных парней, поэтому всерьёз меня воспринимать не стоит
Да, кстати, на что бы я ещё с большим удовольствием взглянул, так это на пяток страниц напечатанного кода собеседника. Не важно какого кода, просто кода. Локальный такой code review.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Eugene_B, Вы писали:
EB>Вы забыли свое IMHO приписать.
Я так и сказал, я лучше не видел.
Imho 'imho' здесь не нужно. BTW
сформулируй сам что должен уметь программер?
A>>Требования там указанные вполне справедливы. A>>И они не технические, их все можно выяснить A>>просто спросив.
EB>Классно! Тогда любые знания можно выяснить EB>просто спросив. EB>"Ты умеешь программировать на С++" EB>"О, да, я умею программировать на С++.
Ты своего оппонента то читаешь вообще
или просто пишешь сам. Я сказал нетехнические.
Кроме того именно эти требования никто
в резюме не пишет.
A>>Ты согласен взять на работу человека который говорит A>>я "офигенный C++ программист" но при этом не может себе A>>поставить самостоятельно Visual Studio на машину? A>>Или говорит "Извини а как ставится Windows95? A>>а чем она отличается от Windows 2000"
EB>Не надо подменять то, что написано в сообщении по EB>вашей ссылке своими словами. Там написано не только EB>про Windows 98, а еще про всякие почтовые клиенты EB>и прочее.
Ну уж Microsoft Office поставить и
настроить Outlook это вообще все
должны уметь. Опять же ты возьмешь
на работу человека который не может это
делать?
A>>Извини но этот человек получает деньги за то A>>что нанимает людей.
EB>Ну и что? Если получает деньги, так сразу автоматически EB>умеет это делать? Мало кто за что деньги получает.
Ты знаешь если он только этим занимается
он должен делать это хорошо. Если не делает
гнать его в шею.
EB>Чтобы ссылаться на практику, надо привести хотя бы EB>один живой пример. И хорошо бы определить понятие EB>"хорошо"
Когда я устраивался на работу меня никто не спрашивал
про лампочки. Единственный технический вопрос
был ты "используешь STL в своей работе".
Разговаривали со мной менеджер и программист.
A>>Не важно что он сам не может программировать. A>>Поверхностные знания у него есть.
EB>Вы не поняли, задачки про лампочки как раз от таких EB>людей с поверхностными знаниями, а не от программистов.
Перечитай еще раз, задачу про лампочки задал программист.
A>>Что касается ошибок. Если твой предыдущий проект был неудачным.
EB>Давайте оставим это "если ты..", "если у тебя.." EB>и будем говорить в третьих лицах.
Извини, я не это имел ввиду.
A>>И ты не можешь просто сформулировать почему именно(уже не говоря правильно A>>или нет) то это говорит не в твою пользу.
EB>Ну вы даете! Да это же задача (решить трудности больших EB>проектов в программировании), которую пытаюся решить EB>во всем мире и не могут пока.
Она давно уже решена просто не все об этом знают.
EB>Категорически не согласен. Причины провала проектов, EB>непрограммисту не понять. Другое дело, может быть, EB>что для этого не достаточно быть просто программистом, EB>а надо иметь какие-то дополнительные знания, но EB>программистом быть обязательно.
Ты знаешь сейчас у нас всеми проектами управляет человек
который вообще никогда программистом не был и
делает это очень хорошо(он безусловно опирается на
технических специалистов)
Почитай какую нибудь из книг на эту тему. Там
собрана статистика(просто цифры) о неудачных проектах.
Так вот технические трудности стали причиной неудач
в 5% проектах. Тогда как отсутствие управения требованиями
(грубо говоря когда несколько месяцев писали не совсем
то что нужно) 30%
EB>В моем сообщении понятие ВЕСЬ курс сразу четко EB>очерчено: "ВЕСЬ курс, который тебе читали". EB>Т. е. берется некая объем знаний и умений, EB>составляется по нему курс, и затем для EB>этого ИЗВЕСТНОГО набора строятся проверочные EB>задания. Так же можно поступить и для дисциплины EB>"программирование". Будем иметь некий перечисленный EB>набор знаний и умений и при условии грамотного, EB>талантливого составления тестового задания EB>уверенность с достаточной степенью вероятности, EB>что человек, правильно выполнивший это задание, EB>владеет перечисленными знаниями и умениями. EB>Конечно, человек, составляющий такие задания EB>должен обладать исчерпывающими познаниями в EB>данной области.
Как ты думешь он во всех фирмах есть? Кто будет
составлять задания если набирается новый отдел
и никто вообще не знает области в которой они
будут работать?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Обрати внимание на следующие вещи
1) В форуме ее решают толпой притом долго
2) Знания необходимые для решения задачи нигде
почти не пригодятся, т.к. от программиста Delphi
обычно требуется писать простые приложения по
вводу/обработки данных
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Dr_Sh0ck, Вы писали:
DS>А если человек сразу после института и нигде до этого не участвовал (по-серьезному)?
В таком случае на собеседовании на сколько он адекватен в
общении, опять же способен он поставить Outlook или нет.
Его зарплата при этом известна еще до начала собеседования.
Т.к. обычно всем выпускникам которые ничего не умееют
предлагают некую маленькую зарплату а потом по ситуации
станет понятно
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте IT, Вы писали:
IT>Здравствуйте Anatolix, Вы писали:
IT>У китайца на бумаге было 7 лет, у индуса 4 года. У обоих был вписан не один год опыта C++. Первый вообще с трудом понимал о чём речь, второй видимо не успел дочитать букварь.
Ну не знали они английского языка. Именно поэтому они
и не прошли. Да для таких вещей и существует собеседование.
A>>Ты вообще задумывался что именно надо определять на собеседовании? И вообще какие именно качества должны быть у программиста. Почитай вот это http://alexm.here.ru/mo.job.talk/novik-formal-req.txt например
IT>Всё это здорово, я вот по этому списку в программеры не прохожу, т.к. не знаю что такое grep-ом и diff-ом.
Не стоит привязываться к названиям
По другому ты способен пользоваться поиском и утилитой
сравнения файлов? любой?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте IT, Вы писали:
IT>Здравствуйте IT, Вы писали:
IT>>В общем, это я так... рассуждаю по причине того, что мне самому довелось побывать по ту сторону баррикад и зарубить двух отличных парней, поэтому всерьёз меня воспринимать не стоит
IT>Да, кстати, на что бы я ещё с большим удовольствием взглянул, так это на пяток страниц напечатанного кода собеседника. Не важно какого кода, просто кода. Локальный такой code review.
Ты знаешь сразу после того как прочитал его резюме ты мог бы
попросить его по email прислать тебе кусок совего кода.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Раз у всех разные представления предлагаю сделать
некую симуляцию. Например я буду претендентом на вакансию,
а ты будешь пытаться выяснить мой уровень подготовки.
Потом посмотрим какие вопросы были удачны, а какие нет.
Может быть голосование проведем.
Давай я напишу себе резюме в котором 50%
информации лживо, а ты попытаешься узнать
какие именно.
Напиши что-то типа объявления о наборе C/C++
программера с неким набором дополнительных
скиллов(пиши их побольше чтобы точно
попалось то чего я не знаю)
Потом я тебе на это напишу резюме, и начнем.
Согласен?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте IT, Вы писали:
IT>>В общем, это я так... рассуждаю по причине того, что мне самому довелось побывать по ту сторону баррикад и зарубить двух отличных парней, поэтому всерьёз меня воспринимать не стоит
IT>Да, кстати, на что бы я ещё с большим удовольствием взглянул, так это на пяток страниц напечатанного кода собеседника. Не важно какого кода, просто кода. Локальный такой code review.
Здравствуйте Igor Trofimov, Вы писали:
IT>Не будет адекватно. Offline. Нет общения нос-к-носу, у тебя есть большое время на обдумывание и т.п.
Могу пообещать отвечать без поиска по MSDN итп.
Кроме того всмысл не в том чтобы взять меня на работу
или не взять(я то как раз никуда не перехожу), а в том чтобы
выявить какие вопросы имеет смысл задавать, а какие нет.
Сообщения будут не вопрос/ответ, а вопрос и что им хотели
выяснить для чего его вообще задавать.
Если не хотите симуляции давайте просто выясним какие вопросы
имеет смысл задавать и почему.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
A>Кроме того всмысл не в том чтобы взять меня на работу A>или не взять(я то как раз никуда не перехожу), а в том чтобы A>выявить какие вопросы имеет смысл задавать, а какие нет.
Это понятно
Не, можно попробовать, действительно, только следует аккуратно делать выводы. Все-таки, даже без MSDN — разница есть в переписке и в очном общении.
A>Если не хотите симуляции давайте просто выясним какие вопросы A>имеет смысл задавать и почему.
Здравствуйте DarkGray, Вы писали:
IT>>Да, кстати, на что бы я ещё с большим удовольствием взглянул, так это на пяток страниц напечатанного кода собеседника. Не важно какого кода, просто кода. Локальный такой code review.
DG>А по каким параметрам ты бы его оценивал?
Опять оценивал... Два программера над двумя страницами кода могут просидеть сутки
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Anatolix, Вы писали:
IT>>У китайца на бумаге было 7 лет, у индуса 4 года. У обоих был вписан не один год опыта C++. Первый вообще с трудом понимал о чём речь, второй видимо не успел дочитать букварь.
A>Ну не знали они английского языка. Именно поэтому они и не прошли. Да для таких вещей и существует собеседование.
Английский они знают получше меня, тем более индусы. Он у них почти родной. А вот лишнего в резюме много пишут.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Anatolix, Вы писали:
A>Раз у всех разные представления предлагаю сделать некую симуляцию. Например я буду претендентом на вакансию, а ты будешь пытаться выяснить мой уровень подготовки. Потом посмотрим какие вопросы были удачны, а какие нет. Может быть голосование проведем.