Ранее, я повторно опубликовал две свои старые статьи (оригиналы: раз, два — прим. перев.), касающиеся процесса технических собеседований. Полагаю, что мог бы описать более подробно, как провожу собеседования и на что при этом обращаю внимание.
Вот мои главные цели:
- не нанимать плохих работников;
- нанимать хороших работников;
- оставить кандидата с положительным впечатлением о компании.
Конечно же, избежать найма плохого работника — гораздо важнее, чем нанять хорошего. Если мы не заполучим отличного сотрудника — это очень плохо, но неудачный подбор персонала может снизить производительность команды на годы.
Последний пункт также является ключевым; если мы хотим принять человека на работу, то, очевидно, должны произвести хорошее впечатление. Но мне также хочется, чтобы все, получившие отказ — также оставались хорошего мнения о нас. У них есть друзья, которые, возможно, захотят собеседоваться. Когда-нибудь они могут принимать решение о покупке нашего продукта, либо рекомендовать его. Собеседование — это дорогостоящий бизнес-процесс; если он не приведет к найму, то, быть может, мы получим клиента, или хотя бы большую благосклонность к себе.
Собеседование проходит следующим образом.
Прежде всего, я должен убедиться, что соискателю комфортно, есть чем утолить жажду, не хочется в туалет, и так далее. Затем, если человек уже собеседовался у кого-то до меня, то я спрашиваю «Как дела?». Цель этого вопроса — разрядить атмосферу, завязать разговор, и посмотреть, есть ли у кандидата какие-либо вопросы касательно прохождения собеседования. Иногда у меня есть информация о том, как уже показал себя кандидат, но она не предназначена для принятия решений. (В Microsoft поощрялось давать обратную связь следующим в цепочке интервьюерам как можно скорее, чтобы они могли копать в сторону потенциальных проблем; в Coverity мы более склонны к тому, чтобы каждый интервьюер начинал беспристрастным. Оба подхода имеют свои плюсы и минусы.)
После этого, я выбираю из резюме кандидата что-нибудь интересное и не слишком старое, сперва прошу дать мне «Elevator Pitch» — несколько предложений, описывающих проект, чем он был интересен, важен — а затем прошу более подробно описать решенную в этом проекте проблему.
Это, опять же, поможет кандидату расслабиться, поскольку он рассказывает о чем-то из своего резюме, и, вероятно, хорош в этом. Я хочу выяснить в первую очередь — может ли собеседуемый нормально общаться? Вы будете удивлены, какое количество людей не может рассказать одним-двумя предложениями о вещах из своего резюме. Во-вторых, чем на самом деле они занимались на этом проекте? Это может шокировать, но люди постоянно приукрашивают свои заслуги. Изучив подробности того, что именно сделал кандидат, я могу понять, действительно ли он «умен и доводит дело до конца» (smart and gets stuff done — прим. перев.) или нет.
Затем мы переходим к действительно интересному этапу: техническая задача. Цель — выяснить, способен ли кандидат писать тот сорт кода, который необходимо будет писать каждый день. Мне известно, что написание кода от руки на доске критикуют, и я с согласен с этой критикой. Это неестественная обстановка, не такая как при реальном написании кода, это стрессовая ситуация и т.д. Я стараюсь придумывать вопросы, минимизирующие подобные трудности, но все еще способные показать мне, справится ли кандидат с реальной работой. (А если человек не желает писать код на доске, мы можем сделать это на компьютере. Однако, задаваемые мной вопросы редко требуют написания более чем шести строк кода. Самые лучшие соискатели должны быть в состоянии написать полдюжины коротких строчек и без помощи текстового редактора.)
И этот этап действительно важен. Я проверяю, чтобы претенденты соответствовали необычному набору требований. Кандидаты в команды, работающие над инструментами анализа языка, должны быть сильны в теоретических основах информатики, и в то же время способны работать в реальном мире несовершенного кода. Я собеседовал прорву глубоко понимающих теорию ученых, при этом неспособных написать реальный код, а также опытных промышленных программистов, которые не могли сказать мне, что такое бинарное дерево.
Хорошая техническая задача имеет следующие характеристики:
- может быть поставлена ??и решена небольшим количеством кода за малое время;
- не требует внезапного озарения, чего трудно добиться в стрессовой ситуации;
- это не загадка с подвохом;
- по желанию может быть сделана труднее, либо легче, для того, чтобы лучше оценить уровень кандидата;
- похожа на проблемы, которые соискатель должен будет решать на рабочем месте;
- тестирует не только написание кода, но и другие навыки, такие как умение читать существующий код, или иметь дело с нечеткими требованиями;
Задача, которую я долго использовал в Microsoft, и которая работает даже лучше в Coverity, имеет следующую схему:
Во-первых, есть два написанных на C++ метода из публичного API, каждый из которых состоит из трех строк очень простого кода. API управляет «задачами» на «сервере», и используется «клиентом». Сценарий намеренно очень размыт, но код понятен. Я провожу кандидата по каждой строке и убеждаюсь, что он понимает код. Здесь мне необходимо только базовое понимание простого синтаксиса (подавляющее большинство кандидатов знакомы с C++ согласно их резюме, так как это необходимое требование для работы).
Далее, я поручаю кандидату исследовать этот код на наличие любых проблем. И наблюдаю, в какую сторону он копает при исследовании чужого кода. Представленный код имеет проблемы дизайна, надежности, безопасности, тестируемости и переносимости. Я смотрю, какие проблемы кандидат находит самостоятельно, а если он что пропускает, могу подсказать: «Если клиент намеренно попытается нарушить работу сервера, что вы сделаете?» или «Что будет, если скомпилировать этот код для запуска на 64-разрядной машине?» и посмотрю, поймет ли он намек.
Это реальный навык, который мне необходимо использовать каждый день — во-первых, при code review собственного кода и кода моих коллег. А во-вторых, мой бизнес — написание программ, анализирующих забагованный код и определяющих, что он забагован. Если соискатель не способен проверить чужой код — маловероятно, что он будет успешен вообще где-либо. У того, кто не может найти ни одну из десятка ошибок в программе, содержащей шесть инструкций — вряд ли получится написание анализатора кода, находящего ошибки.
Здесь я ищу понимание, критическое мышление и базовое знание предметной области. Часто на этом этапе проявляются сигналы опасности. У меня были претенденты с «PhD in computer science», которые не знали, например, что в 64-битной архитектуре длина указателя составляет 64 бита. Да и зачем им знать? Как говорится, астрономия — это не наука об изготовлении телескопов. Обширные знания теоретической информатики не обязательно влекут за собой знания о пропускной способности шины между процессором и памятью. Но кандидат, не понимающий, как указатели реализованы в распространенных архитектурах — вряд ли будет успешен, работая в команде по разработке анализаторов, которые ищут связанные с длиной указателя ошибки.
Также многие соискатели определяют ошибки в коде, но не могут описать их последствия. Неопределенное поведение по определению не определено. Но описание того, что может произойти, если вредоносный клиент назначает указатель на произвольный кусок памяти (англ. pointer to arbitrary memory — прим. перев.) и заставляет сервер выполнить виртуальный метод с таким указателем — демонстрирует понимание, как на самом деле компилятор генерирует код.
Это первая фаза технической задачи. Следующий этап включает в себя дизайн, и, возможно, некоторые небольшое количество кодинга. «Вы можете изменить реализацию API, но не сигнатуры методов — как бы вы исправили каждую из найденных ошибок?». Опять же, это основной рабочий навык, который нам приходится использовать каждый день: исправление ошибки на «сервере», будучи не в состоянии изменить поведение «клиента». Возможно, вызывающий код принадлежит заказчику, или другой команде, либо уже продан, да что угодно.
На данном этапе я обращаю внимание на следующее:
- Есть ли еще сигналы опасности? Боже, количество кандидатов, пытавшихся решить проблему переносимости путем сжатия 64-битного указателя в 32-разрядное целое число — огромно. Тут нет хитрой загадки, которую я прошу разгадать. Вы не можете поместить двадцать фунтов муки в десятифунтовый мешок. Должно быть очевидно, что необходимо найти другой способ решения проблемы.
- Какие инструменты могут быть в багаже соискателя? Все кандидаты в конечном итоге понимают, что им необходимо добавить вспомогательную структуру данных для маппинга из 32-битного целого числа в 64-битный указатель. Известны ли им существующие реализации такого маппинга? Если нет, уверены ли они, что смогут написать подобное?
- Может ли кандидат выделить действительно сложную часть задачи? Сложность здесь — не в осознании необходимости маппинга, а в том, чтобы обеспечить уникальность ключей при добавлении новой пары ключ-значение (как я упоминал в предыдущем эпизоде, оригинал — прим.перев.). Даже когда я неоднократно спрашиваю: «В вашем решении вы так и не рассказали, как вычислить значение ключа — так как генерируется это значение?», некоторые кандидаты просто не обращают на это внимания и продолжают объяснять мне, как работает маппинг. Либо они возвращаются к предыдущей точке и пытаются сжать 64-битное значение в уникальный ключ 32-бит, что невозможно, и что является причиной маппинга.
- Как кандидат выйдет из подобной неоднозначной ситуации? Проблема умышленно размыта, неясна, и трудная часть заключается в генерации уникальных значений. Если есть два клиента, каждый из которых создает по две «задачи», а затем отключается, то сгенерировать уникальные 32-битные целочисленные ключи несложно. Если есть миллионы клиентов, генерирующие миллионы «задач», то получать уникальные ключи может быть очень трудно. Многие кандидаты никогда не спрашивают меня, сколько клиентов и «задач» есть в этой системе, и поэтому некоторые выдают слишком переусложненные идеи, а кто-то предлагает решение, которое немасштабируемо в принципе.
- Может ли кандидат провести параллели с решенными ранее проблемами? Это трудно сделать в стрессовой ситуации, но на подобное все равно интересно посмотреть. Некоторые кандидаты очень быстро осознают, что проблема «сгенерировать уникальный 32-битный номер, и не использовать повторно его до тех пор, пока клиент не закончит с ним» должна была быть ранее решена тем, кто написал 32-битную версию менеджера памяти. В конце концов, что такое менеджер памяти (англ. memory manager — прим. перев.): устройство, которое предоставляет вам по запросу уникальный указатель, и не выдает этот же указатель вновь до тех пор, пока вы его не освободите. Поэтому сформулированная мной проблема может быть сведена к ранее решенной. Некоторые кандидаты рассуждают о выделении памяти и подобных вещах, как о магии. Многие поняли, что проблема аналогична реализации кучи; но только один сказал: «Я решу проблему, получив от Windows кучу объемом в 4 миллиарда байт, а затем буду выделять отдельные байты из кучи для того, чтобы генерировать уникальные 32-битные числа» (англ. I’ll solve the problem by having Windows make me a four billion byte heap, and then allocate single bytes out of it to generate unique 32 bit numbers — прим. перев.). Это действительно сведет задачу к уже решенной!
Если кандидат справляется очень хорошо, то усложнить задачу достаточно просто. Предположим, клиенты используются многими потоками; какая стратегия синхронизации сохранит высокую пропускную способность? Допустим, состояния задач должны быть сохранены при перезагрузке компьютера. Что если сервер в кластере и может перенаправить нагрузку на другие сервера. Я хочу выяснить, насколько глубоки их знания. Или я могу упростить задачу, ограничив число клиентов десятью. Предположить, что «задачи» стартуют и завершаются в некотором определенном порядке, так что следующая «задача» стартует после того, как завершается предыдущая. И так далее. Мне бы хотелось, чтобы соискатели почувствовали, что справились с хоть с какой-нибудь проблемой.
В конце собеседования я стараюсь выгадать немного времени, чтобы кандидат успел задать вопросы о команде, вакансии, компании и т.д. (никто ни разу не спросил: «Напишете код, разворачивающий связанный список?», и я был бы очень удивлен, если бы кто-то это сделал). Для меня это еще одна возможность «прорекламировать» нашу компанию, а также понять из вопросов соискателей, что для них важно.
Комментарии (35)
0x13
25.06.2015 17:38+7опытных промышленных программистов, которые не могли сказать мне, что такое бинарное дерево
Простите, а чем их опыт измеряется тогда, годами чтоли?
Кстати, описанная в статье задача выглядит гораздо более адекватной, чем куча мелких задач на комбинаторику или алгоритмы, что заставляют решать на большинстве собеседований. Человек на собеседовании показывает, как быстро генерировать перестановки или какова вероятность бросания n-мерного кубика со смещенным центром тяжести, а потом устраивается на работу и изо дня в день исправляет неправильное отображение диалогов на экране или проектирует базы данных. Если мы говорим не про найм олимпиадников для оптимизации каких-нибудь баз данных в памяти, то большая задача, которая позволяет в комплексе оценить умение человека думать, гораздо более важна, чем
Но про основы автор, безусловно, прав. Меня вот иногда приглашают принимать экзамен по архитектуре компьютеров у студентов второкурсников, мне половина не отвечает, как отрицательные целые числа в памяти представляются в x86. А что такое виртуальная память, отвечает при лучшем раскладе только каждый четвертый. И это топовый российский вуз, ага.0x13
25.06.2015 18:35«гораздо более важна, чем знание пары конкретных алгоритмов». Куда-то конец фразы пропал.
Dywar
25.06.2015 21:17Часть людей все таки отвечают на все вопросы, или интерес к невидимым подробностям иссекает со временем?
0x13
25.06.2015 21:30+1Невидимые подробности — это Вы о чем? Я не очень понял вопроса, если честно.
Dywar
25.06.2015 21:39Я имею ввиду подробности работы компьютера и ОС. Работает и ладно, что там внутри интересует немногих.
И все таки, были ли случаи когда отвечали на все вопросы, или когда сами задавали такие что глаза на лоб? :)0x13
25.06.2015 21:42+1Работает и ладно, что там внутри интересует немногих.
Надеюсь, это все же была шутка.
Отвечают на все вопросы многие. К счастью, вершина айсберга никуда не делась, и она не такая уж и маленькая. Многие осознают, зачем пришли в университет, и им интересно учиться.
Quilin
26.06.2015 11:05Но есть ли по-вашему какой-то необходимый предел низкоуровневости знаний? Скажем, нужно ли знать особенности интерфейса взаимодействия процессора с северным мостом? Или, если это был неудачный пример, достаточно ли знать сложность сортировки бинкучи или нужно уметь доказать эту сложность?
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.0x13
26.06.2015 11:58Я бы сказал, что есть необходимый минимум, который должен знать каждый уважающий себя разработчик ПО независимо от области, в которой он работает. Если говорить про железо, то это общая архитектуры компьютера и влияние физических характеристик железа на работу программ. Например, человек должен понимать, чем ограничен максимальный объем подключаемой оперативки, что такое кэш процессора, как хранятся типы данных в памяти, как происходит работа с ними и т.п.
Аналогично про алгоритмы и структуры данных — списки, стеки, очереди, деревья, хеш-таблицы, графы: концепции абстрактных типов данных, хотя бы самые базовые реализации и алгоритмы работы с ними. Упрощенно задача программиста — решить задачу наиболее быстро и эффективно, для этого надо быть в состоянии выбрать наиболее подходящие для нее инструменты. Ну а для этого, в свою очередь, надо понимать, чем структуры данных между собой различаются, осознавать понятие сложности алгоритмов.
Это не полный список, но, я надеюсь, идея понятна. Все это составляет базовую культуру в этой области. Не знать таких вещей — это как не знать, что Земля круглая или когда была Вторая мировая война: жить можно, но непонятно, что от такого человека ждать. У меня есть цикл лекций по основам программирования как раз для студентов первого курса (практически нулевой порог вхождения), как раз вот эти фундаментальные вещи. Если интересно, я могу опубликовать тезисно его как-нибудь тут для обсуждения. Вопрос, что есть минимум, правда интересный.
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.
Конечно не стану. Предел каждый для себя сам определяет. Если интересно ковыряться в алгоритмах, например, кто же запретит. Если же задача в «расширении кругозора», то остановиться стоит, на мой взгляд, когда качество начинает требовать количества. Хороший пример — спортивное программирование: чтобы добраться до уровня середнячка, надо очень многое узнать и попробовать, а вот чтобы выбраться в топ, надо очень много тренироваться на однотипных задачах, набивая руку. Понятно, что последнее не имеет особого смысла для тех, кто просто хочет подтянуться в алгоритмах, скажем.Quilin
26.06.2015 12:11+1Очень странно, что перечислив достаточно низкоуровневые вещи, вы упустили вещи уровнем повыше: работа компиллятора, GC, транзакции в базах данных и многое другое. Это тоже вещи, с которыми сталкивается «каждый уважающий себя разработчик ПО». Но какой смысл знать, сколько места занимает указатель в 64хбитной системе, если ты написал код, который после компилляции никогда не освободит этот указатель?
Нужно ли мне уметь написать красно-черное дерево, если оно уже есть в стандартной библиотеке и покрыто всевозможными тестами, или мне достаточно знать ситуации, когда его следует/не следует использовать?
Хватит ли времени на изучение всего вами перечисленного одновременно с перечисленным и не перечисленным мной? Мне кажется, нет. А тут, простите, ни слова еще не сказали об архитектуре приложений, в которой, на мой взгляд, любой уважающий себя программист тоже должен разбираться. И как же быть с новыми технологиями, в зоопарке которых (и это уже не мое мнение, а реальное положение рынка труда) мы все обязаны свободно плавать?
Это, конечно, тема для холивора. Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».0x13
26.06.2015 12:27+1Согласен, работа компилятора, управление памятью, основы БД, архитектура ПО, основы ООП, ФП, параллельного, сетевого программирования и многое другое — это все фундамент, который надо знать. Зоопарк технологий я бы в него включать не стал: грамотный человек, понимающий общий принцип (у которого сформирован вот этот фундамент), вполне в состоянии разобраться с новым языком или технологией за вполне разумное время.
Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».
Если человек не знает, что такое указатель, но умеет им пользоваться — это все равно карго-культ, который рано или поздно выстрелит ему в ногу или голову. Такого человека я бы на работу не взял даже стажером. А вот если он не умеет написать красно-черное дерево, но знает, зачем вообще нужны деревья и может реализовать BST (или хотя бы рассказать алгоритм работы с ним), например, у него гораздо больше шансов.Quilin
26.06.2015 12:45Ну, в целом я с вами согласен, но я бы смог работать с человеком, который не понимает в алгоритмы, но понимает в красоту кода, что после него хотя бы можно оптимизировать написанное без особого труда. Потому как встречались разработчики, которые замечательно разбираются в таких вещах, но пишут код, сложность которого зашкаливает и в котором кроме них никто не разбирается. Этот код работает и работает быстро, а разраб сел на высокую зарплату и теплое место. Казалось бы, всюду плюсы. Ан нет.
0x13
26.06.2015 12:48Я бы тоже не смог :)
strannik_k
26.06.2015 16:48Хочу сказать, что знания зависит от области, в которой человек работает, и какие задачи он обычно выполняет.
Вот вы, в какой области работаете?
Если будут вопросы по «базовым вещам»: «алгоритмы, структуры данных, тонкости синтаксиса языка» — то с большей вероятностью наймете студента, а не опытного программиста. Просто у студента свежие знания из института, а промышленный программист это все уже подзабудет, т.к. почти никогда не использует в реальных задачах.
Это все, безусловно, полезно знать, но если не нужно использовать в работе, то человек это забудет рано или поздно.
Тогда в чем опытность?
Способность одному и в команде сделать проект длительностью разработки не несколько месяцев, а несколько лет; знание стека технологий в данном направлении; знание различных инструментов разработчика и умение ими пользоваться; умение писать понятный другим код; умение проектировать архитектуру, которую не надо переделывать при каждом малейшем изменении требований; понимание, что есть готовые решение и не нужно писать велосипеды и т.д.0x13
26.06.2015 17:02Хочу сказать, что знания зависит от области, в которой человек работает, и какие задачи он обычно выполняет
Специальные знания, конечно, зависят от конкретной области работы, но базовые фундаментальные знания одинаковы для всех. Или Вы считаете, что, скажем, веб-программисту, необязательно знать, как куча и стек работают?
Это все, безусловно, полезно знать, но если не нужно использовать в работе, то человек это забудет рано или поздно.
Что забудет, как бинарное дерево поиска работает или что такое виртуальная память? Опять же, я говорю о базовых вещах, которые нельзя «развидеть», если понял принцип :)
С последним абзацем я согласен, только редко уж больно встречаются такие самородки, которые без образования это все могут.Quilin
26.06.2015 17:48С последним абзацем я согласен, только редко уж больно встречаются такие самородки, которые без образования это все могут.
Вот тут путаете корреляцию с зависимостью, мне кажется. Хотя и поучиться пришлось в разных университетах и поработать с выпускниками разных университетов, не встречал пока такой учебной программы, где про архитектуру рассказывали бы что-то посложнее UML. Максимум — уровня «паттерн стратегия» и то не преподы, а приглашенные программисты.0x13
26.06.2015 17:56Ну вот
есликак у меня руки дойдут свою программу четырехсеместрового курса выложить сюда, посмотрите, может покритикуете, там весь третий семестр про архитектуру. Правда, практика показывает, что толку от одной теории мало, так что у нас потом все это закрепляется в студпроектах и летних школах по программированию.
chumakov-ilya Автор
26.06.2015 18:00+1По-моему опыту, многие преподаватели в вузах считают фундаментальными именно те предметы, которые сами и преподают :) Так и в программировании, спросите программистов из различных областей (пусть будут, например, микроконтроллеры и JavaScript), какие знания они считают фундаментальными для своей работы — мне кажется пересечений будет мало.
0x13
26.06.2015 18:03+2По моему опыту это тоже так. :) Причем чем экзотичнее предмет, тем больше преподаватель считает его самым основным.
А Вы вот какие знания считаете фундаментальными для грамотного разработчика ПО? Вот абстрактно, без специализаций, этакая азбука для программиста.chumakov-ilya Автор
26.06.2015 19:34+1Полагаю, что знания — дело приходящее. А необходимыми для всех 100% программистов являются, скорее, личные качества — логическое мышление, так называемый «технический склад ума» и т.п.
strannik_k
26.06.2015 18:04Попробую Вас убедить, что если не используется, забывается все :)
Сможете посчитать дискриминант или вспомнить теорему косинусов? Конечно, может Вы математик, и такой вопрос для Вас простой.
Или Вы считаете, что, скажем, веб-программисту, необязательно знать, как куча и стек работают?
Можете привести пример, как это ему пригодится не в 1% решаемых задач, а хотя в 10%?
Если в его задачи не входит оптимизация производительности, то скорее всего нет.
Знание, например, что типы значений копируются при присваивании, а у ссылочных типов при этом копируется ссылка — важно, но это не имеет отношение к тому как куча и стек работают.
Про стек как структуру данных полезно знать любому программисту. Нечасто, но когда-нибудь пригодиться.0x13
26.06.2015 18:12Сможете посчитать дискриминант или вспомнить теорему косинусов?
Оказывается, помню, но не суть. Я же не профессиональный математик, мне теорему косинусов не грех и забыть лет этак через 10, но вряд ли какой-то геометр ее когда-то забудет. То же самое и с программированием, разве нет? Профессионал не может забыть основы своей области.
Можете привести пример, как это ему пригодится не в 1% решаемых задач, а хотя в 10%?
А что, в джаваскрипте сборку мусора уже отменили? Я временами встречаю страницы, на которых была такая дикая работа с памятью, что плакать хочется. Оптимизация производительности в таком случае — это уже исправление последствий неграмотности разработчика.strannik_k
26.06.2015 19:38Профессионал не может забыть основы своей области.
Полностью все — нет. Многое из того, что долго не приходилось использовать — забудет:) Или по крайней мере будет гораздо хуже помнить, чем раньше.
Вы преподаете — поэтому основы хорошо помните. Вам их каждый год надо студентам объяснять.
А что, в джаваскрипте сборку мусора уже отменили? Я временами встречаю страницы, на которых была такая дикая работа с памятью, что плакать хочется. Оптимизация производительности в таком случае — это уже исправление последствий неграмотности разработчика.
Тут скорее последствие того, что один разработчик пишет серверную часть, работает с базой данных, занимается администрированием сервера, версткой страниц под разные браузеры и пишет js код на клиенте. И все это на постоянно меняющихся технологиях. Это сколько потребуется времени, чтобы во всем этом экспертом стать? Естественно, что будут пробелы в том или ином месте. Ну и второй момент, что большинству работадателей нужно пораньше сделать продукт и начать получать с него прибыль. Кому нужен круто сделанный оптимизированный программный продукт, который не приносит прибыли? Если он уже приносит прибыль и становятся видны проблемы с производительностью и т.п., то тогда встает вопрос об улучшении.
Про javascript — не знаю. Про C# знаю. Но, думаю не важно. Что в сборке мусора конкретно нужно знать, без чего нельзя написать нормально работающую программу?
Ладно, я Вас не убедил. Давайте последний Ваш пост и не будем продолжать далее холивар:)
aparamonov
25.06.2015 19:38+1Все таки
how’s it going so far?
переводится какКак дела?
, а не какНу как все проходит?
, что не имеет смысла в русском языке.chumakov-ilya Автор
25.06.2015 19:56Точно! Спасибо, поправил.
indigo
27.06.2015 03:48Всё–таки «so far» в этой фразе не просто так. Имеется в виду вопрос: «как проходит собеседование?» — в смысле доволен ли кандидат собой и/или собеседующими, не устал ли он, как вообще себя чувствует, но именно в контексте сегодняшнего дня и конкретно данного собеседования, а не в целом.
Я не знаю, как правильно, понятно и полноценно перевести этот вопрос (мой вариант потребовал 3 строчки пояснений, так что он далек от идеала), да это наверное и не очень важно; я лишь хотел обратить внимание на это «so far», которое придает вопросу более конкретный оттенок, нежели «how's it going?» или «how're you?»chumakov-ilya Автор
27.06.2015 10:35+1спасибо, я так и пытался перевести изначально, в итоге между корявым и лаконичным вариантом выбрал лаконичный.
Wayfarer15
25.06.2015 21:34Описанное интервью, это где-то примерно третье интервью на пути потенциального кандидата. Большинство (не знакомых с особенностями интервью в западных компаниях) не прорвётся даже через первые вопросы первого интервью, которые будут звучать примерно как «Tell me about yourself», «Tell me about a time when you failed», «Tell me how you deal with a conflict situation» и т.д. и т.п. на протяжении часа.
0x13
25.06.2015 21:38+1Да, у меня половина знакомых на этих вопросах тихо расплачется и медленно поползет к выходу :)
Wayfarer15
25.06.2015 22:37Пол-года, годик поработают на лесопилке или на разноске газет (реальные истории), и не только не расплачуться, но и выучат ответы штук на 100-200 подобных вопросов так, что от зубов будет отлетать. Конечно, возможно вариации, но если компания достаточно большая, то первая линия защиты будет примерно такой.
Elevator Pitch в статье выше и есть вопрос «Tell me about yourself», на который ожидается вполне определённый ответ (минут на 5-ть). Если кандидат начнёт что-то вроде «в ХХ-ых годах я пошёл в детский сад, потом в школу, потом...» то вероятно на нём тут же поставят крестик, хотя и продолжат интервью.0x13
25.06.2015 22:44+2Ну не скажите. Одно дело, когда человека спрашивают о проекте, в котором он работал (конкретные факты, которыми он может оперировать), а другое дело — спрашивают его о том, кем он видит себя через пять лет (невнятная перспектива, про которую он, может, и не думал никогда). И эти товарищи не будут на лесопилке или разноске газет работать. К счастью для них, у нас в России много компаний (и западных в том числе), которые учитывают большой процент интровертов в индустрии и не особо стремятся задавать такие вопросы, особенно в течение часа.
Wayfarer15
25.06.2015 23:01Разве Эрик Липперт работает в российском отделении Microsoft? Ну тогда забираю свои слова обратно. В противном случае, всё сказанное мной основывается на собственном и многочисленном опыте других.
0x13
25.06.2015 23:06+3А где я говорил про Microsoft? Я сказал, что в России есть много компаний, в том числе и филиалов западных, где такие вопросы на собеседованиях не задают.
SerJook
26.06.2015 12:32+4Ой, был я однажды на собеседовании в «западной» конторе, ну позадавали мне подобных тупых вопросов, я был злой, рявкнул на них.
Уже потом я узнал, что мое место занял человек, который программировать нихрена не может, плодит г-код, и только трепать языком умеет.
Так что не ясно, кто тут выиграл, а кто тут проиграл.
vladlichonos
26.06.2015 21:11+1Верно. К примеру такая штука модная в США, где мол нанимают general developer! «lean team» так что и скорость кодинга и самого кода тоже важна! Хотя ищут конкретно Sr. Android Developer к примеру. Но задать вопросы на тему сортировки списков, бинарный дерев ну просто необходимо, да еще онлайн и по телефону/google hangouts. Так что, нужен обычно Sr. Android Developer, а нанимают студентов у которых свежие знания с универа. Так и живем тут.
p.s. сейчас сам иду через этот процесс, докатился что MIT лекции онлайн смотреть начал оп data structures & algorithms.
igrishaev
>> умен и доводит дело до конца
эта фраза — отсылка к Спольски и его статье о собеседованиях — russian.joelonsoftware.com/Articles/Interviewing.html