Не дали офер из-за того, что не надел костюм на интверью

[Mic]

adda, извините, что слишком резко высказался. Прошу прощения.

Да, adda, я бы тоже хотел извиниться, если показался грубым.
Я давно читаю ваши посты и всегда относился и отношусь с уважением. В комментах не содержалось злобы.

[Papa Hotel Whisky]

А я делаю еще проще. Никогда не спрашиваю на интервью то, что можно за две минуты найти в документации.
Мне не важно, знает ли человек, сколько параметров у той или иной функции и какого они типа. Потребуется - найдет. Мне важно как он мыслит. Даю конкретную задачу (обычно из практики) и прошу на словах объяснить подход к решению. Потом лезем вглубь и разбираем отдельные нюансы, уже с использованием доски. Модель данных, необходимые процессы и преобразования, основные переменные и их передачу и т.п. Но писать на доске работающий код - верх идиотизма.
Еще один нюанс. Я всегда довожу кандидата до момента, когда он не сможет ответить на вопрос. Мне важно, как именно он это сделает. Если скажет "Ну-у-у, не знаю..." - один разговор. Если "На данный момент у меня нет готового решения, но дайте полчаса и доступ в Интернет - и оно будет" - совсем другой.

[nightmare2]

Я не совсем понял, что вы имели в виду. Вы считаете, что не нужно просить писать на доске код человека, работа которого будет заключаться именно в написании кода? И я не должен этого делать потому, что у него 20+ лет опыта в индустрии, и потому это его обидит?

Я конечно не программист, но когда пишу скрипты, всегда свои предыдущие смотрю, без этого не могу.
Если бы меня попросили на интервью написать код на доске, то наверняка понаделал бы ошибок, хотя и программы и скрипты только и писал всю жизнь и уже пред-комиссаровского возраста.

Я имею в виду не синтаксические ошибки, а ошибки, которые показывают плохое понимания основ языка, на котором человек пишет.

Скажите пожалуйста, у вас программисты код на доске пишут? Я почему то думал что для этого есть компьютеры.
Вы знаете, я довольно таки долго работал преподавтелем и могу вас сказать, что у доски можно завалить любого, не зависимо от уровня знаний и опыта. Причем все будет сделано объективно, не знает ХХ, УУ и так далее..

Я не могу и не собираюсь оспаривать ваши мудрые выводы по поводу данного кандидата, но мне просто интересно, как он умудрился работать программистом все эти годы? Я ведь полагаю, вы делали какой то чекап по его предыдущим местам работы, ну хотя бы через линкендин или просто смотрели референсы.

И еще. Вы писали что позиция до сих пор открыта. Лично у меня это не вызывает удивления.

Я поясню чтобы два раза не вставать.
Есть два подхода к интервью. Одни - выяснить что человек не знает. Второй - что он знает.
Есть два типа интервьюеров. Один - пытается показарть какой он крутой путем заваливания кандидата. Другой - пытается выяснить, что есть у кандидата хорошего и как его можно будет использовать лучшим образом в своем коллективе.

+1
Абсолютно верно.

Мне уже к 60 и как верно заметил г. Коммисар, я старпер. Но за свою достаточно долгую программисткую жизнь я очень редко встречал совсем уж дураков которых нельзя использовать группе. И реально нет на самом деле проблемы научить человека не знающего что то за короткое время каким то навыкам, особенно в кодописании, которое не есть рокет сайенс, если он хочет работать и если у него умная голова. И еще раз повторю, дураков на самом деле не так уж много в нашей профессии.

Мне это кажется очевидным, но мало кто так делает.
Вообще, если говорят что кандидат не справился, то в большинстве случаев - это вина менеджера и коллектива.
Очень уж велик соблазн самоутвердиться за счет новенького.

[avitya]

А я делаю еще проще. Никогда не спрашиваю на интервью то, что можно за две минуты найти в документации.
Мне не важно, знает ли человек, сколько параметров у той или иной функции и какого они типа. Потребуется - найдет. Мне важно как он мыслит. Даю конкретную задачу (обычно из практики) и прошу на словах объяснить подход к решению. Потом лезем вглубь и разбираем отдельные нюансы, уже с использованием доски. Модель данных, необходимые процессы и преобразования, основные переменные и их передачу и т.п. Но писать на доске работающий код - верх идиотизма.
Еще один нюанс. Я всегда довожу кандидата до момента, когда он не сможет ответить на вопрос. Мне важно, как именно он это сделает. Если скажет "Ну-у-у, не знаю..." - один разговор. Если "На данный момент у меня нет готового решения, но дайте полчаса и доступ в Интернет - и оно будет" - совсем другой.

