Комментарии 19
"Собеседование на работу – это разговор двух лжецов"
Абсолютно нормально спрашивать кандидата вопросы, на которые он может приукрасить, умолчать информацию, сказать не всю правду и т.д. Поэтому даже в обычных вопросах про самый сложный проект и как кандидат справляется с возникающими проблемами, есть смысл, потому что ваша задача понять ход мыслей соискателя и реально оценить, что человек придумал для решения. Да, вы всю информацию не проверите, но вам это и не нужно, вам нужно понять подход.
Еще лучше спрашивать про гипотетические ситуации и сценарии у человека, тогда сразу можно оценить его критическое и аналитическое мышление, глубину и ширину шагов для решения ситуации.
А так, интервьювер тот же лгун, который приукрашивает внутренние процессы, увиливает от неудобных вопросов, умалчивает, уходит от ответов. И ничего с этим не поделаешь, с опытом приходить понимание чтения между строк и нужных вопросов для выявления истины. А иногда и этого не хватает и все выявляется во время ИС.
Еще лучше спрашивать про гипотетические ситуации и сценарии у человека, тогда сразу можно оценить его критическое и аналитическое мышление, глубину и ширину шагов для решения ситуации
Я, как практик, не согласен. Если человек красиво говорит, это совсем не значит, что он способен это реализовать. Именно поэтому я и спрашиваю, что человек реально делал, а не что он мечтал делать, и "как бы он обустроил Россию".
А так, интервьювер тот же лгун
Это плохой интервьюер, потому что нет ничего хуже, чем обманутые ожидания. Я честно и тщательно проговариваю все недостатки (главным образом это необходимость читать очень много легаси) и предлагаю человеку взять время подумать, точно ли достоинства достаточно хороши, чтобы в это вписываться. Остается конечно вопрос, действительно ли те, кто отказался от оффера, в итоге ушли бы с испытательного, увидев, что я навешал им лапши, или плюнули бы и решили что и так сойдет) Но пока я все же стою на позициях радикальной честности)
Никто
кроме Яндексане пишет код на листочке и не компилирует его в уме.
Не работали вы в embedded... Там это чуть ли не основной навык. А вот зачем этот навык зачеркнутым - вопрос очень открытый.
В целом все по делу. И да - люди действительно разные нужны. И даже в рамках одной команды нужны. Другое дело, что есть очень серьезный вопрос - как из людей с такими разными базовыми ценностями сделать команду.... Но, по сути, это и есть один из основных навыков тимлида. И это для сведения всем тем, кто считает что сеньор-помидор на определенном этапе автоматически становится хорошим лидом. Увы. Хорошим лидом, как правило, становится совсем не технарь. Впрочем в любом случае вариантов нет - "гуманитарный" лид вынужден подтягивать технику, а "технический" навыки общения и перевода с технического на человеческий и бизнесовый.
Ну да ладно, Остапа понесло... Я, собственно, только по навык написания кода в бумажном блокноте и переводе его на ассемблер целевой архитектуры в голове. Редко, но бывает и этот навык востребован.
Embedded - это программирование микроконтроллеров? Да, я там совсем не работал, не моя тема. Можете даже развернуть, когда и почему навык написания кода на листочке нужен и полезен, думаю всем будет интересно.
Embedded - это несколько шире, чем просто контроллеры. В общем случае, это написание кода, которые непосредственно взаимодействует с аппаратурой. В частности это включает в себя написание кода операционных систем, драйверов под железки. Но встречаются и достаточно большие проекты, целиком написанные без использования операционных систем в том виде, в котором их понимает подавляющее большинство программистов. Ну, и конечно, контроллеры.
В общем случае одним из самых ключевых свойств кода, работающего на этом уровне будет скорость. Коду драйвера или планировщика непозволительно "отбирать" процессорное время у прикладных программ. Идут жаркие битвы по поводу границ этого утверждения, и я, если честно, долго думал стоит ли отвечать. Рискую разжечь очередную ветку священной войны, но... Пусть будет. Единственное, что я обязан обговорить - так это вопросы безопасности. Как той, которая "safety", так и той, которая "security". К сожалению русское "безопасность" не передает нюансов, а синонимы "взломостойкость" и "отказоустойчивость" тоже не вполне применимы. И тем не менее, даже с учетом этих ограничений скорость критически важна. А поскольку код работает непосредственно на аппаратуре, скорость его работы непосредственно зависит от того через какие именно цепи потекут электроны в процессоре и окружающей его периферии. И становится критически важно понимать, как тот или иной код, написанный как правило на том самом "кроссплатформенном ассемблере с элементами структурного синтаксиса" (т.е. языка C, опять же как правило без всяких плюсов) преобразуется в машинные инструкции и каким именно путем они в свою очередь заставят бежать электроны по самому процессору и окружающей его схеме.
У нас очень простой код. Ну правда - у нас нет каких-то предсказаний поведения чего бы то не было, как правило нет серьезной математики с плавающей точкой. Есть только довольно линейные алгоритмы - если произошло событие "a", то делай "бэ". Но делай максимально быстро и не мешая другому коду (не останавливай выполнение соседних потоков без реальной на то необходимости). Ну и адекватно реагируй на асинхронные события. Выдрал пользователь USB-устройство, а у тебя кто-то с ним работает. Изволь сам не упасть, и не задержать остальных впав в бесконечное чтение из отсутствующего устройства, ну и этому самому кому-то работающему нормально завершиться позволь. В первом приближении абсолютно ничего сложного. Ровно до тех пор, пока за реализацию не возьмешься. И еще неизвестно где сложнее - в составе операционной системы, где есть какие-то программные средства IPC и управления временем выполнения или на контроллере, где реально только железки и твой код, пасущий табун электронов.
Да, конечно, код "на листочке" мало кто пишет (разве что в учебных или трепологических целях, вспоминая в очередной раз те самые UB - неопределенное поведение или гораздо чаще избыточно умные оптимизаторы компиляторов), Но тем не менее - навык работы компилятором реально важен. Более того - именно в embedded среде главной проблемой является не UB, а именно излишнее "оптимизаторство" компиляторов. Я руками развернул цикл ради скорости, а излишне умный компилятор увидел и завернул все назад в цикл - практически типовая проблема, особенно если применяется типичная для нашего мира опция -Osize (т.е. оптимизировать под минимизацию размера). Так что мы, наверное, остаемся теми немногими, кто просто регулярно проверяет что именно там наделал с нашим кодом компилятор, и не стоит ли его поправить.
Ставлю плюс текстом, т.к. за комментарии к предыдущей статье срезали карму, поэтому пока так)) Спасибо, отличный подход, уверен у вас отличная команда.
Согласен со всем вышеизложенным с автором, причём это относится не только к ИТ. От себя ещё хотелось бы добавить, что личное собеседование никогда не заменит удаленное: много информации можно считать в жестах, мимике, поведении как при вопросах, так и ответах.
Для себя выбрал путь честно отвечать на все вопросы и стараться не преувеличивать, если видел что то только со стороны то так и скажу, но если надо я готов разобраться. Если были какие то огрехи то и о них могу сказать. Думаю что если человек открыто и искренне общается, то ты будешь знать чего от него ждать, а это пожалуй очень важно.
А все эти стрессовые вопросики, реально могут не отображать уровня. Вот рассказал я как то на собесе про транзакции, а через 15 минут на секции "посмотри что с этим кодом не так" про эти транзакции даже не подумал т.к. в стрессе собеса вообще тяжело такие вещи переваривать.
С интересом бы посмотрела на результаты опроса «рекрутерам на собеседовании приходилось»... Потому что там, по идее, тоже самое, только хуже. Особенно на первом каком-нибудь этапе.
Я вам легко отвечу, так как проходил первые этапы в роли рекрутера - люди разные, но в основном без треша. Из моей практики - один товарищ почти не знал русского, хотя и россиянин (из Дагестана), еще один из Донбасса с ПТСР - матерился через слово, не мог сдержаться. А в основном "я всё знаю и всё умею, возьмите меня работать сеньором, ну и что, что опыта нет, я на месячных курсах всё освоил".
Мне нравиться. Стал еще увереннее в своих силах и мотивации. Много раз читал статьи автора из других источников. Всегда в тему и по делу. Узнал по "тяжелый вздох".
"Никто кроме Яндекса не компилирует код в уме" - коллега Вы заблуждаетесь. Это самый ценный навык, характеризующий способности кандидата понимать чужой код.
Про листочек понятно. Но мы например используем обратный лайф-кодинг. При кандидате открываем IDE пишем код и просим объяснить как работает 10 несчастных строчек, что мы написали.
Очень сильно помогает оценить способности.
А то про dry, kiss, solid не слышал и не знает разве что глухо-бухой. И прочитать из интернета зачем и почему не может разве что косой. А вот уметь рефакторить код под эти вещи и видеть их в коде или их отсутствие - уже редко встречается.
Я имел ввиду несколько иное. Код на листочке плох, потому что сама IDE многое подсказывает, а на собеседовании в Яндекс отказывают на основании того, что не помнишь синтаксис наизусть.
Ваш же метод обратного лайф-кодинга вполне хорош, потому что позволяет оценить не зубрежку, а понимание.
А вот практическое применение принципов dry, kiss, solid - вопрос крайне холиварный, и вряд ли стоит оценивать его в коде при собеседовании. Впрочем, если вам с человеком работать, может и надо синхронизироваться в понимании подобных вещей, чтобы потом не было проблем.
Отличная статья, спасибо. Картинка с базовыми ценностями сверху очень хороша.
Кто ты, воин? Или о правильных собеседованиях