Думаю — не надо себя обманывать. Дело не в криворукости. Дело в личности и состоянии души на момент собеседования. Если человек знает какие угодно технические детали, но ковыряет в носу во время собеседования — он не пройдет. Хотя — это такая, в общем, лотерея. Нравится — не нравится. Работал на 4рех работах, на двух сам принимал людей. Ходил по собеседованиям, отказывался сам, отказывали мне. Проекты как заваливал с треском, так и сдавал с получением бонусов и других плюшек. Итак — никогда нельзя сказать со стопроцентной вероятностью — устроишься ты или нет. Слишком много факторов влияют. Сегодня ты бы не взял человека, потому что у тебя через 2 часа митинг, к которому у тебя не собраны документы, а на другой день — он прошел бы на ура, потому что тебе только что выписали премию. Точно так же и с кандидатом — сегодня он пришел хмурый — его жмет время, у него проблемы, он хочет в туалет, наконец — и он в пролете, назавтра — он в ударе, девушки любят, полный успех. Мы живем в социуме, ситуация постоянно меняется — и паттерны здесь совсем не самый важный фактор. Я буду работать с человеком, который способен спокойно поговорить о деталях реализации, но, скорее всего, откажусь иметь дело с пишущим идеальный откомментированный код заносчивым ...ком. communication и negotiation skills — вот что самое главное в девелопере, остальное — выучит, бэкграунд конечно должен быть, но спрашивать на собеседовании о сортировках, sizeof от пустого класса и что вернет select '''''' — это просто неимоверная дурь собеседующего. В человеке главное не то что он знает, как задавать NumberFormat — а то — сможет он это в понятной форме донести до других людей или разобраться с этим сам.
Здравствуйте, lynn-lynn, Вы писали:
LL> Я буду работать с человеком, который способен спокойно поговорить о деталях реализации, но, скорее всего, откажусь иметь дело с пишущим идеальный откомментированный код заносчивым ...ком. communication и negotiation skills — вот что самое главное в девелопере, остальное — выучит
Вы ничего не путаете? Может вам сразу в МВ тогда идти персонал агитировать? Говорят, там у народа очень неплохой communication и negotiation skills.
Лучше уж делающий свое дело **дак, чем неразбирающийся ни в чем ***дун.
Здравствуйте, saproj, Вы писали:
S>Здравствуйте, lynn-lynn, Вы писали:
S>А не получится так: думал он программист, а оказалось — трепач ?
Не думаю. Несколько раз сам проводил собеседование и часто бывает понятно
треплется человек или нет, и для этого не обязательно просить его
написать архиватор или спроектировать МКС.
Для того что бы точно оценить уровень "валидности"
надо давать задачу на "чуть выше среднего" уровень интеллекта
и посмотреть как он парится, тут не важно как
быстро он сделает и эффективно или нет. Обычно уже в процессе видно — он сделает,
или этот — НЕТ. И тут не важно сделал он реально или нет, главное как он за задачу взялся,
как он думал, что делал, как решал.
И пусть задача маленькая, но для мозгов, а не на знания.
Главное процесс посмотреть — главное понять. Ведь вам потом работать,
а увольнять на траяльном периоде, как то больно
Здравствуйте, lynn-lynn, Вы писали:
LL>Я буду работать с человеком, который способен спокойно поговорить о деталях реализации, но, скорее всего, откажусь иметь дело с пишущим идеальный откомментированный код заносчивым ...ком. communication и negotiation skills — вот что самое главное в девелопере, остальное — выучит
А не получится так: думал он программист, а оказалось — трепач ?
Обычно уже в процессе видно — он сделает, М>или этот — НЕТ. И тут не важно сделал он реально или нет, главное как он за задачу взялся, М>как он думал, что делал, как решал. М>И пусть задача маленькая, но для мозгов, а не на знания. М>Главное процесс посмотреть — главное понять.
Встряну и добавлю , что при некоторых подходах к разработке ПО вероятность того, что собеседуемый будет
решать задачу целиком от начала и до конца весьма и весьма не велика. Все знать просто не возможно.
Полная взаимозаменяемость -хорошо, но не всегда достижима, а если программисты будут работать
вместе, то без навыков общения и умения принять чужую точку зрения тут никак не обойтись.
Здравствуйте, 191540, Вы писали:
1>Здравствуйте, Молодой, Вы писали:
1>Обычно уже в процессе видно — он сделает, М>>или этот — НЕТ. И тут не важно сделал он реально или нет, главное как он за задачу взялся, М>>как он думал, что делал, как решал. М>>И пусть задача маленькая, но для мозгов, а не на знания. М>>Главное процесс посмотреть — главное понять.
1>Встряну и добавлю , что при некоторых подходах к разработке ПО вероятность того, что собеседуемый будет 1>решать задачу целиком от начала и до конца весьма и весьма не велика. Все знать просто не возможно. 1>Полная взаимозаменяемость -хорошо, но не всегда достижима, а если программисты будут работать 1>вместе, то без навыков общения и умения принять чужую точку зрения тут никак не обойтись.
LL>> Я буду работать с человеком, который способен спокойно поговорить о деталях реализации, но, скорее всего, откажусь иметь дело с пишущим идеальный откомментированный код заносчивым ...ком. communication и negotiation skills — вот что самое главное в девелопере, остальное — выучит Q>Вы ничего не путаете? Может вам сразу в МВ тогда идти персонал агитировать? Говорят, там у народа очень неплохой communication и negotiation skills. Q>Лучше уж делающий свое дело **дак, чем неразбирающийся ни в чем ***дун.
Отсюда правило: работу в конечном итоге найдет и тот и тот
?