Почти всё верно Но я не согласен насчёт когда на доске. Человек должен суметь написать решение задачи. Придираться к пунктуации, типа ; забыта -- не стоит. Но как будут названы функции и переменные, каков стиль и оформление программы -- сразу видно на программе из 30 строчек. По такому принципу 95% индусов и 80% остальных у мненя просто не проходят. Если они не могут написать элегантный и внятный код на доске -- они не смогут его и в редакторе. Классический пример попросить написать двоичный поиск. (60% не могут неписать с первого раза рекурсивно, 80% итеративно).

[Lisa]

Я не могу и не собираюсь оспаривать ваши мудрые выводы по поводу данного кандидата, но мне просто интересно, как он умудрился работать программистом все эти годы? Я ведь полагаю, вы делали какой то чекап по его предыдущим местам работы, ну хотя бы через линкендин или просто смотрели референсы.

И еще. Вы писали что позиция до сих пор открыта. Лично у меня это не вызывает удивления.

Я поясню чтобы два раза не вставать.
Есть два подхода к интервью. Одни - выяснить что человек не знает. Второй - что он знает.
Есть два типа интервьюеров. Один - пытается показарть какой он крутой путем заваливания кандидата. Другой - пытается выяснить, что есть у кандидата хорошего и как его можно будет использовать лучшим образом в своем коллективе.

Мне уже к 60 и как верно заметил г. Коммисар, я старпер. Но за свою достаточно долгую программисткую жизнь я очень редко встречал совсем уж дураков которых нельзя использовать группе. И реально нет на самом деле проблемы научить человека не знающего что то за короткое время каким то навыкам, особенно в кодописании, которое не есть рокет сайенс, если он хочет работать и если у него умная голова. И еще раз повторю, дураков на самом деле не так уж много в нашей профессии.

Люди в резюме врут. Если человек заявляет что работал 10 лет с SQL и при этом не может написать простейший select или join из двух таблиц - мне пофиг как и где он умудрился до этого работать.
У меня нет ни времени ни людей кого-то чему-то обучать. Если бы мы хотели обучать то позициция была бы джуниор. А если уж позиционируешься как сениор, то ожидается что ты способен выдать результат самостоятельно без обучения элементарным вещам.

[nightmare2]

А я делаю еще проще. Никогда не спрашиваю на интервью то, что можно за две минуты найти в документации.
Мне не важно, знает ли человек, сколько параметров у той или иной функции и какого они типа. Потребуется - найдет. Мне важно как он мыслит. Даю конкретную задачу (обычно из практики) и прошу на словах объяснить подход к решению. Потом лезем вглубь и разбираем отдельные нюансы, уже с использованием доски. Модель данных, необходимые процессы и преобразования, основные переменные и их передачу и т.п. Но писать на доске работающий код - верх идиотизма.
Еще один нюанс. Я всегда довожу кандидата до момента, когда он не сможет ответить на вопрос. Мне важно, как именно он это сделает. Если скажет "Ну-у-у, не знаю..." - один разговор. Если "На данный момент у меня нет готового решения, но дайте полчаса и доступ в Интернет - и оно будет" - совсем другой.

Мне как-то ответили: "Я этого не знаю, но вы же меня научите".

[Lisa]

Я поясню чтобы два раза не вставать.
Есть два подхода к интервью. Одни - выяснить что человек не знает. Второй - что он знает.
Есть два типа интервьюеров. Один - пытается показарть какой он крутой путем заваливания кандидата. Другой - пытается выяснить, что есть у кандидата хорошего и как его можно будет использовать лучшим образом в своем коллективе.

Нормальный интервьюер выясняет знает ли кандидат то, что требуется для данной позиции. Позволить себе нанимать человека потому что то что он знает и умеет может в принципе пригодиться в будущем мало кто может. Гугл какой-нибудь разве что.

[nightmare2]

Я не могу и не собираюсь оспаривать ваши мудрые выводы по поводу данного кандидата, но мне просто интересно, как он умудрился работать программистом все эти годы? Я ведь полагаю, вы делали какой то чекап по его предыдущим местам работы, ну хотя бы через линкендин или просто смотрели референсы.

И еще. Вы писали что позиция до сих пор открыта. Лично у меня это не вызывает удивления.

Я поясню чтобы два раза не вставать.
Есть два подхода к интервью. Одни - выяснить что человек не знает. Второй - что он знает.
Есть два типа интервьюеров. Один - пытается показарть какой он крутой путем заваливания кандидата. Другой - пытается выяснить, что есть у кандидата хорошего и как его можно будет использовать лучшим образом в своем коллективе.

Мне уже к 60 и как верно заметил г. Коммисар, я старпер. Но за свою достаточно долгую программисткую жизнь я очень редко встречал совсем уж дураков которых нельзя использовать группе. И реально нет на самом деле проблемы научить человека не знающего что то за короткое время каким то навыкам, особенно в кодописании, которое не есть рокет сайенс, если он хочет работать и если у него умная голова. И еще раз повторю, дураков на самом деле не так уж много в нашей профессии.

