На самом первом собеседовании я даю задачку на HackerRank и смотрю, как кандидат ее решает. Задачку даю простую, чуть-чуть сложнее, чем FizzBuzz. Зачем? Для того, чтобы убедиться, что кандидат умеет программировать, то есть может, получив практически чистое описание несложного алгоритма, взять и закодировать его на том языке, который он выберет сам. И да, я периодически встречаю кандидатов, у которых 10 с лишним лет опыта работы, все резюме заполнено крутыми технологиями, но закодировать простой алгоритм они не в состоянии.
Знают отличие — да, все. Понимают, что из этих отличий следует (производительность, сильные и слабые стороны) — далеко не все. Осознанно принимают решение, что использовать — из джунов почти никто.
Я не говорил ничего об уме и глупости, и уж никак не развешивал ярлыки. Я просто увидел в представленном «резюме» характерные признаки джуниора, о чем и сказал. Если угодно, могу показать, что именно меня привело к этой оценке.
— Из текста я предполагаю, что основной язык, на котором работает кандидат — Ява. В таком случае от синиора я бы ожидал глубокого знания системы программирования Явы, в частности — понимания того, как работает Garbage Collector. Без этого тяжело предсказывать производительность систем, оптимизировать, бороться с утечками памяти (с их Явским вариантом). (Заявление об интерфейсах меня насторожило, но тут мне, как нанимающему менеджеру, было бы интересно побеседовать с кандидатом на эту тему.)
— Я бы ожидал от синиора понимания принципов хорошего дизайна и следования им, даже если код никто читать не будет. Это относится к использванию инкапсуляции, public properties и т.п., тем более что отказ от них не дает никаких преимуществ.
— По поводу ArrayList и LinkedList, от синиора я бы ожидал немного другого заявления: «Я знаю, в чем разница между ними, и понимаю, когда следует использовать какой, но во всех моих проектах мне хватало ArrayList'a»
По поводу Soft Skills (в вопросе «джуниор или синиор» для меня они гораздо важнее технических).
— По поводу «делать каку». Синиор смотрит не на то, что нужно сделать, а на то, какую задачу нужно решить, и при этом прилагает все усилия к тому, чтобы каки не получилось, ни внутри ни снаружи. Если появилось требование сделать каку, синиор выяснит, откуда оно идет, почему оно возникло, убедится, что все понимают, почему это кака, и постарается придумать и предложить хорошее решение. Если выхода нет, он, конечно, каку сделает, но только когда все остальные варианты невозможны.
— Если синиору есть, что сказать, он не молчит на совещаниях. Если сказать нечего, то он, скорее всего, на этом совещании не нужен.
Человек, который, несмотря на опыт работы, так и не поднялся выше джуниора. Ни по знаниям, ни по пониманию того, как и почему функционируют команды и компании.
Занятно — я тоже живу в Америке последние лет двадцать. В русском диалоге «Я достаточно подвинул стул? — Да, отлично» слово «отлично» не означает что стул подвинут так уж замечательно. Это подтверждение, с оттенком похвалы. Именно так и звучит слово «perfect» в вашем примере. «Good job», конечно, может в определенных ситуациях и с определенными интонациями означать ироничное «ты подаешь надежды», но в большинстве случаев это все-таки мягкая утверждающая похвала, что-то типа «Молодец.»
А к статье я не придираюсь; идея статьи сама по себе хороша, и «very good» можно и нужно заменять адекватными синонимами. Ключевое слово тут — адекватными. И беда в том, что у тех, для кого эта статья предназначена (а это, прошу заметить, не мы с вами), нет возможности оценить контекст, в котором предлагаемые замены будут или не будут работать.
Да, присоединюсь к уже прозвучавшему мнению: многие из предложенных в статье замен имеют иной оттенок или, увы, просто неверны.
«VULGAR» имеет совсем иной смысл, чем «VERY RUDE». Vulgar — вульгарный, пошлый, безвкусный.
«DULL PERSON», конечно, можно сказать, но звучит странно. Скорее, скажут moron, idiot.
«PERFECT» — больше, чем very good. Perfect — значит, идеально.
«UNIQUE POINT» — может означать разные вещи, очень-очень зависит от контекста. Вполне может прозвучать в качестве иносказания для «Запредельный идиотизм».
«RAVENOUS» — редкое слово, не разговорное. Лучше сказать «starving».
«RAPIDLY» имеет специфический смысловой оттенок. Например, по-русски можно сказать и «Он очень быстро выхватил кинжал» и «Он мгновенно выхватил кинжал». Но вот «Он очень быстро ездит» можно, а «Он мгновенно ездит» — нельзя. В предложении в статье та же проблема.
Я подозреваю, что «JavaScript. Сильные стороны» изрядно устарела. Я читал ее вскоре, после ее выхода, и тогда это было здорово, но с тех пор сам JavaScript изрядно изменился.
Меня, честно сказать, потрясла последняя история. Я себе представляю ситуацию: вот я провожу интервью, мне кандидат не нравится, я так и говорю. После этого рекрутер устраивает телефонный разговор на эту тему, и вдруг начинает нападать на меня и на мой код на Гитхабе?! Честно скажу — я бы в этой ситуации принял все меры, чтобы моя компания больше не работала с этим самым рекрутером. Никогда. Ибо более непрофессиональное поведение рекрутера себе трудно представить.
Очень часто одна и та же ситуация может совершенно по-разному восприниматься начальником и работником. То, что начальник видит как нормальное полюбовное расставание, подчиненный может воспринимать неожиданно эмоционально. Был случай в компании, где я работал много лет назад: попал мужик один под сокращение, вежливо со всеми попрощался и спокойно ушел. И в тот же день зачем-то взял и выложил адресную книгу компании в открытый доступ — с адресами электронной почты, телефонами и т.п.
Я думаю, что увольнять надо одномоментно. Поговорили, попрощались, закрыли всесь доступ, забрали пропуск, проводили из здания. Зарплату можно потом еще платить, но пускать к рабочим материалам уже не стоит.
Вообще я не знаю, насколько безопасно для компании позволять человеку, знающему, что его увольняют, продолжать работать. Возможны самые разнообразные последствия.
По поводу писания кода на доске — я всегда прошу сделать это в начале разговора. Задачу предлагаю примитивную, с очевидным алгоритмом, и ни в коем случае не придираюсь к синтаксису и мелким огрехам. Например, я прошу написать функцию Fib (n), которая будет возвращать n-ое число Фибоначчи. При этом я охотно напоминаю определение чисел Фибоначчи. Почему я это прошу? Да потому, что я считаю, что преобразование алгоритма в код — это основное умение программиста. Человек, который не в состоянии, получив определение чисел Фибоначчи, написать функцию, их вычисляющую, вряд ли будет способен нормально программировать.
По поводу теоретических вопросов — большое О и так далее. У программиста должна быть теоретическая база, должно быть представление об алгоритмах, их сложности и т.п. Понятно, что в наше время все можно погуглить и найти — так вот, программист должен понимать, что именно гуглить. Я не считаю, что программист обязан уметь определять сложность алгоритма; но иметь представление о том, что это такое, понимать, что логарифмическая сложность лучше линейной, и чем чревата квадратичная он обязан.
Первый и второй примеры напрямую связаны с характерным когнитивным искажеием у не-инженеров: отсутствием системного видения. Для очень многих не-технических людей система выглядит набором компонентов: Есть кнопки, поля ввода, контрольки, иконки и т.п. При таком взгляде просьба сделать кнопку зеленой, а заголовок заставить менять цвет каждый час выглядят очень невинными, простыми, и искреннее недоумение вызывает сопротивление инженеров. Ну, а инженеры сопротивляются, потому что понимают, что сделать правильно — долго и дорого, а сделать быстренько — значит, написать криво и немедленно залезть в технический долг.
Иными словами, тут нужно обучать обе стороны: инженерам нужно объяснить, что технический долг — это не конец света, и что иногда приходится для нужд бизнеса в него залезать, потому что иначе бизнес загнется, и тут уж никому радостно не будет. А не-инженерам нужно объяснить три вещи: что есть система, элементы в проекте взаимосвязаны, и их желание нарисовать красную рамочку вокруг одной иконки требует на самом деле значительной работы; что существует такая штука, как технический долг; и что залезть в него можно, но потом НЕПРЕМЕННО нужно его погасить.
— Из текста я предполагаю, что основной язык, на котором работает кандидат — Ява. В таком случае от синиора я бы ожидал глубокого знания системы программирования Явы, в частности — понимания того, как работает Garbage Collector. Без этого тяжело предсказывать производительность систем, оптимизировать, бороться с утечками памяти (с их Явским вариантом). (Заявление об интерфейсах меня насторожило, но тут мне, как нанимающему менеджеру, было бы интересно побеседовать с кандидатом на эту тему.)
— Я бы ожидал от синиора понимания принципов хорошего дизайна и следования им, даже если код никто читать не будет. Это относится к использванию инкапсуляции, public properties и т.п., тем более что отказ от них не дает никаких преимуществ.
— По поводу ArrayList и LinkedList, от синиора я бы ожидал немного другого заявления: «Я знаю, в чем разница между ними, и понимаю, когда следует использовать какой, но во всех моих проектах мне хватало ArrayList'a»
По поводу Soft Skills (в вопросе «джуниор или синиор» для меня они гораздо важнее технических).
— По поводу «делать каку». Синиор смотрит не на то, что нужно сделать, а на то, какую задачу нужно решить, и при этом прилагает все усилия к тому, чтобы каки не получилось, ни внутри ни снаружи. Если появилось требование сделать каку, синиор выяснит, откуда оно идет, почему оно возникло, убедится, что все понимают, почему это кака, и постарается придумать и предложить хорошее решение. Если выхода нет, он, конечно, каку сделает, но только когда все остальные варианты невозможны.
— Если синиору есть, что сказать, он не молчит на совещаниях. Если сказать нечего, то он, скорее всего, на этом совещании не нужен.
А к статье я не придираюсь; идея статьи сама по себе хороша, и «very good» можно и нужно заменять адекватными синонимами. Ключевое слово тут — адекватными. И беда в том, что у тех, для кого эта статья предназначена (а это, прошу заметить, не мы с вами), нет возможности оценить контекст, в котором предлагаемые замены будут или не будут работать.
«VULGAR» имеет совсем иной смысл, чем «VERY RUDE». Vulgar — вульгарный, пошлый, безвкусный.
«DULL PERSON», конечно, можно сказать, но звучит странно. Скорее, скажут moron, idiot.
«PERFECT» — больше, чем very good. Perfect — значит, идеально.
«UNIQUE POINT» — может означать разные вещи, очень-очень зависит от контекста. Вполне может прозвучать в качестве иносказания для «Запредельный идиотизм».
«RAVENOUS» — редкое слово, не разговорное. Лучше сказать «starving».
«RAPIDLY» имеет специфический смысловой оттенок. Например, по-русски можно сказать и «Он очень быстро выхватил кинжал» и «Он мгновенно выхватил кинжал». Но вот «Он очень быстро ездит» можно, а «Он мгновенно ездит» — нельзя. В предложении в статье та же проблема.
Я думаю, что увольнять надо одномоментно. Поговорили, попрощались, закрыли всесь доступ, забрали пропуск, проводили из здания. Зарплату можно потом еще платить, но пускать к рабочим материалам уже не стоит.
По поводу теоретических вопросов — большое О и так далее. У программиста должна быть теоретическая база, должно быть представление об алгоритмах, их сложности и т.п. Понятно, что в наше время все можно погуглить и найти — так вот, программист должен понимать, что именно гуглить. Я не считаю, что программист обязан уметь определять сложность алгоритма; но иметь представление о том, что это такое, понимать, что логарифмическая сложность лучше линейной, и чем чревата квадратичная он обязан.
Иными словами, тут нужно обучать обе стороны: инженерам нужно объяснить, что технический долг — это не конец света, и что иногда приходится для нужд бизнеса в него залезать, потому что иначе бизнес загнется, и тут уж никому радостно не будет. А не-инженерам нужно объяснить три вещи: что есть система, элементы в проекте взаимосвязаны, и их желание нарисовать красную рамочку вокруг одной иконки требует на самом деле значительной работы; что существует такая штука, как технический долг; и что залезть в него можно, но потом НЕПРЕМЕННО нужно его погасить.