Люди в резюме врут. Если человек заявляет что работал 10 лет с SQL и при этом не может написать простейший select или join из двух таблиц - мне пофиг как и где он умудрился до этого работать.
У меня нет ни времени ни людей кого-то чему-то обучать. Если бы мы хотели обучать то позициция была бы джуниор. А если уж позиционируешься как сениор, то ожидается что ты способен выдать результат самостоятельно без обучения элементарным вещам.

И что, такое реально бывает на interview?
Обычно народ сыпется на чем-то немного более сложном.
Например: не понимает разницы в уровнях изоляции или сложный update from не может правильно написать.
Некоторих напрягает задачка удаления дубликатов из таблицы без ключа.

[nightmare2]

Я поясню чтобы два раза не вставать.
Есть два подхода к интервью. Одни - выяснить что человек не знает. Второй - что он знает.
Есть два типа интервьюеров. Один - пытается показарть какой он крутой путем заваливания кандидата. Другой - пытается выяснить, что есть у кандидата хорошего и как его можно будет использовать лучшим образом в своем коллективе.

Нормальный интервьюер выясняет знает ли кандидат то, что требуется для данной позиции. Позволить себе нанимать человека потому что то что он знает и умеет может в принципе пригодиться в будущем мало кто может. Гугл какой-нибудь разве что.

Это в идеале, а на практике спрашивают то, что знают сами и считают, что это типа круто.

[Stoic]

Нормальный интервьюер выясняет знает ли кандидат то, что требуется для данной позиции. Позволить себе нанимать человека потому что то что он знает и умеет может в принципе пригодиться в будущем мало кто может. Гугл какой-нибудь разве что.

Осталось только определить что такое "нормальный интервиюер".
Меня как-то с понтом ПО ТЕЛЕФОНУ спрашивали какие-то головоломки решать совершенно неотносящиеся к предмету, про черные шары и обезьян, кубики рубика.
Уверен, что сами спрашивающие никогда бы сами их не решили, однако спрашивают...

[Lisa]

Нормальный интервьюер выясняет знает ли кандидат то, что требуется для данной позиции. Позволить себе нанимать человека потому что то что он знает и умеет может в принципе пригодиться в будущем мало кто может. Гугл какой-нибудь разве что.

Осталось только определить что такое "нормальный интервиюер".

Ну я же там написала, нормальный это тот кто выясняет знает ли кандидат то что требуется для позиции.

[valchkou]

Что нужно сделать программисту, чтобы ему задавали только один вопрос на интервью - how much do you want?.
понятно что надо как то имя создать, но как именно? что сделать?
тут писали, что некоторых брали только за то что их апп в applestore/androidmarket.
Как быть с жава например?

[Easbayguy]

Мне уже к 60 и как верно заметил г. Коммисар, я старпер. Но за свою достаточно долгую программисткую жизнь я очень редко встречал совсем уж дураков которых нельзя использовать группе. И реально нет на самом деле проблемы научить человека не знающего что то за короткое время каким то навыкам, особенно в кодописании, которое не есть рокет сайенс, если он хочет работать и если у него умная голова. И еще раз повторю, дураков на самом деле не так уж много в нашей профессии.

Очень редко встречается что у человека умная голова и его надо учить кодописанию, умные кандидаты все таки готовяться к интервью. Очевидно мы говорим о разных вещах, мы нанимаем человека работать с нами несколько лет и если он не тянет на интервью, то проще не нанять, чем потом учить ( operations). У нас всегда наготове молодые в дата центре, желающие перескочить в сисадмины.

[Lisa]

Если бы мы нанимали кого-то, кто может языком болтать и руками водить, сидеть на митингах важно надувая щеки и рисовать графики в MS Project, то его тоже бы не просили код на доске писать.

Это образ типичного PM, обычно на такие должности стремятся индусята либо молодняк, в виде протекционистких MBAs. Что очень НЕ ценится, и не очень хорошо оплачивается, если не блатной.
Technical/Operational/IT manager или просто даже team lead это несколько совсем другая работа.

Действительно хороший РМ ценится очень сильно, и найти его не проще чем найти хорошего девелопера. На всех виденых мной серьезных успешных проектах или был РМ, или его функции так или иначе выполнялись другими.

[nightmare2]

Если бы мы нанимали кого-то, кто может языком болтать и руками водить, сидеть на митингах важно надувая щеки и рисовать графики в MS Project, то его тоже бы не просили код на доске писать.

Это образ типичного PM, обычно на такие должности стремятся индусята либо молодняк, в виде протекционистких MBAs. Что очень НЕ ценится, и не очень хорошо оплачивается, если не блатной.
Technical/Operational/IT manager или просто даже team lead это несколько совсем другая работа.

Действительно хороший РМ ценится очень сильно, и найти его не проще чем найти хорошего девелопера. На всех виденых мной серьезных успешных проектах или был РМ, или его функции так или иначе выполнялись другими.

Обычно - это хороший team lead.
PM - персона не техническая и далека от деталей, как правило.

[Easbayguy]

И что, такое реально бывает на interview?
Обычно народ сыпется на чем-то немного более сложном.
Например: не понимает разницы в уровнях изоляции или сложный update from не может правильно написать.
Некоторих напрягает задачка удаления дубликатов из таблицы без ключа.

Реально сыпятся.

[Lisa]

Если бы мы нанимали кого-то, кто может языком болтать и руками водить, сидеть на митингах важно надувая щеки и рисовать графики в MS Project, то его тоже бы не просили код на доске писать.

Это образ типичного PM, обычно на такие должности стремятся индусята либо молодняк, в виде протекционистких MBAs. Что очень НЕ ценится, и не очень хорошо оплачивается, если не блатной.
Technical/Operational/IT manager или просто даже team lead это несколько совсем другая работа.

Действительно хороший РМ ценится очень сильно, и найти его не проще чем найти хорошего девелопера. На всех виденых мной серьезных успешных проектах или был РМ, или его функции так или иначе выполнялись другими.

Обычно - это хороший team lead.
PM - персона не техническая и далека от деталей, как правило.

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

[Stoic]

Если бы мы нанимали кого-то, кто может языком болтать и руками водить, сидеть на митингах важно надувая щеки и рисовать графики в МС Пройецт, то его тоже бы не просили код на доске писать.

Это образ типичного ПМ, обычно на такие должности стремятся индусята либо молодняк, в виде протекционистких МБАс. Что очень НЕ ценится, и не очень хорошо оплачивается, если не блатной.
Течницал/Оператионал/ИТ манагер или просто даже теам леад это несколько совсем другая работа.

Действительно хороший РМ ценится очень сильно, и найти его не проще чем найти хорошего девелопера. На всех виденых мной серьезных успешных проектах или был РМ, или его функции так или иначе выполнялись другими.

Обычно - это хороший теам леад.
ПМ - персона не техническая и далека от деталей, как правило.

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

[Lisa]

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

А если подумать зачем он делает?

[nightmare2]

Это образ типичного ПМ, обычно на такие должности стремятся индусята либо молодняк, в виде протекционистких МБАс. Что очень НЕ ценится, и не очень хорошо оплачивается, если не блатной.
Течницал/Оператионал/ИТ манагер или просто даже теам леад это несколько совсем другая работа.

Действительно хороший РМ ценится очень сильно, и найти его не проще чем найти хорошего девелопера. На всех виденых мной серьезных успешных проектах или был РМ, или его функции так или иначе выполнялись другими.

Обычно - это хороший теам леад.
ПМ - персона не техническая и далека от деталей, как правило.

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

Менеджер принимает решения и несет за них ответственность.
Надо же кому-то быть "козлом отпущения", если девелоперы не справятся.

[Stoic]

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

А если подумать зачем он делает?

Я ж вам как-то отвечал, что мне думать лень...Пусть лошадь думает ? (ц)

[Stoic]

Менеджер принимает решения и несет за них ответственность.
Надо же кому-то быть "козлом отпущения", если девелоперы не справятся. :Д

Наверно такое где-то есть, однако так проишодит в редких случаях ...
И как правило, плох тот [PM], который не смог найти крайних, на корню поломавших сроки

[Lisa]

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

А если подумать зачем он делает?

Я ж вам как-то отвечал, что мне думать лень...Пусть лошадь думает ? (ц)

Мне? Мы с вами вроде бесед не вели. Если думать лень, то не стоит ввязываться в дискуссии подразумеващие хотя бы минимальное напряжение мозга.

[Stoic]

РМ-у совершенно не надо быть сильно техническим, его роль совсем не в этом.

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

А если подумать зачем он делает?

Я ж вам как-то отвечал, что мне думать лень...Пусть лошадь думает ? (ц)

Мне? Мы с вами вроде бесед не вели. Если думать лень, то не стоит ввязываться в дискуссии подразумеващие хотя бы минимальное напряжение мозга.

Ну вы похоже сами не знаете, раз других думать просите

[fruit6]

А в чем ? Переложить в [MS Project Manager] то что ему технические специалисты скажут ?

А если подумать зачем он делает?

Я ж вам как-то отвечал, что мне думать лень...Пусть лошадь думает ? (ц)

Мне? Мы с вами вроде бесед не вели. Если думать лень, то не стоит ввязываться в дискуссии подразумеващие хотя бы минимальное напряжение мозга.

Ну вы похоже сами не знаете, раз других думать просите :-)

это такой стиль дискуссии, с помощью намеков и вопросов, чтобы не сболтнуть лишнего