Как стать автором
Обновить

Комментарии 294

Не так давно я был на собеседованиях в нескольких фирмах.
Одна, совсем маленькая, директор сидит в полутемной комнатке, заваленной хламом. Конечно, у них полно иностранных заказчиков, и миллиардные бюджеты, кто бы сомневался. Собеседовал лично директор. Задавал задачи на логику. Одну задачу я решил, вторую не стал. Я пытался завести разговор на технические темы, но очень быстро понял, что он в этом не шарит. Когда я сказал, что работаю только по ТЗ, он сказал, что у них научная фирма и им нужны творческие люди, а не исполнители, работающие по ТЗ.
В другой фирме я написал тестовое задание, сдал экзамен на сертификат, мне HR сказала, что всё очень хорошо, я пришёл, там было два человека, они задавали вопросы, я отвечал в меру своих знаний, потом они сказали, что к ним приходит по несколько человек в день на интервью, и что они мне позвонят. Разумеется, никто не позвонил.
Потом, правда, позвонила HR из этой же компании, предложила работу в другом отделе, где я сейчас и работаю. А про тех ребят, она сказала, что я их испугал.
им нужны творческие люди, а не исполнители, работающие по ТЗ
Плавали, знаем: через месяц начинаются крики «за что я вам зарплату-то плачу, где результат!?!»
Также могу сказать, что при разработке без тз у начальства включается необузданная фантазия, и новые идеи сыплются как из ведра, причём они противоречат как друг другу, так и тому, что уже сделано. ТЗ тоже не 100% гарантия, но хоть какой-то тормоз.
НЛО прилетело и опубликовало эту надпись здесь
К сожалению, это так.
обычная ситуация, поэтому нужно самому собирать все эти противоречивые требования в один документ и спрашивать — что делаем — А или Б?
>А про тех ребят, она сказала, что я их испугал.

Да, слишком умным тоже не надо быть. На… собеседовании. ;-)
Я высказал о нем все что думаю. Я так сделал в первый и последний раз в жизни.

Означает ли это, что вы пожалели об этом? Или вы не так выразились, или я вас не понял.
Значит, что нисколько не пожалел, но больше такого потока задачек не встречал. По остальным был максимум в три. Обычно — две.
Где вы вообще таких находите? С задачками на логику? Да ещё когда их четыре. Да, даже пусть и три-две-одна. А это, кстати, в каком стеке технологий такая ботва? Может разгадка где-то в этой области?
Ну, этобыла вакансия .NET разработчика :)
Бывает. Более того, проблема не столько в задачках, сколько в подходе. Мне на последнем интервью дали 3 задачки на несколько минут каждая, вполне неплохо зашли.
Да ясно, что не в задачах ;). Демонстрация умения решать головоломки не говорит ни о чём, кроме наличия умения решать головоломки.
Давайте для статистики стек технологий озвучте.
> Демонстрация умения решать головоломки не говорит ни о чём,
> кроме наличия умения решать головоломки.

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

Говнокодеров мне в любой момент пачку любое рекрутинговое агентство подкинет.

Вам приходится? Вот именно такого типа, как на собеседовании? Серьёзно? Или, вот, админу постом ниже? Например, про круглые люки? :)
А что вы скажите об умении решать кроссворды?
> Вам приходится?

Я не смог распарсить, к какой части моего комментария относится этот вопрос, простите.

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

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

(а ведь это была _даже_ не головоломка...) Решать головоломки того типа, что вы задаёте на собеседованиях?

>Просто нам с теми людьми, которым неуютно разговаривать на собеседовании про круглые люки — не по пути, вот и все. И лучше всего понять это как можно раньше.

А, то есть вы говноголоволомщиков себе набираете? Ну, это бывает :)
Знаете… это конечно действительно аргумент — выбирать кандидатов «под себя» что называется. Но скажу что проходил собеседования, в которых был аналогичный подход. Но не только с задачками на логику, но и добрыми пачками каверзных вопросов по стеку технологий. А вот пройдя все эти круги «ада», получив работу, увидел примитивный проект, с кучей говнокода и уровень задачь, которые нужно было решать в рамках проекта, были в разы проще и примитивнее самого собеседования и прогону по технологиям.

Итог — собеседуйте пожалуйста адекватно. Не нужно спрашивать криптограффию или предлагать сиюминутно решать задачи на тему коэффициента трения при увеличении скорости объекта, когда на проекте придётся писать только пединги и маргины (я утрирую но надеюсь суть понятна).
Понятно что каждый владелец компании пытается приувеличить как свою значимость, так и значимость компании в целом но будьте адекватнее. Если задаёте задачки на логику и гоняете человека, то хотябы для себя будеть уверены что данному кадидату именно с этим и работать.
Тогда в вакансии надо писать не пафосное «написание кода для супермегабизнес решений» и "+100500 лет на рынке", а «необходим человек для частого решения головоломок». Тогда к вам пойдут именно программисты, которые любят решать и программировать именно головоломки, а остальные — прочтут и пойдут искать дальше.

Сами пишут в требованиях фигню всякую, а потом возмущаются: «ай-ай-ай, какие редиски приходят — головоломки решать не хотят».
По непонятной причине вы решили написать этот комментарий мне, хотя я ни словом не обмолвился о том, что именно мы пишем в вакансиях и нигде не позволил даже заподозрить меня в том, что я чем-то возмущаюсь.

Вы придержите полет своей фантазии в следующий раз.

Ну и да, раз уж зашел: программист, не умеющий и не желающий решать головоломки, называется «говнокодер», и, как я уже сказал, их пачками подгоняют агентства.

Тут вроде когда-то была статья как девушка математик стала программистом. Приходила на собеседование, с легкостью решала головоломки, а через две недели её выгоняли потому что код она писать не могла. (речь шла вроде про Америку)

Там все было не совсем так. Писать код она могла — но она просто не знала современных способов его написания. Плюс все это было наложено на ноду с ее тотальной асинхронностью на колбеках.

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

Да, умение писать код — базовый навык, который никто не отменял. Людей, которые умеют только писать код в последнее время вокруг очень много. Из них нужно выбирать, понимаете?

Любил я решать головоломки в первый год работы, именно когда был «говнокодером». Потом дисциплина, тесты, код чтоб мог читать коллега. А не вот это вот «супермегаалгоритмкоторыйделаеттвсенасвете».
У меня 25 лет стажа, я умею дисциплину, тесты и код для коллеги.

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

Все, сказанное в последнем предложении — умение решать головоломки, на сколько-нибудь сложном проекте.
Выделение из кода абстракций а также грамотное разбиение на модули и разумное применение паттернов — к головоломкам относится чуть более чем никак. Этому учатся через опыт (ну если хотят), а не решая по вечерам головоломки.

Есть люди, которые любят собирать паззлы, а есть, которые не любят — тоже самое с головоломками, которые есть ни что иное, как антипаттерн от HR, которые в большинстве своём в теме разработки ПО совсем не разбираются, но человека «отобрать надо», а значит они дают головоломку и, по их словам, «смотрят как он её решает — само решение не важно». Типичная туфта от человека, который один раз грамотно и удачно её применил и все дружно бросились её повторять, надеясь, что эта фича поможет им отобрать супермегапрограммистов.
Не поможет. А просто покажет выдержанность наблюдаемого — будет ли решать или психуя скажет: «ну вас нафиг и сгрызёт карандаш».
Типичная проверка на адекватность, а раздули невесть что.

Программист, не умеющий и не желающий решать головоломки, называется "программистом не умеющим и не желающим решать головоломки". Ни больше и ни меньше. Он с равным успехом может писать как хороший, так и плохой код, но вы этого с высоты своей осины, ограниченной дремучестью, не узнаете никогда - потому что вы его не наймёте.
Мало того, вы вон в обычной беседе уже дважды контекст теряли: вам на это я сейчас указываю и @avostчуть раньше указывал - в вещах, которые "даже не головоломки" вы потеряли суть. Являетесь ли вы на основании этого плохим "головоломщиком"? Вас наняли по ошибке (ещё не было фаната-головоломщика вроде вас, чтобы НЕ нанять вас)? Или вы являетесь говнокодером? Вообщем тут целый спектр вопросов о вашей компетенции, основанной на банальной невниматьельности.
Вы называете людей, которые не подходят по вашим ограниченным (и ИМХО глупым) критериям - говнокодерами. Хотя они могут писать намного лучший код чем вы - просто не любят решать головоломки.

P.S. Не указывайте что мне делать и я не буду советовать вам направление куда идти. ;)

Не так давно на хабре/гиктаймсе была статья от имени девушки (перевод), где она описывала, как [зачеркнуто]у неё отросла борода[/зачеркнуто] она стала программистом. Что читала, что спрашивали на собеседованиях, как она в этом поднаторела, сколько фирм сменила. И что в некоторых компаниях, куда её брали, было много удивленных лиц — ведь она знала и алгоритмы, и задачки на логику решала, и физбазз влегкую — да только первые несколько лет программировать на целевых платформах она не умела. Совсем.
Я буду обновлять комментарии, честно =\
собеседующему в команде могут быть нужны люди, именно что умеющие решать головоломки

Серьёзно?
Так вы не программиста ищете, а решателя головоломок?
И большинство задач у вас состоит из хитро придуманных ребусов? Или всё-таки из новых фич, которые надо проектировать и легаси-кода, который надо поддерживать и рефакторить?
Что за компания у вас такая, огласите название, пожалуйста. Уверен, тут найдётся много желающих пополнить свой чёрный возможных список работодателей.

Не переживайте, у вас нет никакого шанса с нами пересечься.

И слава всем богам…
Простите, я правильно понимаю, «не знает почему люки круглые» = «говнокодер»?
НЛО прилетело и опубликовало эту надпись здесь
Любой другой формы? Уточню — подразумевается плоский бесконечно тонкий люк.
Под ваше решение подходит как минимум еще одна фигура.
НЛО прилетело и опубликовало эту надпись здесь
Для произвольных двух выпуклых фигур если минимальная ортогональная проекция первой больше диаметра второй — то первая во вторую не провалится, даже если обе фигуры — одни и те же, то круг — не будет единственной фигурой с у которой длина минимальной проекции равна диаметру. Очень практичными могут быть прямоугольные люки с петлей, или, например, створчатые многосегментные люки, если дырка большая, а люк надо открывать руками. Круг можно было бы приплести аргументировав что дырки зачастую круглые по другим причинам, а на круглый люк и крепление для него уходит меньше материала, но у меня сомнения что стоимость материала люков хоть как-либо сопоставима со стоимостью той системы, которую эти люки прикрывают.
Мдя, честно признаю, я о таком даже не задумывался. Почему то мне казалось, что обычного равнобедренного треугольника хватит в качестве не падающей вниз никоим образом крышки люка.
НЛО прилетело и опубликовало эту надпись здесь
потому что так принято. я видел прямоугольные люки и ничего страшного в них не было
>потому что так принято. я видел прямоугольные люки и ничего страшного в них не было

У них была поворотная петля — поэтому то ничего страшного и не происходило.

Имхо.

Эти известные "гуглевые" задачи не предназначены для выявления программиста. Они предназначены для выявления инженера.

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

Месяц назад собеседовался на .Net разработчика, в 4 компаниях.
1. Внешний рекрутер, тест на английский, тест типа IQ, тест на математику, личностный тест общение с лидом (технологии), разговор с лидом и рекрутером.
2. Тестовое задание. Написать простенький сервис, простенький ASP.NET сайт. На все — 4 часа (более чем достаточно). Потом собеседование.
3. Разговор с лидом. Исключительно вопросы о технологиях. Полтора часа.
4. Два собеседования по часу, вопросы личные, технологические, задачки.
головоломки и задачки на сообразительность просто показывают как человек ведет себя, столкнувшись с новой задачкой. просто еще одна метрика для оценки
Если человек откажется выполнять глупое задание, о чём это скажет? Допустим, я собеседуюсь на позицию java junior, передо мной кладут кубик Рубика и просят его собрать. Что покажет мой отказ?
ХЗ. но, например, после одного собеседования агент мне дала обратную связь по поводу решения задачки на сообразительность (я тогда решил, что задача не имеет решения), что-то вроде «рассмотрел не все возможные способы решения задачи»
Допустим, я собеседуюсь на позицию java junior, передо мной кладут кубик Рубика и просят его собрать. Что покажет мой отказ?
Покажет проактивную позицию, т.е. что Вы не тупо кидаетесь выполнять задачу, а сначала думаете зачем и можно ли обойтись вообще без этой задачи. На самом деле, это очень ценное качество.
Хотя на позиции, связанные с Java или с Go, такое вряд ли заценят, там обычно нужны «винтики», тем более на junior-уровне.
Зачем отказываться?
Поддеваете ногтём один из 8 угловых сегментов, выковыриваете его, затем разбираете весь оставшийся кубик. После чего собираете его уже правильно раскрашенным, тем самым показывая свои находчивость и умение нестандартно мыслить.
НЛО прилетело и опубликовало эту надпись здесь
Гуглоиды (у которых самая, наверное, большая статистика) не обнаружили корелляции и отказались от головоломок на собеседовании.
Мне тоже приходилось встречать такое. Однажды судьба занесла в Сбербанк-Технологии, где собеседовали парочка умников, очень гордых тем, что до этого работали в Дойче-банке. После этого я ушел оттуда, лишний раз убедившись, что делать в совковых конторах нечего.
Не стоит переносить личные качества «гордых умников» на всю компанию. Я как-то тоже собеседовался в сбертех, меня не всзяли, но впечатления остались положительные.

Почему?
Культура собеседований компании позволяет допускать этих умников до кандидатов. Вы не считаете это проблемой компании?

Не имею ничего лично против aevolodin, но зная человеческую сущность, за «собеседовали парочка умников, очень гордых тем, что до этого работали в Дойче-банке» может скрываться тот факт, что собеседовали вполне адекватные люди и ушел оттуда получив отказ и затаив обиду.

А если все так и было, то далеко не факт, что культура собеседований компании далеко не обязательно позволяет такое. Просто описанный опыт кореллирует с моим личным и я призываю не обобщать основываясь на одной частности.

Ну тоже верно, да.

И будете неправы. Ни отказа, ни обиды. Только удивление, что на собеседовании на позицию разработчика баз данных задают задачу высчитать процент усушки грибов (!!!). Спасибо, что не тестировали на знание таблицы умножения.

Ну давайте будем объективны, грибы в таких задачах просто для разбавления сухости и упрощения понимания. С таким же успехом вас могли попросить рассчитать абстрактную величину X.

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

Полностью с вами согласен.

Одно другому не мешает, это во-первых.

Во-вторых, нынче любой специфический вопрос гуглится за пять минут, а вот если человек задачи решать не умеет — это не нагуглишь.
А мне как раз там попадался вполне адекватный собеседующий (да вообще, совсем неадекватных с люками пока и не попадалось, в общем-то), разве что зачем-то попросил включить видео в скайпе (но сам всю дорогу смотрел куда-то в компьютер). Идти я туда не собирался и денег они предлагали совсем не столько, чтобы был даже повод задуматься туда идти — так, любопытство удовлетворял.
Согласитесь было бы странно, если из штата в несколько тысяч человек не было бы достаточное количество адекватных. Кстати, мне довелось и самому как то приложить к этому руку — участвовал в экспертном совете по оценке вопросов на собеседование в СБТ и думается мне, что если бы проходившие собеседование люди знали с чем им предстояло столкнуться, если бы не наши поправки, то они были бы очень удивлены. Но это уже отдельная песня.

Я бы на вашем месте бы решил, что не стоит общаться с умниками из Дойче-банка. Это больше подходит под предоставленную вами информацию.
И это абсолютно правильно! По своему опыту двух собеседований в дойче я окрестил этот процесс zadrot-driven recruitment и зарекся с ними общаться.
Да дело даже не в умниках из Дойче-банка, и не в особенностях человеческой сущности, на знание которой так претендует настолько уверенный в себе djonik1562, а в том, что за 20 лет стажа работы в разных компаниях, как и многие мои знакомые, выработал для себя подходящий субъективный набор параметров компании, понимание где было бы комфортно работать. И в коммерческих компаниях мотивированность и отдача от проделанной работы намного выше именно за счет того, что руководство коммерческих организаций проявляет гораздо более высокую заинтересованность в конечной результате, чем в действующих государственных или пост-совковых учреждениях, где обычно избыток менеджеров, совершенно непонятно чем занятого, просиживающего штаны или бегающего с озабоченным видом. Опять же, прошу заметить, что я не претендую на истину в последней инстанции, а выражаю свое сугубо субъективное мнение.
На собеседованиях с разработчиками (программистами) со стороны компании обычно присутствуют тех- или тим-лиды, ведущие разработчики, директора по разработке или ресурсам, может быть и генеральный директор

Все хорошо, но… почти никогда не присутствует ПМ
А ведь при современной постановке разработки — аджайл, скрам, проектные команды, ПМ как главный начальник над командой — именно ваша совместимость с ПМ'ом, начиная от психологической совместимости и заканчивая взглядами на процессы разработки, определяет, насколько плодотворно вы сработаетесь.

Вот у меня было другое — хорошо сошёлся с тимлидом и ведущим девопсом своим типа шефом по задачам на проекте, а с остальной командой — никак. Грустно было

Они любили писать тесты, а вы нет?

А причем тут общение с коллегами по команде, о котором идет речь в статье, и техническими задачами на проекте?

"нельзя чтобы их пришло человек 5, например" — хех, я собеседовался в присутствии примерно 12 человек, причём представляющих все уровни, не только «технических специалистов». Как по мне, это попытка размазать ответственность за принятие (не подходящего) кандидата и воспринимать это надо соответственно.
Есть практика приглашать кандидата на целый день и интервьюировать его с утра до вечера с перерывом на обед. Тогда все эти 5 человек получат возможность побеседовать с кандидатом лично, но по очереди — и каждый для себя сможет составить независимое мнение, и кандидату проще разбираться с каждым в отдельности, четче представляя, какой ответ каждый конкретный товарищ ожидает получить. В случае с 12-ю могли бы их по парам хоть разбить что ли — на 6 интервью. Я уж прям даже не знаю, какова вероятность понравиться всем 12-ти, отвечая на их вопросы одновременно.
Вероятность очень маленькая, точнее ни какая, тем более, что многие понятия не имеют как проводить интервью и нашли какие-то дурацкие вопросы в интернете. Надеюсь, больше ни у кого не будет такого увлекательного experience.

Череда интервью в течении дня с 1-3 собеседующими — это более вероятный вариант.
НЛО прилетело и опубликовало эту надпись здесь
Прям таки исключительно? Интересно, как в это «исключительно» попали люди, сумевшие этих идиотов как идиотов оценить. По сути — проблема в планке, которую задают интервьюеры. Если интервьюеры сами слабы, то и наберут они таких же как сами.
НЛО прилетело и опубликовало эту надпись здесь
Ну так тогда проблема совсем в другом — открытые позиции надо занимать людьми, а вменяемые туда не идут — кто-то ведь все же должен работу делать, вот и приходится брать того, кто идет. И никакой альтернативный подход к интервью проблему не решит.
НЛО прилетело и опубликовало эту надпись здесь
Я не уверен, что понимаю ваш последний вопрос. Вы ведь про конкретный ДЦ говорите? Про то, что платили мало, головастые уходили, оставались те, кто не смог бы так же удачно уйти? Теперь результат — куча заурядностей. Последний вопрос про «Are you ok?» что именно означает? И уж совсем непонятно, какое это отношение имеет к интервью.
Или эти два ДЦ — два разных работодателя (не Амазон и Амазон)? Если это так, то это не очевидно из ваших коментариев. Очевидно, что фильтр в прошлом ДЦ — это зарплата. В новом же ДЦ (Амазоновском, если я правильно понял), проверить знания на интервью не смогли — взяли слабых людей из прошлого ДЦ вместо сильных, ушедших когда-то оттуда. И это говорит либо о низкой планке, либо о том, что проверяли что-то не то. Скорее всего, и то, и другое — поговорили про предыдущий опыт, а задачки дали примитивные. С таким подходом и неделя интервью не поможет.
Это вы сейчас Яндекс описали? Был на собеседовании в 2010, не сошлись по деньгам, в конце 2015 менял работу, решил что второй раз 5-6 собеседований не готов теперь, т.к. идиотизм и не пошел, о чем не жалею. Просто подобного рода подход сильно изматывает, а выхлоп… ну как правило такое в крупных компаниях, где большая текучка и зп примерно в рынке или даже чуть меньше. Собственно, смысл продавать скилл за это?
А почему сразу Яндекс? Ниже я уже упоминал, где такое практикуется. А именно — топовые софтверные гиганты интервьюируют именно так — Гугл, Майкрософт, Фэйсбук, Амазон и прочие. Так же я вроде указал, почему это нужно. Те, кто считают, что это идиотизм, работают в других местах (и может даже об этом не жалеют).
«нельзя чтобы их пришло человек 5, например»
Где-то полгода назад была ситуация, когда собеседовало именно 5 человек. Тех.дир, тимлид, 2 программиста и то ли ПМ, то ли генеральный, уже не помню. Сперва весьма пугало такое численное превосходство, но разговор быстро перешел в приятную беседу. Обговорили и технические моменты, и организационные. Неуютно, но продуктивно.
Не прошёл, но тут сам виноват, ляпнул на паре вопрос лютую дичь.
«нельзя чтобы их пришло человек 5, например»
Бывает так что ваше резюме видели ребята из разных команд и им всем хочется на вас посмотреть… Ничего плохого в это не вижу…
Наверное, можно разбить на несколько раундов — и каждый сможет на вас посмотреть. По человеку на раунд. Так делают многие крупные компании — Майкрософт, Гугл, Фэйсбук, например.
Отличная идея. Сделаем не одно собеседование на 1 час (+ час на добраться + час на вернуться) а 5. А потом скажем «не подходит».
А если серьезно, не всегда возможны раунды. И реально часто лучше собрать человек 5. С другой стороны, я очень сильно сомневаюсь что юниора (мидла) будут 5 человек собеседовать. А сеньёру бояться 5 человек… Ну разве что если он «по стажу» сеньер, а не по сути, тогда да. А так — какая разница, какая аудитория то. Да и чем больше людей, тем интереснее с ними «играть в собеседование.

Тут важно разделять. Либо все эти 5 человек пришли зная зачем — тогда это одно. Либо у каждого из них свой сборник глупых вопросов — тогда это совсем другое.

Небольшая проблемка — для этого надо быть крупной компанией. Так и представляю себе ООО «Бадишоп» с пятью раундами собеседований))
Тут, скорее, лучше предупредить о количестве и спросить, будет ли это комфортно. Если нет, можно поделить на раунды. Но в этом случае придется ездить несколько раз. Вроде как и выбор дан и понятно что будет выбрано. И человек успокоится что выбор был и психологически подготовится
Почему ездить несколько раз? Как долго длится раунд? Если раунды часовые, то в один день вполне себе интервью из 5-6 раундов уложится.
Ну… Тут тоже получается что какая-то мешанина из собеседований. За час что успеешь спросить? Только если какие-то основные вещи… Получается что у конкретных людей мнение не успеет сформироваться и вырисовывается что хорошо когда либо все и разом либо с каждым — но с каждым полноценно. Ну, это конечно, мое мнение
Я глянул https://habrahabr.ru/company/luxoft/blog/152505/ — весь список вопросов можно вложить в час, если не просить писать код на каждый вопрос. Для средненького кандидата можно растянуть на 2 часа. Код, на мой взгляд, достаточно написать на одну задачу — выделить на это минут 30. Из этого кода уже будет много понятно.

К чему я это — за час с человеком можно разносторонне обсудить вполне себе интересную задачу, где будет и дизайн, и архитектура. И интересующие куски можно попросить закодить. И мнение составится. За последние 10 лет я интервьюировал много кандидатов в Майкрософт и Гугл — именно на часовых интервью (где я был одним из 5-6 человек у кандидадата за день). И как-то оно все же работает. Не всегда нанимаются правильные люди и иногда правильные не нанимаются, но в общем случае вполне себе система работает.
Это что ж настолько интересного должны рассказывать интервьюеры, чтобы согласиться их слушать 5-6 часов?
В Амазоне у меня было 8 интервью по часу, и один на один и с тремя
вы себе представляете 5-6 часов интервьюирования?
если кто-то это выдержит — уже нужно брать :-D
упорство и усидчивость — не основные качества, которые я бы хотел видеть в кандидате :) высиживают до конца многие. а так да, представляю — за свою жизнь десятка два таких циклов (из 5-6 интервью) сам прошел. на прошлом месте работы даже при переходе между группами надо было проходить полный цикл интервью.
Но точно можно сказать что кандидат очень заинтересован, а это важно.
Два десятка дневных интервью? Офигеть. Ладно при переходе между группами на работе — там хоть работодатель время оплачивает — отчего бы не поучаствовать в хорошо оплачиваемом шоу. Но вот за свои деньги целый день коту под хвост? И так двадцать раз? Гвозди бы делать из этих людей!
Ну в этих компаниях (амазон, майкрософт, гугл, фэйсбук, линкдин, и т.д.) дневное интервью — это норма. Хочешь в них работать — день придется выделить. Кроме того, при смене работы желательно сходить в несколько мест, получить несколько предложений. Это способствует повышению привлекательности пакета компенсации. В таком случае «коту под хвост» — не совсем верное определение. Да и рука набивается проходить интервью, волнение пропадает после какого-то раза — помогает впоследствии. Можно эти походы рассматривать как инвестицию в будущее.
Был месяц назад в московском Яндексе. Пришел в 12 часов, ушел чуть позже 18, 30 минут обед. Было 1 собеседование с hr и 5 технических собеседований, каждый раз с новым человеком. Если учитывать, что в этот же день я приехал на утреннем Сапсане из Питера (сам дурак, нет бы ночью ехать), то да, тяжеловато, на последних 2 беседах уже поплыл.
Странно, у Яндекса же есть офис в СПб. И при собеседовании именно в этот офис общался с людьми из Мск по скайпу.
Я шел в московские команды (С++ senior developer), мое резюме нашел московский hr, питерские команды она даже и не предлагала, сказала лишь, что в Спб вариантов значительно меньше. Позже я на их сайте уже смотрел по Питеру, нашел только в команду Яндекс-Браузера чтоли.
Меня на последнем собеседовании у них ещё и интервьювер перебивал постоянно и не давал закончить ни одного предложения. Ушёл я от них радостный от того, что всё закончилось. Чтобы приехать к ним к 12, пришлось вставать в 5 утра. Тоже считаю это большой ошибкой, нужно было в Москву с вечера поехать.
у меня крайне положительные впечатления от них остались, несмотря на то, что во время собеседования объявили учебную пожарную тревогу и часть вопросов пришлось обсуждать эвакуируясь из здания, правда на админа собеседовался.
Не всегда даже известно кто будет собеседовать.
Я лично сам пару раз собеседовал, а пару раз мне говорили,
>> там это XX пришёл, если у тебя нет горячих тасков поговори с ним,
Я — Пилю такую фичу, сдавать уже в концу дня
>> Ок.
И идут к следующему столу :D С тем же предложением :D
НЛО прилетело и опубликовало эту надпись здесь
прошел скала интервью, сказали теперь джава.
наплмнил им что я скалист, ответили что заказчик считает что спец. знающий скала лучше чем просто джава разраб, после чего (после первой части по скала которую прошел) сказали что не подойду, неадекватное открытие года))

Недавно здесь читал, что часто Scala в вакансии ставят, чтобы заманить более адекватных разработчиков, которые по сути будут на Java писать. Обидно, наверное, потратить время на интервью и обнаружить такое.

C++ знаете? Отлично! Значит и пол помыть сможете…
Пожалуй, случай, когда я наиболее офигел. Мое резюме одна it компания передала другой. Как так получилось, не знаю. Должность стажер. Связался по скайпу, поначалу вроде более-менее нормально, стандартные вопросы. И вдруг hr заявляет, что я не подхожу для данного места исходя из своего опыта. То есть я учусь, занимаюсь(для меня это перепрофилирование, hr в курсе), и без проверки моих знаний, на гите примеры она не смотрела(это не её задача, по ее же словам), такое заявляет. Кроме того, убеждает меня, что это не подходящее для меня занятие. Мол даже профильные выпускники с их заданием не справляются. Я, конечно, вступаю в полемику по этому крайне тревожному для меня вопросу, стараясь слишком не раздражаться. В итоге вроде убеждаю меня так просто не отсеивать. Через какое-то время приходит письмо с отказом и пример задания. Открываю задание и вижу, что оно для frontend (я же в backend развивался, смотрим резюме).

Выводы: Сказать, что осадочек неприятный остался, значит ничего не сказать. Вели меня, как слепого щенка, не давая полной информации. Ссылок на место\вакансию никаких не было, чисто переписка по почте, так бы сам отказался — ведь не по профилю. Почему я сам не задавал вопросы, ничего не выяснял, приведу следующие аргументы:
1. Просто не ожидал такого предвзятого подхода.
2. Думал раз все расписано в резюме, то hr должен понимать, на что я годен. Есть ведь стек технологий.
3. По сути hr вступила со мной в спор и пыталась доказать, что я идиот. Приходилось сдерживать себя, чтобы не нагрубить. Добившись шаткой положительной позиции, просто хотелось закончить с ней разговаривать.

При отказе можно было бы просто показать требования к стажерам, как причину. Но нет кругом загадки и личный бесконечно богатый опыт.
Много непонятного в работе данного сотрудника. Мое резюме она получила раньше, еще раз там все есть, и вопросы крутились только вокруг него, не затрагивая вопросов по разработке. Зачем назначать собеседование, если заранее собиралась отсеять? Она пришла к выводу отсеять на собеседовании? Так ничего нового я не сказал(резюме). Но даже сбор информации по прошлому непрофильному опыту был неорганизованным. Рекрутер перебивала, скакала с одного периода на другой, чем больше запутывалась. Хотя я хотел начать с самого начала. В итоге все то же самое, но по 20 раз.
НЛО прилетело и опубликовало эту надпись здесь
Как вы это читаете у себя в голове? Я про последнее слово. «Джавау»?
джаву…
Однажды, в позапрошлом веке я пришла на собеседование по Perl. Прошла нормально, на все вопросы ответила. По моему мнению, все было ок. Тимлид вышел на несколько минут, вернулся и сказал, что я им не подхожу, так как они ищут кодера на PHP, а у меня не было опыта.
Ежу понятно, что это был просто формальный предлог от меня отвязаться, но для меня до сих пор загадка, чем я им так не понравилась.
В веке, все-таки, скроее всего, прошлом :D
Формально в этом — дело было в начале 2000-ых :) Просто по ощущениям это было едва ли не при динозаврах.
Однажды пришлось ждать почти час в коридоре возле турникетов перед собеседованием, причем не было где посидеть. Они это объяснили как «наш технический специалист пока занят». Компания довольно крупная, известная во всем мире. Само собеседование прошло не плохо, можно сказать даже отлично. Стоит отметить что на собеседование я приехал с соседнего города.
Меня однажды собеседовали дольше 4 часов. И даже без HR-а, только тимлид. Сначала вопросы, потом задачи. Мелкие, минут по 15-20 каждая, но их было много и после каждой вынос мозга, почему сделал так, а как еще можно и т.п. Скучно ему было что-ли. Первый и единственный раз потратил пол дня на одно единственное собеседование.
забавно читать пост от люксофта про то как надо собеседования проводить)
Наслышан о люксофте немало отрицательных отзывов, но когда сам проходил у них собеседование по скайпу, то и HR и тех. специалист вели себя вполне адекватно и по теме.
На мой взгляд, Люкс очень профессионален в вопросе найма. Тут, конечно же, появляются дополнительные факторы. Например, если сам отдел HR поставлен на рельсы: они и резюме техническое умеют правильно прочитать (хотя не программисты) и поговорят и отпишутся по результатам, то как и везде могут пострадать те шаги, которые к ним не относятся: это разговор с техническими специалистами. Ведь нас, технарей, не обучают искусству найма. Вот и получается что когда доходит до разговора с программистами, эта часть как у всех. Как этого избежать? Тема отдельной дискуссии.

Был случай: собеседовался в «большой немецкий банк». Меня таскали так, что жесть. Спрашивали такие вопросы, которые могут пригодиться только разве что программисту ядра .NET. После чего сказали что старший разработчик .NET — это такая позиция, где надо будет автоматизировать тестирование. Вот зачем меня тогда все это спрашивали?

Вопрос в Люксе скорее в том, что туда прособеседован, наверное, весь город. Ну и много людей, которых отшили. По разным причинам. Бывает, как на экзамене, спрашивают не то, что знаешь. А бывает что не знаешь и все равно — обидно.
Люкс, как раз, на мой взгляд, крайне непрофессионален в плане найма. Несколько лет назад меня пригласили на собеседование и предложили выбрать одну или несколько интересующих меня вакансий. На тот момент я решил что меня больше интересует Java и отмел все предложения по .NET. Сказал об этом HR-у, дополнительно уточнил что интересует именно Java, HR все подтвердил. Приезжаю и… в комнату заходят два спеца и говорят что сейчас меня будут собеседовать на совершенно другую вакансию и по .NET.

Потом еще несколько раз звонили и снова звали на собеседование. Хотя в конце встречи я явно сказал HR-у, чтобы вычеркнули меня из своей базы навсегда.
Сейчас вроде получше. Раньше и не такие казусы случались.
У меня товарищ несколько лет назад туда устроился, так ему через пару недель после выхода на работу из HR позвонили и на новое собеседование в другой проект зызывали (:
Вот-вот. Самое идиотское собеседование, которое я проходил (хотя, по правде сказать, у меня за всю карьеру было всего три собеседования), было как раз в дочке Люксофта. Я пришел туда на позицию embedded software developer с опытом, не для студентов. По телефону было нормальное такое собеседование, задавали вопросы про проекты на прошлой работе, язык C и, собственно, Linux, все прошло хорошо, пригласили на очное.
А вот на очном было что-то странное. Или вопросы по C, но из серии «что будет, если написать так, как нормальный программист на C не напишет никогда». Или же задачки как бы по программированию, но в совершенно нереалистичных условиях, вроде «найти зацикливание в бесконечном списке за бесконечное время с бесконечной памятью», те же головоломки по сути. Справедливости ради, я так офигел от происходящего, что на пару нормальных вопросов тоже не ответил.
Это — нормальная практика на собеседованиях, когда просят решить не стандартную задачу и смотрят какими путями вы это будете делать. Я как раз такие задачки решать люблю. И алгоритм можно придумать и гномиков, смотрящих друг другу в затылок считать не надо.
Ну, я потом выяснил, что многие так делают и открыл для себя целый мир «вопросов для собеседований», но все равно не понимаю, зачем так делать. Мне ближе более деловой подход, когда у компании есть конкретная работа, которую нужно делать, и она проверяет, можешь ли ты ее делать, и насколько хорошо (качество кода, там, best practices). Хотя это больше для продуктовых компаний, наверное.

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

Нет. Память, впрочем нужна только для списка, а время пропорционально его длине, но сам список просто односвязный и добавять в него поля никак нельзя.
Рассказываю решение: берете два указателя, и пускаете их в цикле по списку от головы вперед, один со скоростью два (три, четыре, всё равно) элемента за итерацию, второй — по одному элементу. Если второй указатель «столкнулся» с первым, значит есть зацикливание, если дошел до конца — нет. Ну, в общем, или догадаешься или не догадаешься. Головоломка.
Живо себе представляю программиста, который таким образом решает задачу в реальном проекте. Особенно в embedded.

А при чем тут добавление полей? И где тут бесконечные память и время?


PS односвязные списки широко используются. Особенно в embedded, где нельзя решить задачу просто накидав 100500 библиотек. Сама задача, очевидно, проверяла насколько хорошо вы знаете односвязные списки.

Эм… Ну я знаю что такое односвязный список, и в разных вариантах его реализовывал в девайсах. В работе программисту приходится вставлять/удалять в списки, конкатенировать, сливать, инвертировать. Если уж понадобилось искать зацикливания, то нормальное рабочее решение — добавить флажок «пройдено» к структуре и закрыть на этом вопрос. Или положить, что список не может быть больше N и если мы прошли больше N шагов, значит мы заблудились. Честно, ни разу не видел в коде таких «решений», это правда больше похоже на олимпиадную задачку.
Это типичная задача на знание структур данных с типичным решением (только список конечный, а не бесконечный, иначе в случае отсутствия цикла решение никогда не завершится), ничего общего с головоломками (типа задач про гномиков) не имеющая. Приведенное решение — линейное (от длины списка) по времени и константное по памяти (нужны два указателя, список вам уже дан и в расход памяти на решение не считается). Задачи на списки — одни из самых простых среди задач на структуры данных. И программист вообще в структурах данных должен разбираться.
Покажите мне, пожалуйста, продакшен код, который использует подобные решения. «Бесконечный» — в смысле нельзя сказать «скисок не может быть больше N» (а обычно не может, а в embedded N скорее всего будет еще и достаточно маленьким).
Я вот сейчас задумался — в реальном коде поиска цикла в списке я еще не встречал (что в принципе не означает, что его нет). Поиск циклов в графе встречал неоднократно. Вам бы было проще решать задачу на поиск цикла в графе (раз уж применение такому наверняка существует)?
Без возможности маркировать вершины, как посещенные?
Это не принципиально. Хорошо, когда кандидат может решить задачу (любым способом). Еще лучше, если он это делает эффективно (по времени выполнения, например, или по памяти — и может это объяснить). Еще лучше, если он понимает, что решить можно несколькими способами и выбирает какой-то из них, понимая, что он приобретает и что теряет, в зависимости от условий окружения — их можно уточнить у интервьюера, интервьюеры это любят. Ну, допустим, скажут вам, что структура передается извне и изменять ее нельзя. Легче решать задачу, которая в жизни может встретиться, чем задачу, которая вроде как синтетическая, просто на нахождение алгоритма? Мне кажется, что с точки зрения решения разницы никакой — и тут, и там надо найти способ решения, который человеку, не решавшему эту задачу раньше, не очевиден.
Вы знаете, как ни странно, легче. Только скорее не «которая может встретиться», а которая реально им встречалась или для решения которой (в том числе) меня нанимают. Они как правило более, приземленные, что ли, да и разговор получается более конкретный. Сразу голова в привычный рабочий режим включается (типа коллеги обсуждают проблему), а не в давно заброшенный режим «школьник/студент на соревнонании».
В принципе, я бы даже понял, если бы они захотели проверить, знаю ли я этот алгоритм. Алгоритмический кругозор еще никому не повредил. Но там речь была о том, чтобы я о нем догадался в реальном времени. Embedded developer все же за свою карьеру немного другие навыки.
Больше всего на собеседованиях бесит не обстановка, а то что работодатель не отвечает на прямые вопросы: зп точно сколько я буду получать? Четкий круг задач. Нет? Ну признайтесь что надо быть суперменом. Соблюдаете законы? Как насчет полного северного отпуска и оплаты проезда? Как не слышали?! В смысле 2 месяца слишком много? А то что детей надо вывезти? Ааа, исключение делаете в 3 недели за раз…
Порой ответы на это все получаешь потратив тонну времени на тестовые задания, собеседования и т.п.
Собеседовался как-то в странную, как оказалось на месте, контору, и двое чуваков (видимо разработчиков, они не представились по роду деятельности) просили написать сортировки, убеждая, что с лёту могут мне по 5 вариантов каждый написать, и пару парсеров для деревьев с разными условиями. При этом я жутко тупил и не сделал ни одного задания. А закончилось всё тем, что они хихикали, пересматриваясь. Прийдя домой, я в спокойной обстановке потратил 15 мин, чтобы сделать все задания, которые были на собеседовании. И понял, что они идут в опу со своими сортировками.
Из вашего комментария не понятно, что помешало вам написать сортировки сразу на собеседовании.
Скорее всего отсутствие доступа к Интернету (ведь средний разработчик не пишет сортировки раз в неделю), поэтому не обязан знать точный алгоритм. Разработчик должен знать названия и примерный принцип работы (плюсы и минусы), а конкретная реализация гуглится за 10 минут и реализуется в данном контексте за 15. Поэтому если меня попросят написать алгоритм сортировки на интервью, то напишу им «Array.Sort()» с объяснением, что в данном случае «велосипед» не нужен.
Почему-же. Напишу. (Но ведь «пузырёк» не самый эффективный вид сортировки. Явно же встроенная функция языка будет работать быстрее.) Вот только навык написания сортировки мне не пригодился за 8 лет в разработке и я думаю не пригодится и в будущем (по крайней мере пока я на .Net пишу).

Из похожих примеров: «Реализуйте двусвязанный список». Реализовать-то можно, но зачем?! Тем более если это должно быть сделано на листе бумаги…
Собеседующий проверяет не навык написания сортировок. Собеседующий проверяет навык написания работающего кода. Сортировка — одна из наиболее общеизвестных задач, но при этом достаточно нетривиальная, чтобы по результатам такого задания составить представление и о вашей IT-эрудиции, и о вашем навыке написания нетривиального работающего кода. Двусвязный список — туда же. Ну не генерацию же чисел Фибоначчи просить написать (хотя некоторые не могут и этого!).

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

Такие общеизвестные задачи можно заучить. Сортировка реализуется шаблонно (т.е. либо ты знаешь алгоритм и можешь его написать, либо не знаешь). Поэтому задача показывает не ИТ-эрудицию, а скорее подготовку к интервью.

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

К тому же часто кандидат пишет код упрощённо и может намеренно писать «некрасивый» код, т.к. задача часто ограничена по времени и кандидат считает, что важнее написать что-то рабочее, чем правльно-оформленное. Опять-же задача с оптимизацией существующего кода более наглядна.
В чём разница то? Программист вроде как по определению способен реализовать любой формализованный алгоритм.
zenkz всё-таки более насущные проблемы предлагает… Имхо предложить что-то отрефакторить/оптимизировать гораздо интереснее, чем сортировку писать.
Полагаете, давать на собеседовании отрефакторить код гуманнее, чем попросить реализовать сортировку?
Реализуйте умножение матриц алгоритмом Копперсмита-Винограда, и я соглашусь с первым вашим утверждением. Но на самом деле наивно полагать, что любой человек, называющий себя программистом, может реализовать любой алгоритм любой сложности.
Полагаете, давать на собеседовании отрефакторить код гуманнее, чем попросить реализовать сортировку?
Смотря что за код, само собой это должен быть специально заготовленный небольшой фрагмент изолированной функциональности, покрытый тестами.

Но на самом деле наивно полагать, что любой человек, называющий себя программистом, может реализовать любой алгоритм любой сложности.
Это вопрос времени. Чем сложнее алгоритм, тем больше времени займёт его изложение на языке программирования.
Конечно, вопрос времени. Вот только когда вы платите за это время, вам хочется, чтобы оно было покороче. (Например, время на сортировку должно укладываться в собеседование...)
генерацию чисел фибоначи на собеседованиях тоже спрашивают )

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

То есть все задачи, которые вы решаете, проще написания сортировки? :)
(См. мой ответ выше.)
Написать сортировку — это одно, а написать сортировку «методом пузырька» — это другое. Для второго нужно знать именно этот алгоритм, а для первого — найти/придумать алгоритм и реализовать его.

Так что ваше утвержение можно инвертировать: все задачи обычно намного сложнее сортировки и в них чаще всего требуется придумать новый уникальный алгоритм, а не повторять уже ранее реализованный. (Конечно это не отменяет знаний паттернов и часто-используемых алгоритмов, но сортировка в современной разработке к таким не относится.)
Рискну предположить, что люди вам пытаются донести одну мысль: нефиг мелочью свою ценнейшую «ОЗУ» забивать. Это не несет профита.
Я порой ищу себе различные не фулл-тайм подработки, чтобы мозг не плесневел. По основной специализации — разработчик автоматизированной системы тестирования. Создал весьма сложную систему. Но вот на днях завалил собеседование из-за того, что какую-то мелкую фигню напутал. Т.е. на мой взгляд таким людям, которым до вот таких сортировок охота прикапываться, им важнее, чтобы человек был ходячим гуглом по не важным вещам, чем компетентный «разработчик систем под ключ».
На собеседовании интернет не нужен, пиши сам, покажи как ты умеешь думать, свои решения — это оценят. Но если нет возможности проверить, что делает код, то смысл в этих рукописях? Если, конечно, это не вопросы типа «что выведется в консоль».
Да, забыл упомянуть о том что листику, на котором я писал, не хватало хотя бы консоли.
Как разработчик могу дать несколько советов:

1. Не пытайтесь показать фирму солиднее чем она есть на самом деле. Видел конторы в подвале, у которых были ожидания как у Гугла, а предложить сами они могут немного… (Если у вас небольшая фирма и если вы не можете предложить большую зарплату, то не завышайте планку и старайтесь привлечь нематериальными бонусами: например гибкий график, работа из дома, дружный коллектив, интересные проекты и т.д.)

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

3. Создайте комфортную атмосферу. Улыбайтесь, будьте дружелюбными. Общайтесь на равных. Не относитесь к кандидату как к просителю. Ведь устройство на работу — это обоюдовыгодная сделка. Было бы приятно видеть хотя бы бутылку с водой и стакан.

4. Не увлекайтесь практическими задачами. Они должны быть, но они должны быть решаемыми за 10-15 минут без помощи Интернета. (Т.е. не делайте упор на конкретную реализацию, а лучше на общее понимание и архитектуру).

5. Лучше всего когда в интервью участвуют 2-3 человека со стороны организации: HR, технический специалист (лучше если из команды проекта), и, возможно, ПМ.

6. Не задавайте глупых вопросов. (в дополнение к п.2). Классические примеры «Кем вы видите себя через 5 лет» или «Почему вы выбрали нашу фирму». Большая часть кандидатов ответят то, что вы хотите услышать, а не то, что думают на самом деле…

7. Уютный офис, светлое помещение, удобные кресла и столы, чистота. — Это то, чем запоминается компания. По своему опыту могу сказать, что отказался от работы в компании только из-за того, что не был готов проводить треть своей жизни в тёмном и неубранном помещении, хотя проекты обещали интересные, а зарплату конкурентоспособную. Ведь если фирма не может даже организовать порядок в офисе, то вряд-ли она сможет грамотно планировать, что приведёт к долгим овертаймам и прочим прелестям…

8. Отвечайте сразу и честно. Если после интервью компания пропала больше чем на неделю, значит на ней можно ставить крест. Намного приятнее получить отказ с объяснением причин или же информацию о том, что кандидатура заинтересовала и через неделю будет 2ое интервью, чем сидеть в неопределённости. Цените чужое время!
> «Кем вы видите себя через 5 лет»

Такому интервьюверу можно задать вопрос «Какой вы видите вашу компанию через 5 лет». Правда эффект может быть только если ему задают этот вопрос 1-ый раз.
НЛО прилетело и опубликовало эту надпись здесь
очень раздражают многоэтапные собеседования: сначала выдели вечер на разговор с HR, потом вечер на техническое собеседование с участием рядовых сотрудников, потом еще вечер с сеньорами, потом сделай тестовое и жди неделю ответа. Лично проходил собеседование, которое заняло неделю, включая выходные. Создается впечатление, что людям в компании заняться больше нечем.
Мне сложно говорить об отечественном рынке, но на западном это необходимое зло, потому как уволить человека очень сложно, а приличную зарплату платить тому, кто ничего не делает, а может быть даже еще и вредит слегка — дело накладное.
Да, это точно, после западных собеседований — все российские рекрутеры кажутся чудесными и милыми :))) Все расписанные в статье «ужасы» можно смело умножать раз на 5, в плане тягомотины и волокиты. Ну и конкуренция несравнима (на любую западную вакансию придет 100 резюме со всех стран, от Греции до Бразилии).

PS: Да, работу я в итоге нашел, но повторить все это еще раз… Бррр.
На западе много проще уволить человека, ну не считая некоторых стран. Российский ТК очень гуманный по отношению к работнику. С западными фирмами вопрос в том, что очень дорого нанимать плохого разработчика особенно из-за рубежа — релокация, визовая поддержка, дорогое обучение новичка (очень много часов всех окружающих).
Возможно не везде так, но крупные богатые компании просто так уволить человека не могут. В том же Майкрософте уволить человека (если не по статье, а за перформанс) занимает 6-12 месяцев. Собирается доказательная база, чтобы в случае чего не платить милионных компенсаций, когда он побежит в суд кричать про дискриминацию. Исключение — layoffs, сокращение штата, по-нашему. Но в таких случаях это массовая операция, не индивидуальный случай, как то, что мы рассматриваем. Релокация же и визы — копеечные расходы по сравнению с полугодовой-годовой зарплатой (сегодняшних цифр я не знаю, а 5 лет назад один работник майкрософту в среднем обходился в $250К в год, это не только зарплата — тут и обеспечение рабочим местом, и дополнительные налоги, и куча всего еще).
НЛО прилетело и опубликовало эту надпись здесь
Так задайте. :) Особенно, если хочется. В интервью у вас позиция менее сильная, чем у интервьюера, но, пока ещё, независимая. Вы ведь тоже выбираете соглашаться на предложение или нет.
Во-во, заодно можно справочку из психдиспансера требовать. Поработал я как-то 2 недели в одной конторе, где директор оказался любителем кидаться клавиатурами в сотрудников, которые по его мнению накосячили.
НЛО прилетело и опубликовало эту надпись здесь
А меня как-то занесло в очень крупное рекрутинговое агенство, которые нашли меня на открытую позицию для одного из их клиентов.

Из плюсов: действительно за вас болеют перед работодателем.

Из минусов:
Заколебали распросами про текущее место работы — сколько зп? Сколько вас человек? Где зарегистрирована компания? Какие в вашей компании бонусы? Как долго компания существует?

Ну какое вам дело? В резюме написано. Интересно — погуглите, это ваша работа. Мы же мои навыки должны проверять, а не пытаться выведать все про текущее место.

Когда озвучил ожидаемую сумму ещё потратили 5 минут, уверяя что я просто ОБЯЗАН сказать сколько сейчас получаю, а то чего это я денег прошу столько. И что вообще у них желания нет сотрудничать с таким закрытым человеком(ну да, оно же мне надо, а не вам заказчики за сотрудников платят).

После тз и ещё 4 нетехнический (серьезно, 4 интервью с вопросами «что вам интересно по жизни». И после каждого звонят из агентства с вопросом «ну как, что сказали?») интервью с самой организацией, предложили зп на 20% ниже озвученного пожелания и получили ожидаемое «мне это не очень интересно» — сказали что это же потрясающее предложение!

А есть у кого-нибудь успешный опыт общения с рекрутинговыми агентствами? Может, мне просто не повезло?

Общался с разными рекрутерами.
Одно агенство — просто чекнули меня на адекватность, на язык, дали подобную инфу про целевую компанию и процесс найма. Нашли мне два хороших собеседования. Более того, сориентировали меня по зарплатам в регионе (честно проконсультировали, проверял).
Другое агенство — милая девушка, которая писала какие-то странные вещи про оформление резюме. В итоге позволила себя переубедить и нашла отличное собеседование.

Про текущую зп — спрашивали везде. Всегда есть вежливый ответ: цифра под NDA.
НЛО прилетело и опубликовало эту надпись здесь
Найдется и чуть менее любезный ответ — «я не готов оглашать эти данные».

Но вообще у меня вопрос — значит ли это, что условный бухгалтер может на каждом столбе писать «зарплата у %User такая-то», и ему ничего за это не будет от государства?
Можете пояснить, какой конкретно статье ТК этот пункт противоречит? Я вроде знаю ТК, но не полностью, так что действительно интересно.
Погуглил проблему и сам себе отвечаю — в ТК нет информации об этом.
Есть закон «О коммерческой тайне», который говорит, что система оплаты труда не может являться коммерческой тайной. Т.о., сведения о ЗП являются персональными данными сотрудника — т.е. вы можете распоряжаться ими по своему усмотрению, организация не может накладывать ограничения на эти сведения. Сотрудники же организации, в которой вы работаете (бухгалтерия, например), должны распоряжаться этими сведениями, как и другими персональными данными — включая ответственность за разглашение.
У меня есть. Нашел меня рекрутер из Radley James на LinkedIn, и предложл вакансию в крупной зарубежной компании, в которую я как раз собирался когда-нибудь пойти работать, но собирался уже больше полугода и собраться никак не мог.
Сначала он сам со мной пообщался — подробно объяснил, что за проект, что за роль, какие нужны навыки, выдал кучу информации о компании и стране, в которой нужно будет работать. После этого сказал, что, на его взгляд, я вполне на эту вакансию подхожу и, если я не против, он меня будет туда устраивать.
Перед каждым собеседованием он узнавал, о чем примерно будут вопросы, присылал 10 похожих, узнавал, кто будет собеседовать и давал всякие советы из серии «этому человеку нужно рассказывать максимально подробно, не страшно, если что-то не успеешь или интервью затянется». После каждого собеседования узнавал подробный feedback, рассказывал мне, что конкретно понравилось или не понравилось каждому из собеседующих (скажем, «первый собеседующий неверно понял твой вопрос о том, какие в компании бывают греды — он думал, что ты хочешь повышения сразу после принятия на работу»).
Перед onsite мы подготовили ответы на внушительный список hr-вопросов, и просто вопросов о жизни, подробно обсудили, какие темы стоит затрагивать, рассказывая о себе, а какие — нет. Он сказал мне, какую сумму и как именно нужно назвать при вопросе «сколько денег вы хотите?» и договорился о дополнительном звонке с senior manager уже после onsite для того, чтобы она смогла оценить мою адекватность и предложить больше денег. На тему денег, кстати, я вообще не вел переговоров (все рекрутер), и мне предложили на четверть больше, чем я запросил.
Ну и периодически он меня мотивировал, чтобы не возникло желания забить на процесс из-за кучи бюрократии.
В общем, бывают хорошие рекрутеры.
Агентство скорее всего исследовало рынок, а не искало вам работу. Текущие доходы потенциальным работодателям не называйте — никогда.
Нет, в таком положении вещей я сомневаюсь. Все же это действительно была довольно крупная, международная компания, и к работодателю на вакансию, о которой мы изначально общались, они меня вывели.

Я также не соглашусь с вашей категоричностью. Любую информацию можно использовать. Скорее это зависит от формата разговора. Покер какой-то.
Мне кажется что идеальный ответ в данном случае «Политика моего текущего места работы не позволяет разглашать информацию о заработной плате». И о реальной сумме ни слова, и показывает, что вы знаете и соблюдаете правила игры в компании…

В том году после выпуска равлекался поиском работы и даже текст на эту тему написал => Из физиков в Data Science (Из двигателей науки в офисный планктон), правда тут своя специфика — дело проиходило в Кремниевой долине.


Размер помещения => в быстро развивающихся стартапах часто проблемы с помещениями. Одновременно идут какие-то совещания, встречи и кого-то интервьюируют. Места на всех не хватает, поэтому таки да — часто общение проходит в каких-то закутках. После того как нашел работу и сам начал общаться с кандидатами часто телефонные интервью проводил сидя на полу в коридоре.


Анкетирование => на практике встречалось только пару раз. Google и Uber отсылали анкету на email со списком вопросов, по результатам которого попадаешь или нет на техническое телефонное интервью.


Onsite interview => это стандартно марафон на весь день с обедом по середине. Минимум за день было 5, максимум 12 человек, но парами.


Головоломки => я интервьюировался по Data Science, так что тут может и по-другому чем на программиста, но Facebook, Google, LinkedIn, Uber головоломки не задавали, говорили по делу. Вот use case — что будем делать?


Но в то же время многие стартапы любили задавать задачки на вероятность с обильным использованием Байесовой теоремы — там тоже не так далеко от головоломок.


Зарплата => обычно обсуждается после того, как вы им понравились и тут начинается торг. Но при этом рекрутеры при впервом разговоре часто спрашивают — на сколько вы расчитываете? И если ваш ответ их устроил и продолжилось общение — то что вы хотите, то и получите, опять же если им понравитесь.


Тупорылые вопросы => Вопросы типа "Почему вы хотите работать в нашей компании?" таки задают, причем что стартапы, что конторы побольше вроде LinkedIn. Но в то же время "Кем вы видите себя в нашей компании через пять лет?" не попадалось, но тут народ часто меняет работу, так никто в общем и не ожидает, что вы к ним прикипите.

Когда мои знакомые проходили собеседование с решением логических задачек, после собеседований они не помнили ничего кроме задания на первую задачку. Человек сидит целый час, а потом еще после шока отходит и всё как в тумане.

Да и после прочтения анкет о соискателе создается ложное мнение. По моей практике, когда соискателю до 21 года, то хорошая анкета часто бывает результатом выдернутых кусков из чужих резюме, как потом оказывается, или кого-то попросили написать. Лучше непосредственно напрямую общаться.
Читаю комментарии и удивляюсь: многие интервьюируемые действительно не понимают, на что направлены некоторые «особенности» собеседований. Потому и бесит вас происходящее, что не понимаете. Если бы вы решили третью задачку быстро, вам бы дали четвертую. А потом пятую. Пока не смогли бы. А потом бы они использовали это как аргумент в давлении и торге. И если человек поплывет — значит, можно давить и дальше. Ищут порог прогиба. Это определенный сорт людей, которые не гнушаются такими методами. В принципе, правильно, что ушли. Нефиг НА ТАКИХ работать.
Предположим, у вас есть одна открытая позиция, а на интервью пришли два кандидата — вы обоим дали одинаковую задачу, оба решили. Как вы будете выбирать из них? Вы правы, насчет того, что решил бы четвертую — дали бы пятую. Но далеко не всегда это делается для того, чтобы потом давить на человека в целях дать ему более низкую зарплату. Возможно один из кандидатов решил первую задачу и не смог бы решить вторую. Или третью. А другой смог решить четыре и в общих чертах набросать решение пятой. Теперь уже понятнее, кого брать.
Почувствуйте разницу между «способен решить и эффективно решать на практике, будучи реально заинтересован», «решил задачу» (поставленную мной), «хочет решить» (поставленные мной задачи), «готов решать и дальше» (любые поставленные мною задачи), «готов делать что скажут» (что я скажу), «готов учиться и позволит установить менторские отношения учитель-ученик», «начнет приносить деньги сам в клювике, получая зарплату, ища и выполняя работы самостоятельно», «Просто готов платить „налоги“ — нести деньги хозяину». Бинго. Тут дело в психологии личности. И кстати позвольте заметить, прием на работу вовсе не значит, что в данном специалисте действительно есть потребность в данный момент в актуальных проектах. Сначала подчинение, затем поиск, чем специалиста загрузить. Себе не во вред разумеется. Но для работодателя всегда важен КОНЕЧНЫЙ результат (найти и психологически научить человека, который потом будет нести тебе деньги), а не затыкание мелких дыр в проектах. Может немного путанно, но типо так.
То есть «потому что на девять девчонок по статистике десять ребят»? а вот фиг :) даже если позиций будет тыща, а кандидат один, и он решит, что может ставить любые условия, приходить на собеседование будет все равно он, а не к нему будут приходить за решением задачи. И «хотеть у них работать» будет все равно этот кандидат. Как вы думаете, почему? )) Читаем Кафкинский «Процесс».
Не только для этого. В крупной компании с хорошим руководством человек, скорее всего, будет работать над максимально сложными задачами, с которыми он может справиться, и было бы неплохо на собеседовании определить, как человек размышляет над такими задачами. Если соискателя спросить, чему равно 2+2=4 или как доказать великую теорему Ферма — это не даст какой-то полезной информации. Так что начинают с простых задачек и дают все более и более сложные до тех пор, пока не становится понятно, что соискатель решил задачу с трудом, и именно процесс размышления над последней задачей дает много информации.
Ну, наверное.
НЛО прилетело и опубликовало эту надпись здесь
"Однако, когда я встречаю анкету, мне хочется развернуться и уйти. Это ведь так, анкета, а собеседование-то будет потом! И уйти охота именно поэтому. Потому что понимаешь, что будешь за них заполнять формы для их базы данных, что это — пустая трата времени."

Это одна сторона проблемы. Ведь еще анкеты как сделаны, как будто их не проверяет никто перед созданием. У меня тоже солидное число в области собеседований за 150, и из них всего три раза попадались адекватные анкеты. Дадут листочек, а в нем даже место под ответ не предусмотрено, и вот начинается ужатие текста, мало того что «анкета это так», так еще получается что им и ответы не так важны, потому что вписать туда реальный ответ места не хватает, да и сами вопросы порой это не что. Мне кажется анкетирование должно идти вторым пунктом после собеседования, а не первым.
Есть очень простой вопрос — почему эту анкету не выслать в электронной форме и не попросить заполнить заранее?
Это позволит им скопипастить данные и соискателю было бы удобнее)… Жаль не все гениальные решения есть и у HRов)))
Был и такой опыт.
Но ряд вопросов был слишком, мнэ… Интимен, на уровне «есть ли у вас кредиты? В каких банках? На какие суммы?».
Что любопытно, отказ от заполнения анкеты не вызвал отказ от собеседования и последующего предложения работы.
И правильно делали :) Никогда не отвечал на вопросы, ответы на которые, я считал, что им не стоит знать. Когда после спрашивали «почему не заполнил?», отвечал, что не считаю нужным сообщать им эту информацию.

Больше всего раздражали анкеты, в которых надо заполнять все тоже самое, что есть у меня в резюме. После пары таких анкет, просто разворачивался и уходил.

Сверх наглость была, когда в анкете просили указать свои паспортные данные. Я слал лесом таких. И так делают достаточно крупные компании.
А HR — это отдельный пункт. В начале пути часто приходилось встречать, что HR присылает отклик на ит вакансию в которой он совсем не шарит. В резюме специально было написано, что я начинающий и ничего не знаю и не умею, ищу вакансию или стажировку с обучением или помощником. Я не прошу чтобы кадровик изучал ИТ и знал все тонкости, это не его задача. Но если вы ищите человека с опытом, а в резюме стоит начинающий спросите у самого хотя бы потянет он или нет. Тоже самое касается культуры приглашения. Вроде карты существуют уже давно, можно создать красивое и удобное описание маршрута как к ним добраться, нет они превращают это в задачку, если вам нужен ИТшник, а не курьер или картограф.
НЛО прилетело и опубликовало эту надпись здесь
Все сильно зависит от позиции на которую собеседуют.
Внезапно! Ваш кэп!!!
У меня был случай, что на собеседование приехал за 100 км., а мне на месте предложили компьютер с которого я пообщался по скайпу… Бардак, конечно, но нужно отметить, что общались больше часа и это было одно из самых лучших собеседований из тех, что я проходил.
А как-то раз пообещали супер-мега вопросы от суперспецов. В результате общение по скайпу с примерно 6-тью лбами, и ни одного нормального вопроса. Больше часа потерянного времени. Все вопросы были стандартными и шаблонными. Причем, такое чувство, что на джуниорский вопрос а-ля «что такое полиморфизм» ожидался джуниорский ответ, заученный из учебника, а не объяснения своими словами. То чувство, когда собеседующие смотрят на тебя свысока, но сами при этом никакие. К собеседованиям должен готовится и собеседующий, и у него есть большой козырь, он может повести разговор в сторону любой технологии. А вот собеседуемому вспомнить технологию, которой он занимался пару лет назад может быть сложно. Касательно логических задачек — бррр… Согласен. Читать и заучивать решения из сети это дурной тон. И оценивать кандидата скорее нужно по оригинальности предложенного решения или варианта. Пусть даже и ошибочного. В этом суть.
PS: собеседования в Люксофт у меня были — понравились.
Причем, когда холодно (кондиционер — прямо над головой) — это особенно плохо, т.к. мозг начинает занимать себя мыслями:


О, да. Однажды я так здорово влип. Темно, холодно, чаю не предложили и «напишите три задачи по SQL на бумажке».
Мой антипример с последнего поиска работы: первоначальное собеседование с HR в модном офисе БЦ класса А+, а собеседование с техническими специалистами: «вам нужно идти туда-то, недалеко, минут 15, во дворе трехэтажное здание, вот телефон, как подойдете — позвоните к вам выйдут», это многие другие red flags отпугнули сильно (серая зп, переработки 4 дня в неделю).
1) Собеседовали в Альпина паблишер. Собеседование вёл программист, который почерпул вопросы в гугле. Часть вопросов бессмысленна, на часть сам дал неправильный ответ. И да — когда я шёл по узким душным коридорам офиса, то уже знал, что не хочу тут работать. Надо было сэкономить время и уйти сразу.

2) Собеседовали в сбертехе. Там есть адекватные отделы (с одним из них я сейчас работаю, будучи в другой компании), но эти ребята были фееричны. Собрали человек 8, каждый из которых не знал, о чём со мной говорить. Я пришёл туда со словами, что для меня этот стек новый, я его не умею, но мне было бы очень интересно попробовать (несколько раз писал об этом до собеседования). В результате мне отказали потому, что я не знаю этот стек :)

3) Ещё в одной компании, которая мне очень понравилась, заранее предупредил, что в силу некоторых обстоятельств меня устраивает только белая зарплата. Две недели общались, друг другу понравились… Когда пришёл договариваться, когда выхожу, сказали, что зарплата серая. Спасибо, до свидания.

4) Ещё в одной выдали домашнее задание с объемом работы на неделю. Ребята, вы простите, но вы не конкурентоспособны — у меня нет столько времени чтобы тратить на потенциального и не слишком сильно выдающегося работодателя. К тому же за эту неделю я нашёл более интересное предложение.

5) Ещё в одной компании искали разработчика на Go. Отлично понимая (плюс им в карму), что их крайне мало, искали адекватных людей с опытом в других языках, чтобы перевести. Как тест, выдали солидное задание… Парарам… На Go.

В общем, слава богу, что я отсеялся и отсеял эти компании. В результате нашёл место работы с хорошим доступным офисом, отличным коллективом, высокой белой зарплатой, и я там востребован со всеми потрохами. Главное было не спешить…
Работаю в ИТ-компании руководителем техподдержки. Неоднократно приходилось собеседовать кандидатов вместе с hr'ом в свой отдел. Впечатления крайне негативные.
Во-первых, все вопросы однотипные и «понятные» (например, «насколько собеседований вы сходили», «почему ушли с предыдущего места работы», «как давно ищете работу»). На подобного рода вопросы (если кандидат не идиот) легко ответить. Т.е. кандидат понимает, что от него хотят услышать и может совершенно «верно» ответить на них. И довольный hr, что нашёл «отличного» кандидата кричит: «Бери». Из таких кандидатов больше половину составляют лентяи, безответственные личности, не профессионалы, люди, не умеющие работать в команде. Остальная часть это нормальные кандидаты и полная им противоположность.
Эти «противоположности» — это как раз «тот случай», когда ты пьешь 2 дня успокоительные после такого сногсшибательного собеседования.
Также, заметила, в нашей прекрасной компании не любят указывать размер зп. И, зачастую, уже на втором собеседовании (на котором присутствует руководитель) только всплывает этот факт, и кандидат уходит не довольный.
За свой небольшой стаж работы ходила сама много раз на собеседования, видела множество hr'ор. Единственный человек, который был профессионалом своего дела взял меня на последнее место работы (вскоре после моего прихода, этот человек ушёл). Этот человек умел задавать «правильные» вопросы. После которых складывалась полное понимание, что за человек перед тобой сидит. Остальные — молодые девушки с «яркой внешностью», которые не понятно по каким причинам попали на своё место. Совершенно не знающие и не понимающие того, кого необходимо искать. Не понимающие людей.
1) Вопросы про круглые люки и сортировку шариков по весу. Особенно после технического собеседования. Если они звучат до него, я ещё могу воспринять их как необходимое зло для прохода к техническому собеседованию. Но если со мной уже поговорил технический специалист, и общение со мной продолжается, искать нужный HR'у алгоритм взвешивания шариков я не буду. Если такие вопрос задаёт технический специалист, нам точно не по пути.
2) Тестовые задания умопомрачительных размеров, глядя на ТЗ которых, хочется сразу оговорить стоимость выполнения работы. Тестовые задания, которые просят выполнить на «листочке», отнесу сюда же. Одно дело нацарапать что-то на псевдокоде, показав алгоритм решения, и другое, когда начинают задавать вопросы о пропущенных кавычках, в рукописном тексте программы. К таким у меня только один вопрос, у вас что, перо и чернила вместо IDE?
3) Вопросы личного характера. Я могу понять зачем HR хочет узнать есть у меня жена и дети, но зачем ему знать, как и почему я расстался с бывшей?
Когда я общаюсь с девушкой, я понимаю что я у нее не первый. И даже не второй, скорее всего. Но мне не приятно видеть «следы» бывших рядом с собой.

Согласен )
Стек: С/С++/OpenCV/OpenCL/CUDA. Компания — стартап в техническом зрении. Занятие — разработка и оптимизация софта для мобильных платформ.

4х-часовое (или больше, не помню) собеседование со всеми членами команды, где вопросы варьировались от нахождения суммы сходящегося ряда до написания рабочего кода для тестовой задачи на своём ноутбуке (не выходя из переговорки). Потом переводы научных статей, обсуждение методов оптимизации производительности кода и т. п. Это всё после череды собеседований по скайпу, каждое около часа (с аналитиком, разработчиком, отцами-основателями). Правда народ там вежливый, было интересно.

HR у них не было, т. к. компания маленькая. Претензии традиционные: 1) на одном собеседовании математика с программированием не дружат. 2) написание работающей программы на собеседовании с компиляцией и разбором исходников — это слишком; алгоритм я могу и на бумажке нарисовать, а разбор краевых случаев — это рутина.

На всех собеседованиях очень сильно помогало наличие pet project'ов на github'е. Вопросов по программированию становилось на порядок меньше, собеседующие просто листали исходники.
Судя по описанию — очень грамотное собеседование, как вижу это я. Наиболее приближено к реальным условиям работы.
В реальной работе, например, как раз приходится дружить математику с программированием, а значит — отличный тест кандидата.
Если работаешь с математикой — делаешь, как минимум, важные для проекта вещи. Занимаешься оценкой сложности алгоритмов, построением и минимизацией конечных автоматов и т. п. вещами. Это делается на бумажке (в маткаде / genius'е). Главное — решить задачу, способ вторичен. Это индивидуальная работа с малой по объёму «концентрированной» отдачей. Результаты такой работы трудно оспоримы (например, алгоритм выполняет вычисления за меньшее число шагов — оспаривать здесь нечего).

Если работаешь с кодом — математику только читаешь (если она вообще есть). Работаешь с IDE, отладчиком. Важно не только решить задачу, но и прийти к консенсусу с коллегами (архитектом) по способу решения. Это социальная работа с «разбавленной» отдачей в случае достаточного инженерного потенциала в команде. В данном случае адаптация решения к существующей инфраструктуре зачастую первична. Результаты такой работы можно оспорить (например, на код-ревью).

Ни разу не приходилось смешивать математику с программированием (релизным, продуктовым) в течение короткого времени. Это разные контексты, переключение между которыми отнимает время. Если мы говорим о программировании в терминах составления алгоритмов и их реализации в псевдо-коде — пожалуйста, но в этом случае странно требовать проверки граничных случаев, отладки и т. п.

Ну и по самому собеседованию — после второго часа голова уже не работает. Ни у тебя, ни у проверяющих.
Хе-хе, собеседовался на тестировщика — стоит ли говорить, что разбор краевых случаев занял 80% времени?)
Потому что это одна из основных рабочих обязанностей. Поясню: давайте, например, напишем реализацию вычисления чисел из ряда Фибоначчи без рекурсии за линейное (и быстрее) время.

У нас есть краевые случаи — вычисление 1го члена ряда и инициализация переменных внутри функции. Вас интересует именно это в первую очередь (как тестировщика).

Меня, в первую очередь, интересует сам алгоритм. Потом — для каких наборов входных данных он будет вызываться, есть ли там повторы, какой типичный диапазон, можно ли развернуть цикл, и т. п. Проще говоря, мне более важен proof of concept. Детали добавим потом, если предложенная идея сработает. И только тогда, когда она сработала, откладываем в сторону карандаш с бумагой, и начинаем кропотливо писать тот код, который уйдёт в конечный продукт.

Можно собеседовать кандидата «обходом графа в ширину», а можно — «обходом графа в глубину». В своём первональном посте я высказал ИМХО о том, что «обход графа в ширину» предпочтителен, и аргументировал точку зрения.

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


Вычисление тех же чисел Фибоначчи обычно состоит из краевого случая (он же инициализация) и шага цикла.

Вы читаете по диагонали. Цитирую:
Детали добавим потом, если предложенная идея сработает. И только тогда, когда она сработала, откладываем в сторону карандаш с бумагой, и начинаем кропотливо писать тот код, который уйдёт в конечный продукт.


Очевидно, что проверка краевых случаев входит в написание кода, который уйдёт в конечный продукт. Также очевидно то, что написание и проверка многих краевых случаев зачастую необязательна на этапе подготовки PoC (пишем те 20% кода, которые будут покрывать 80% рабочих сценариев).
Вы случаем не можете указать про какую фирму говорите? А то складывается ощущение, что что-то такое я знаю))

Если на собеседовании со мной будут говорить люди, с которыми мне придется непосредственно работать — то это хорошо. Чем их будет больше — тем лучше, мне тоже очень интересно на них посмотреть. Самое чувствительное для меня — это качество команды, и именно по этому параметру я принимаю окончательное решение. Пусть будет допрос.

1) Один раз тетка-HR из конторы, о которой я никогда не слышал, звонит и с порога говорит «Приезжайте к нам на собеседование, наш директор уже готов с вами побеседеовать». Э? На любые вопросы о вакансии следовал ответ в духе «какая разница, вот же директор уже готов». Для интереса выбил-таки описание вакансии на e-mail, оказалось, что там нужен JavaScript и прочий веб, хотя у меня в резюме DBA/DWH/MS SQL. Что это было?

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

Бесит, когда после нормального в целом интервью, когда на все вопросы вроде ответил (потом проверил по мануалам и выяснил, что таки да, ответил), а HR пропадает на неопределенное время или с концами. Не страшно, что не берут, причины бывают всякие, но сложно написать, что ли, что «увы, вы нам не подходите»?

В целом, могу сказать, что с большинством собеседований мне везло. Либо контора сразу признавалась, что у них официально рабочий день 10 часов, либо — серая зарплата, дополнительного времени на них тратить не приходилось. Там, где доходил до тех. сцециалистов — получал оффер… или прокачивал собственный уровень, найдя пробелы в знаниях :))

Однажды мне выслали тестовое задание в стиле университетских методичек. Самого задания как такового не было, была последовательность шагов:


  1. Откройте Delphi
    2-5. Нажмите сюда, сюда и сюда чтобы создать новый проект
    6-10. Нажмите сюда, сюда и сюда чтобы бросить такой-то компонент на форму

И тому подобное.


Перезвонил, спросил в чем вообще заключается задание и как его делать C#-программисту. Сказали, что перезвонят когда сами уточнят. Не перезвонили :)

НЛО прилетело и опубликовало эту надпись здесь

У java и javascript хотя бы синтаксис похожий (фигурные скобочки, например) :) А ведь еще любят путать 1С и C++...

Так то все ЯП похожи, символы да символы)
Sild >Так то все ЯП похожи, символы да символы)

Отличаются всё же. У одних скобочки фигуристые, а у других отступы в коде. ;-)

@ mayorovp >У java и javascript хотя бы синтаксис похожий

И первые четыре буквы совпадают. ;-)
Позвала меня как-то на собеседование одна неведомая компания. Странности начались сразу. В hh было написано 5 мин от метро, при звонке они назвали точный адрес. Я вбила его в яндекс, метро на карте нет, уменьшила масштаб, еще, еще. И вот оно, метро! Сервис предложил мне ехать 15 мин на трамвае… Как они добираются за 5 мин — загадка.
Прихожу я туда, офис — 2 комнатки заваленные хламом. Усадили меня на стул в середине одной из них, почти как на утреннике в детском саду. Все 6 сотрудников фирмы: директор, сисадмин, тим лид и 3 разработчика сползлись на «собеседование», а еще, учитывая мой пол, это точно был цирк с неведомой зверушкой, девушкой-разработчиком. Дали задрипанную бумажку с куском кода и сказали найти 3 ошибки.
Я начала перечислять. Они:
— не, это ж тестовый пример, зачем тут соблюдать MVC (а то, что у меня кровь из глаз потекла от этого — ладно)
— не, представим что база подключается в другом файле (а где тогда подключение этого файла)
— не, подумаешь стили инлайном, что тут такого
— ээээ, ну может да, но мы не эту ошибку имели в виду.
Короче я нашла ошибок 10, и заданные ими 3 тоже))
Потом посыпались дополнительные вопросы, от всех, одновременно. Я даже остановила их и сказала, что не могу понять вопросы, произнесенные одновременно, давайте по очереди.
Вышла я оттуда с точным решением, что я туда не вернусь. А они позвонили и сказали, что я им подхожу. Так первый раз в жизни я отказала работодателю, а не он мне.
Кровь из глаз — ладно. У некоторых мозги из ушей вытекают, они видимо привыкли к этому...))
Мое последнее трудоустройство прошло слишком быстро. С понедельника по четверг обошел 4 компании, пригласили в 3. Одна из контор сделала 2 попытки переманить к себе предложив больше з.п. чем у конкурента. Я не согласился по двум причинам, хороший коллектив, удобно добираться.
На одном из собеседований, в конце, мне предложили решить задачу — поменять местами 2 переменные не создавая при этом третью. Я сразу ответил, что я сейчас не в состоянии решать задачи, т.к. мозг уже на грани кипения)) Мне ответили, что никуда не торопятся и могут меня подождать. Решил за 2 минуты, хотя на 100% думал что не решу.
>> Я сразу ответил, что я сейчас не в состоянии решать задачи, т.к. мозг уже на грани кипения)) Мне ответили, что никуда не торопятся и могут меня подождать. Решил за 2 минуты, хотя на 100% думал что не решу.

Вместо
            int a = 1;
            int b = 2;
            int buf = a;
            a = b;
            b = buf;
нужно написать
            int a = 1;
            int b = 2;
            a = a + b;
            b = a - b;
            a = a - b;
или
            int a = 1;
            int b = 2;
            a = a + b - (b = a);
?

Мне одному кажется, что в случае, когда мы используем не явно объявленный буфер, а вариант со сложением вычитанием, в памяти создается аж 3 (три) временных переменных (результатов сложения и вычитания), которые потом записываются в переменные, которые нами объявлены явно.

Кроме того, сейчас навскидку не скажу, но надо посмотреть, будет ли работать вариант со сложением/вычитанием, если при операциях ± будет возникать переполнение.
Если вариант рабочий, то операции нужно явно обрамить тегом unchecked, если нерабочий, то и говоргить не о чем.

Кроме того, в варианте буфера, мы имеем три присваивания,
а в случае сложения/вычитания (даже если не считать создание промежуточных буферов) — три присваивания и три операции ±, т.е., второй вариант получается менее производительный, медленнее в 2 раза или более.

Разработчика нужно проверять, понимает ли он, как математика «ложится» на устройство компьютера, а не проверять на саму математику.
Разработчики должны создавать читабельный, производительный и масштабируемый код, а не наоборот.
я думаю, они хотели увидеть xor-ы. но если человек раньше этого не делал и об этом нигде не читал, вероятность услышать такой ответ достаточно низкая.

a = a ^ b; // в а у нас теперь xor изначальных а и b
b = a ^ b; // в б теперь а (полученная из a xor b xor b), а в a все еще xor изначальных а и b
a = a ^ b; // в а теперь b

или

a ^= b ^= a ^= b;

последнюю запись мне как-то на интервью в майкрософт написали на доске и спросили, что это. я ответил секунд через 30, что это обмен двух переменных значениями, но я такой способ давно в детстве встречал на какой-то олимиаде. на мой взгляд, это плохая задача для интервью (вне зависимости от ожидаемого решения — что через сложение и обход переполнения буфера, что через xor-ы).
что через сложение и обход переполнения буфера, что через xor-ы

Через xor-ы не будет переполнения буфера, в "худшем" случае результатом xor будет INT_MAX. Но в целом согласен, что для собеседования эта задача подходит только если позиция связана с системным программированием или с микроконтроллерами.

А где я сказал, что через xor-ы будет переполнение? xor-ы как раз идеальное решение в данном случае.

упс, неправильно интерпретировал Вашу формулировку..

Спасибо. Признаюсь, вариант с XOR (ну а с вашими комментариями он становится вообще очевиден) я нашел в гугле перед тем, как ответить на комментарий, но специально написал именно про сложение/вычитание, т.к. знаю о реальном примере, когда на собеседовании в крупной компании ожидали услышать именно вариант со сложением.
Хотите еще одну задачу на XOR-ы? Дан массив целых чисел, о котором известно, что все его элементы встречаются в массиве дважды, кроме одного. Найти этот элемент. Оптимальным решением (линейным по времени и константным по памяти) будет просто проксорить весь массив. Результатом будет искомый элемент, потому что все пары взаимно униичтожатся при xor-е числа на само себя. К этой задаче есть еще усложнение — непарных элементов два, а не один. Найти эти элементы. Но и эту задачу я бы не стал на интервью задавать.
Разработчика нужно проверять, понимает ли он, как математика «ложится» на устройство компьютера, а не проверять на саму математику.

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


b = a ^ b
a = a ^ b
b = a ^ b

А вариант со сложением приведёт к переполнению, это Вы правильно догадались.


Мне одному кажется, что в случае, когда мы используем не явно объявленный буфер, а вариант со сложением вычитанием, в памяти создается аж 3 (три) временных переменных (результатов сложения и вычитания), которые потом записываются в переменные, которые нами объявлены явно.

Вам кажется. Если не лень написать на C и дизаcсемблировать результат, то можете убедиться, что одни и те же регистры процессора будут использоваться вместо a и b.

Спасибо. Насчет xor'ов и ± ответил выше другому комментатору.

А насчет «Если не лень написать на C и дизаcсемблировать результат» — есть ли такая же уверенность, что такой же результат будет для C#, Java, и тем более различных вебовских языков?

Совершенно не факт, что в случае других языков будут такие же оптимизации, особенно, если переменные будут 64, а не 32 бит.

Все это я к чему. Про эту задачу я слышу не первый раз, и она мне кажется очень некорректной.
есть ли такая же уверенность, что такой же результат будет для C#, Java, и тем более различных вебовских языков?

Ну, у виртуальных машин свои регистры или стек. Но в целом результат должен быть аналогичен. А то Вы описали настолько неоптимальную реализацию компилятора, что сложно поверить, что такое вообще возможно.
Вот для примера результат варианта с ± на C#:


    .maxstack 3
    .locals init (
        int32   V_0,
        int32   V_1)
    IL_0000:  ldc.i4 567
    IL_0005:  stloc.0
    IL_0006:  ldc.i4 789
    IL_000b:  stloc.1
    IL_000c:  ldloc.0
    IL_000d:  ldloc.1
    IL_000e:  add
    IL_000f:  stloc.0
    IL_0010:  ldloc.0
    IL_0011:  ldloc.1
    IL_0012:  sub
    IL_0013:  stloc.1
    IL_0014:  ldloc.0
    IL_0015:  ldloc.1
    IL_0016:  sub
    IL_0017:  stloc.0

Как видите, на уровне виртуальной машины остаётся только 2 переменных, она сама определяет, что числа влезут в int32, ну и работает со стеком вместо регистров eax, ebx, но это неизбежно для стековой виртуальной машины.


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

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


P.S. Кстати, раз уж вспомнили о языковом разнообразии, то в некоторых языках легко поменять местами переменные любого типа, примерно так:


a, b = b, a
Ок, я накидал вопросов, вы ответили.

Тем не менее, почему я считаю эту задачу некорректной, или, в ваших терминах, неуместной.
В самой задаче не обозначена цель, которой хотим достичь, избавившись от буфера:

— поменять местами значения переменных? наиболее читабельно это в случае варианта с буфером

— мы хотим сделать программу более производительной?
не получается, даже с учетом всех оптимизаций компилятора или виртуальной машины
в лучшем случае сохраним ту же производительность

— к слову о производительности — в задаче не указано, должны ли мы учитывать особенности компилятора/вирт машины, или нужно с помощью любого языка программирования или псевдокода показать знание математики?
если последнее, то в справочнике по любому языку будет сказано, что оператор "+" возвращает значение, и не более, ничего про оптимизации там не будет
(и, кстати, о каких переменных речь? — только целых 32/64 бит, или еще вещественных? — с последними сложение и xor не пройдут, не говоря о других типах)
да и вариант «a, b = b, a», если он есть в языке, очевидно, наиболее оптимальнее любого велосипеда

— узнать, владеет ли человек двоичной арифметикой? из задания неясно, что требуется именно это

— показать ход рассуждений, который имеет место в нашем с вами диалоге?
кажется, оверхед для такой короткой в своей постановке задачи

Словом, почему задаче кажется мне некорреткной — неясно, что именно мы хотим достичь, реализуя отличный от буфера вариант обмена значений (найти более лучшйи способ?),
и тем более, неясно что именно хотят понять о кандидате, задавая эту задачу.
Получается, единственный корректный вариант постановки задачи:

1. Имеем устройство с очень ограниченным объемом памяти.
2. Пишем для него на Asm или Pure C
3. Как поменять местами значения переменных, не создавая переменную-буфер, и не зависеть от переполнения буфера?

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

На этот вопрос у меня уже нет ответа… Имхо, тестовые задачки должны быть приближены к реальным задачам, которые должен решать соискатель после трудоустройства.
Т.е. если я хочу узнать знает ли претендент про xor, логичнее будет спросить про битовые маски (относительно часто применяются на практике).

> тестовые задачки должны быть приближены к реальным задачам,
> которые должен решать соискатель после трудоустройства

У меня вот вопрос родился: если мы разговариваем про собеседование чувака, который будет по грамотному ТЗ фигачить имплементацию, то зачем вообще собеседование? Я лично в таком случае просто найду аутсорсера, у которого есть гитхаб, на который я и стану смотреть. Как такой человек выглядит, что ест на завтрак, и умеет ли решать логические задачи — до фонаря совершенно же.

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

Так вот, вопрос: вы когда говорите про «тестовые задачки должны быть приближены к реальным задачам» отдаете себе отчет в том, что реальные задачи типа «форма с тремя полями» уже давно перестали быть задачами. Их решит миллиард человек на Земле, дешевле и быстрее члена команды. Реальные задачи как раз не имеют четких формулировок, зачастую даже входных условий, и больше всего похожи на «пойди туда не знаю куда, принеси то, не знаю что». И ценность члена команды — именно умение выкристаллизовать из этого формулировку, а не умение потом все запрограммировать. С последним, повторюсь, прекрасно справляются люди, которых я даже по имени не знаю.

отдаете себе отчет в том, что реальные задачи типа «форма с тремя полями» уже давно перестали быть задачами

Вы утрируете. Всегда можно взять что-то нетривиальное из прошлых задач по проекту.


Реальные задачи как раз не имеют четких формулировок, зачастую даже входных условий, и больше всего похожи на «пойди туда не знаю куда, принеси то, не знаю что»

Это Вы уже задачи тимлида или архитектора описываете. Для программистов почти никогда не стоит вопрос "что надо сделать?" (архитектура), максимум остаётся вопрос "как это сделать?" (детали реализации)

> Для программистов почти никогда не стоит вопрос «что надо сделать?» (архитектура),
> максимум остаётся вопрос «как это сделать?» (детали реализации)

Это одно из самых распространенных крайне опасных заблуждений. Тимлид не может расписать архитектуру до самых незначительных деталей реализации, потому что для хорошего тимлида отсюда до готового кода примерно 10 минут, или сколько там у вас выполняются тесты.

Команда для того и нужна, чтобы можно было не заниматься архитектурой на самых низких уровнях. И вот тут-то я ожидаю от девелопера, что он не наводнит код бесконечными ифами. А то, что расписано до уровня «осталось только придумать „как это сделать“» можно, повторяю, совершенно спокойно чатботам на аутсорс отдать за три копейки. В наше время это уже нельязя назвать работой програмиста. Это работа копипастера, машинистки со знанием пары дополнительных языков, типа COBOL и javascript, ну или на чем вы пишете.

Тимлид не может расписать архитектуру до самых незначительных деталей реализации

Именно поэтому я их (архитектуру и детали реализации) и разнёс по разным пунктам )))
Или Вы xor vs temp var тоже в архитектуру записали?

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

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

И, да, еще насчет xor'ов. Это вообще очень незаслуженно неиспользуемая многими программистами (знаю из опыта) операция, как при работе с числами, так и с логическими выражениями.
Ага, и вот именно это и есть ответ на вопрос «зачем, например, я люблю спрашивать про `a, b = b, a`». Это же первый (ну хорошо, второй) пример, на который наталкивается человек, разбирающийся с вопросом «а зачем нужен `xor`».

И если кандидат `xor` любит и умеет, он этот пример знает в лицо. А если он привык рожать локальную переменную на каждый вздох — то пусть еще пойдет подучится.

А дальше — ну вот есть два взаимоисключающих флага, которые надо проверить — и ведь каждый раз глаза вытекают от монструозного `if` с 55-ю ветками.
On modern CPU architectures, the XOR technique can be slower than using a temporary variable to do swapping. One reason is that modern CPUs strive to execute instructions in parallel via instruction pipelines.

Вот поэтому в начале дискуссии и я писал, что непонятно, что именно требуется в этой задаче.
Наиболее оптимальное решение (и масштабируемый/переносимый код) для 99,99% устройств — это заведение переменной-буфера.

А тогда совсем неясно, что требуется, когда такую задачу задают — продемонстрировать эрудицию, ход рассуждений, знание умножение/деления, сложения/вычитания, двоичной алгебры, или чего еще.

На мой взгляд, эти недостатком обладает львиная доля задачек на логику и сообразительность.
Самое главное в таких случаях — совпасть в предположении цели и в допущениях условий с задавшим задачку, а найти решение уже дело техники.
А дальше — ну вот есть два взаимоисключающих флага, которые надо проверить — и ведь каждый раз глаза вытекают от монструозного `if` с 55-ю ветками.
Насчет этого могу только согласиться, пусть не 55 ифов, даже условия вида
a && !b || !a && b
— уже достаточно для вытекания глаз, особенно, если вместо a и b осмысленные длинные имена переменных или функций.

А вот насчет xor как первого-второго примера его изучение никак не согласен.
В прикладном коде использование xor для обмена значениями этот супер-преждевременная/избыточная/etc оптимизация.

Пример имеет смысл при разработке для устройств с условными 640КБ памяти.
Можно его еще изучить в рамках изучения собственно двоичной алгебры, и вполне себе позабыть.

Даже в прикладном коде полно реальных примеров, когда нужен xor для чисел и логики.

Хотя… Логику вашу понимаю, и если намекнуть собеседнику, что именно вы хотите проверить, то вполне. (Чтобы не принять задачу за очередную логическую задачку с неявно определенными допустимыми операциями, и не гадать, чего же от тебя хотят)
А я нигде не говорил, что оно будет _быстрее_. Оно будет изящнее. А это в 99% случаев важнее.

Этот пример невозможно забыть, если любишь изящный код. Локальные переменные, помимо прочего, досталяют проблемы некоторым GC в некоторых языках (у меня есть примеры, но тут «поля недостаточно широки, чтобы привести их», как по другому поводу писал один математик).

Понимаете, в современном мире «наизусть» девальвировано полностью. 30 лет назад имело смысл спрашивать про код как таковой — сегодня все гуглится быстрее, чем пишется. Поэтому я спрашиваю про паттерны.

> очередную логическую задачку с неявно определенными
> допустимыми операциями, и не гадать, чего же от тебя хотят

В реальном мире все задачи такие. Я ожидаю как раз вдумчивых дополнительных вопросов, уточнения формулировок, совместного доведения задачи до хорошо поставленной. Нафигачить по идеальному ТЗ тыщу строк кода может и обезьяна, и генератор кода, и чатбот.
А вам не кажется, что с точки зрения ассемблера куда более логичным решением будет что-то вроде этого?
mov eax, a
mov edx, b
mov a, edx
mov b, eax

У нас самая долгая операция — это пересылка из памяти в регистр и обратно, и тут их используется минимальное количество (4). Вариант с xor, если не оптимизировать, займет целых 9 пересылок

Формально да, но по факту то вся оставшаяся часть функции работала бы с eax и edx. Т.е. я подразумевал такой вариант:


mov eax, a
mov ebx, b
xor eax, ebx
xor ebx, eax
xor eax, ebx
; work with eax and ebx

P.S. Про 9 пересылок вообще не понял, что Вы имели в виду...

Хотя по-большому счёту в ассемблере в большинстве случаев можно было бы просто работать с eax как с b, а c ebx как с a без всяких xor'ов.

Если уж рассматривать инструкции ассемблера, то можно и xchg использовать. Переслать значение из ячейки памяти в регистр, обменять регистр со второй ячейкой, переслать из регистра в первую ячейку. Инструкций меньше получится. Хотя по производительности все равно XOR-у проиграет (из-за LOCK-ов, накладываемых xchg).
Это еще один вариант ответа, который показывает некорректность изначальной постановки задачи.
Если в задаче говорится «не создавая буфера» — а можно ли использовать имеющиеся буферы (eax, edx)?

Таким образом, вывод все тот же — с точки зрения производительности и экономии памяти/числа операций, задача имеет смысл, только если мы программируем на C/Asm для микроконтроллера,
а для всего остального оптимальным по совокупности причин будет именно заведение буфера (а также можно продемонстрировать и прокомментировать все возможные варианты).

Но что ожидается, когда эта или подобная задача задается кандидату, неясно.
> Прихожу я туда, офис — 2 комнатки заваленные хламом.

Офис они поменяют. ;-)
Где я работаю уже 5-й офис за годы сменился. Начинали арендой пары комнат на заводе — тьма и ужас!!!

>Потом посыпались дополнительные вопросы

Меня в первом вопросе спросили — что такое «файнели»? — и я завис.

И когда меня стали подводить к правильному ответу, я понял, что спрашивают меня о «финале» ( так я про себя читал в книге слово «finally» ). :-0

Вывод — озвучивайте НОВЫЕ иностранные термины хоть как-то, а не только читайте глазами в книгах. :-)

Но, ничего — приняли. :-)

По моему опыту оценки компаний, куда я ходил на собеседования:


  • организационный уровень компании. Eго видно по тем же деталям вроде стопки бумаги и карандашей в переговорке, обязательности HR и т.п. Чем больше компания, тем важнее этот параметр.
  • ресурсы, которая компания тратит на HR. К примеру, марафонные собеседования в данном случае плюс — на вас тратят целый день ценного специалиста!
  • технический уровень компании. Не нужно стесняться пособеседовать интервьювера — об используемых технологиях, о процессах разработки, тестирования и continious delivery (имхо, самое важное), о сложных задачах.
  • отношение компании к персоналу. Внешний вид рабочих мест, кухни, качество воздуха...

А вообще смотрите на помещение — вам в нем сидеть. И на людей — вам с ними работать.

Я заглядываю в туалет, если он мне не нравится — скорее всего, и компания не понравится.
С каких пор на хабре разрешены комментарии read-only юзерам?
Их необходимо одобрять автрам постов

Так все это знакомо. Сразу чувствуешь, что человек пишет о своем, о наболевшем.

У меня вот остались замечательные впечатления от общения с KELLY агенством.
Все было очень четко оговорено и прошло в итоге замечательно.

Были сложности:
Я был первый день в городе в котором собеседоваля. С самолета, не выспавшийся, в не очень презентабельном виде и с сумкой вещей. HR была в курсе ситуации и этот момент сразу был понят и забыт.

Четкие советы о том, как лучше идти в компанию и что они вообще хотят и прочее.
Удобное место, вежливый персонал в самом HR агенстве.

Само собеседование в компании тоже прошло отлично, но тогда у меня были странные ожидания «по жизни» и сам себе слил вакансию.

После этого когда искал работу не стеснялся звонить по разным вопросам трудоустройства и компаниях.Отвечали, консультировали. Впечатления — супер.

p.s Собеседовался на BI-разработчика в зарубежную компанию

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

Всякое бывает. В итоге меня опять же нашел HR, правда именно самой компании, а не агенства и вот я до сих пор работаю в ней, все отлично и с коллективом сошелся.

В общем ищите и найдете :)
один раз сталкивался с Kelly — впечатления только положительные, очень адекватные рекрутеры
Нужно быть уверенным в своих силах и относиться к собеседующим как к равным, тогда не будет половины переживаний из статьи. Холодно под кондеем? Попросите выключить. В этом же нет ничего сложного. Не нравятся задачи на логику — скажите об этом.
Главное понять что собеседование это не допрос и тот кто тебя собеседует такой же разработчик как и ты.
Ну и плюс к выше сказанному, помните, что интервьюируют не только они вас, но и вы их. И у них тоже есть возможность это интервью провалить.
Был на собеседовании в одной всем известной крупной компании, на встречу пришли два разработчика. Один из вопросов был по практической реализации, когда я предложил вариант решения один сказал что так не получится, второй ему возразил и сказал что это возможно, тот очень удивился и сказал щас я загуглю. Собственно половину моих ответов он сидел и гуглил
Последняя успешная серия собеседований (у текущего работодателя) была очень своеобразной.
Все собеседования были по скайпу на позицию системного инженера (вакансия была с релокацией)

1 тур, HR. Девушка с удовольствием рассказала о компании, о сотрудниках, структуре, кто чем занимается и в целом «за жизнь». Я немного рассказал о себе и задал организационные вопросы про переезд и т.п.
2 тур, менеджер. На старте рассказал уже отработанную часть «о себе, что знаю, что умею», и я оставшиеся минут 50 задавал вопросы по текущей инфраструктуре, процессах, данных и так далее.
3 тур, специалист и будущий коллега. Опять же, почти всё время именно я задавал вопросы что уже есть и что они хотят в будущем и в каком виде :) тоже продуктивно пообщались; задача этого специалиста была в основном рассказать об инфраструктуре, вопросов он почти не задавал.

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

В результате — меня выбрали в основном по вопросам, которые я задавал, а не по ответам (их почти не было)
>В результате — меня выбрали в основном по вопросам, которые я задавал, а не по ответам (их почти не было)

Тут главное НЕ перестараться с вопросами — чтобы СЛИШКОМ за умного не сойти. Для их фирмы.

А так да — иногда попадаешь на «спрашивающего» тебя, который с большим интересом отвечает на твои вопросы. ;-)

Но если окажется, что у них всё устарело лет так на 5, да хоть на 2 от трендов и они понимают, что ты продвинутый — то всё зависит от того — наймут ли тебя для поддержки их легаси кода или для его обновления до современного состояния. Имхо.

Тоже, что ли, поделиться… за последние полгода посетил несколько десятков компаний в Москве…
(для уточнение — стэк .net, опыта 15 лет, позиция не ниже ведущего разработчика)

Раздражающие факторы в организации собеседований:
— неполная инструкция к тому, как же найти офис/кабинет/человека. Например: офис в большом бизнес-центре, три здания, ни слова о том, в какое соваться, или нужный вход только с другой улицы да из подворотни.
— отсутствие готовности места/собеседующих. Было и так, что 15 минут ищем, куда бы присесть, потом ещё полчаса собираем тех, кто же хотел меня лицезреть. И это при том, что заранее было оговорено, что времени у меня — час на всё про всё.
— и да, нелепые рукописные анкеты, которые сильно проще было бы заранее заполнить на компьютере.

Печальные факторы:
— нелепые тесты из задачника «как никогда не надо писать код», типа что выведет этот код. Очень хочется сказать «если я такой код увижу в своём проекте, выкину его нафиг», и да, часто так и говорю.
— туда же алгоритмические задачки из разряда «есть решение у гугле на первой странице» и совершенно точно не нужные в реальной работе.
— вопросы из серии «самые редковстречаемые особенности» языка/технологи. Судя по тону спрашивающего — токмо с целью доказать собственное превосходство.
— или как вариант вопросы про азы, которые я уже давно забыл ввиду неиспользуемости нигде, кроме как в начальных туториалах.

Совсем печальные:
— предложение написать тестовое задание-приложение. Да, некто у них там наспор пишет его за 3-4 часа. А я, значит, должен угадать, какой из двух-трёх десятков возможных вариантов решения их удовлетворит.
— уходящие с тень HR-ы. Все клятвенно обещают обязательно перезвонить, даже в случае ядерной войны… Но некоторые умудряются даже переставать отвечать на звонки.
— и на первом месте традиция спросить «сколько минимум вы хотите денег» чтобы уж точно предложить не больше, не зависимо от степени моей пригодности. Обычно предлагают меньше.
если я такой код увижу в своём проекте, выкину его нафиг

Но перед этим придется выяснить что этот код делал, чтобы правильно заменить его эквивалентным

В своей практике сталкивался с ситуациями при работе с легаси-кодом — нужно исправить «баг» или добавить новую функциональность в «фичу».

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

— Т.е. вместо набора объектов, реализующих Single Responsibility, и общающихся другу с другом по контракту, имеем такую длинную и запутанную макаронину, переплетенную с другими макаронинами.
Логические условия, там где их удается нащупать, записаны как будто специально в обратном порядке, как с точки зрения логики/здравого смысла, так и производительности.

Ок, нащупываем границы кода.
Начинаем рефакторить-распутывать лапшу в заданных границах. По ходу дела вдруг начинает выкристаллизовываться изначальная логика, которая была реализована в виде лапши (логика все-таки была!).

На выходе — код в 5 раз меньше (включая пустые строки для читабельности), логические условия записаны лаконично и понятно, в правильной последовательности, исправлены ошибки, которые были не были видны в клубке лапши (включая исправления для пограничных условий) — т.е., скопом закрывается куча существующих в трекинговой системе багов, и т.д.

Кто все эти люди, которые это писали,
И что со всем этим делать — непонятно

(Я уж не говорю о таких атомарных вещах, когда образчики вида
bool isZero = (i == 0) ? true : false;
byte[] array = new ArrayList(new byte[] { 1, 2, 3}).ToArray() as byte[];

исправляются на
bool isZero = i == 0;
byte[] array = new byte[] { 1, 2, 3 };
)

Хорошо, что не исправить "фичу" или добавить новую функциональность в "баг".

Часто сильно проще выяснить, что должен делать / зачем нужен такой код, чем понять, как именно он работает.
сколько минимум вы хотите денег

Я хочу зарплату как у Чубайса, но вряд ли вы готовы платить мне столько.
Моя ожидаемая зарплата зависит от того, какие обязанности и какая ответственность будут лежать на мне. Давайте сперва обговорим это, я присмотрюсь к вам, вы — к мне, и если мы друг другу понравимся, вы сделаете предложение, основываясь на моей ожидаемой полезности…
Mikluho >и на первом месте традиция спросить «сколько минимум вы хотите денег» чтобы уж точно предложить не больше, не зависимо от степени моей пригодности. Обычно предлагают меньше.

Тут просто. Кто первый назовёт цифру то и… проиграл. ;-)

Когда меня спросили — сколько ты хочешь? — я ответил, сделав паузу, — что знакомый программист подаётся в Норвегию и будет получать там столько-то.

— Эка, — сказали мне, — мы бы сами туда подались на такую зарплату то.

Но цифру моей зарплаты всё же первые произнесли они, в два раза большую чем я рассчитывал. ;-)

Кто первый назовёт цифру

Обычно я примерно знаю, сколько могут дать, а часто зарплатная вилка указана в объявлении. Но суть не в том. Я честно говорю: «Абсолютный минимум вот столько, но это при наличии многих других интересных мне бонусов». И даже список интересных бонусов перечисляю. А потом следует предложение в стиле «никаких бонусов не обещаем, но вы нам очень понравились, предлагаем вам зарплату на 10% меньше вашего минимума»…
Взгляд со стороны.Тем не менее. И не только о собеседованиях.

1. Не перезвонить. (не)отписаться по результатам. Традиция, вызывающая глубокое недоумение у меня.

2. Вопрос об оценках. Некоторым нравится нанимать усердных рабов, причем сами наниматели(сотрудники коллектива) учились не на 5 и даже не на 4.
У них обязательно на это будет оправдание.
Ограничение по возрасту по тем же причинам и с теми же комментариями.

3. Некоторые люди не способны не протрепаться несколько часов только для того, чтобы высказать свое мнение, скорее всего не экспертное, при этом уже в начале разговора решив не брать человека. Затем следуют пункт 1.

4. Приукрашивание текущей ситуации в компании что может в будущем проявится в виде пустой траты времени для обеих сторон.

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

Собеседование собеседованием, а хотел бы почитать как самому отбраковывать собеседующих, сразу или на испытательном сроке.

Только мне после прочтения как текста, так и комментариев, показалось что уж сильно мы, господа и дамы, закушались?

На любом рынке, в том числе на рынке труда, если спрос больше предложения, продавец может и, вероятно, будет кочевряжиться так, как ему удобнее.
Ой, анкетки… =) Проходил собеседование в Melexis на позицию а-ля Test-engineer(тестирование чипов, написание тестовых кейсов на Си и тд.). Выслали 2 анкеты по почте. Вопросы типо: «Каким вы видете своего босса. Кем вы видите себя в нашей компании. Кем вы станете в нашей компании через 5 лет» — и прочие шаблонные вопросы на английском. Ладно, заполнил, отправил. Договорились о встречи. Приехал, рекрутер провел меня через турникет в просторный кабинет с большим столом, предложила что-нибудь выпить, чай, кофе, водички. Начали беседу по тем же анкетам, только уже на русском языке, вопросы такие же. Тест на психологическую устойчивость прошел, принесли мне технический тест с 20 или 21 вопросом, не помню уже. Дали час времени. Вопросы были разные, от схемотехники и узлов чипов, до строк кода на ассемблере и Си. Не скажу что тест сложный, но утомительный с подковырными вопросами. Расчитать схему на ОУ, расчитать четырехполюсник, сколько бит в одном байте(255 или 256). Найти ошибку в Си коде, что выведет данный код и тд. В общем я его не оч. хорошо написал. Ок. После пришел технический специалист, посмотрел тест. Начал по нему задавать снова вопросы, я даже на некоторые неправильные ответы дал устно правильные. После чего показал свои разработки как электронных девайсов так и коды на Си. В общем он начал меня торопить, сказал что у него еще несколько кандидатов и вежливо меня «вытурил». Через два дня звонит рекрутер, дает отказ. В общем не плохо, даже где-то сам виноват, но анкета и разговоры за «жизнь» убили. В этот же день на меня вышел Хэд из Киевского Самсунга, предложил позицию Linux Kernel Developer, на что я ему ответил, что я не совсем программист, а хардварщик. Но он очень настоял на встречи. Хорошо, я пришел, меня встретило секьюрити, заклеили камеру и USB порт на телефоне пломбой, заклеили пломбой крышку ноутбука дали RFID — бэйдж. Встретил меня рекрутер и пошли мы с ним в meeting-room. Он дал мне анкету, кто, откуда, где учился и задание на листочке. Попросил ожидать тех специалиста. На листке бумаги были три задачи на Си, нужно было что-то там оптимизировать и исправить ошибки. Потом пришел технический специалист. Начал гонять меня по указателям и GCC. Но нормальный парень, все вежливо объяснил, указал на ошибки без капли намека на подавление моей личности. Сказал подучись, на что я ему ответил: «Я говорил вашему рекрутеру, что я не сеньер программист». Еще проходил собеседование в Болгарию по скайпу с 5ю тех специалистами на английском — было очень трудно, на что-то ответил, на что-то нет, что-то вообще не понял (название токовый генератор на английском), явно сказался языковой барьер, краснел, пыхтел, тупил… В общем рекрутер. который со мной связывался даже не удосужилась мне отписаться, что я не подхожу. Еще одна персона вышла на меня с вакансией Embedded Hardware Design, назначила звонок по скайпу на время, когда время подошло, в сети ее не оказалось. На следующий день она мне отписалась с извинениями, якобы у нее был срочный митинг. «Да не вопрос» — я ей говорю. Она мне отписалась что на следующий день отпишется, и назначит новое время. Но так и пропала. Вот такие у меня были приключения. Еще я ходил в контору под названием СЭА — электроникс. Просторный чистый офис, парковка, чистый туалет. В общем заводят меня в комнату, где сидят все разработчики. Приходит их ЭйчАйр и начинает мне при всех задавать вопросы, в том числе о желаемой заработной плате. Меня этот момент поверг в шок. Ну окей ладно, поехали дальше — техникал ревью. На меня тупо нападают все сидящие разработчики, перебивая друг друга и задавая вопросы. Эмбеддеры лезут со своими стеками TCP/IP, разработчики плат со своим Altium, схемотехники с расчетами. Причем один схемотехник (опытный дядя) явно пытался меня лошить. Начал грубить и тд. Понравился парнишка программист (соображал в электронике) и разработчик печатных плат. Предложили мне чай/кофе и помогали морально. В общем я оттуда сам свалил. Хотя офис их понравился. Вот такие у меня были истории.
Помню было собеседование на standard test engineer. Вторым этапом, после тестировщика(вполне грамотно проведшего интервью), собеседовал разработчик.И видимо настолько привык задавать вопросы по списку не задумываясь, что вопрос на тему знания мной JS-фреймворков через 5 минут после того, как я ответил что в JS у меня опыта почти нет — его не смутил.
>И видимо настолько привык задавать вопросы по списку не задумываясь, что вопрос на тему знания мной JS-фреймворков через 5 минут после того, как я ответил что в JS у меня опыта почти нет — его не смутил.

Иногда тестировщикам задают вопросы как про JS, или C++ или SQL — чтобы… хоть как-то просеять, когда слишком много на одно место приходят. ;-)
Ну тут как бы претензия не в языке, с этим то как раз все понятно. Тут вопрос в последовательности вопросов: сначала задается вопрос про JS, и выясняется что я не имею опыта с ним, а затем — вопрос по опыту с JS-фреймворками, что вводит меня в ступор, т.к. я уже несколько минут назад(меньше 5) уже ответил, что у меня нет опыта с JS, если я не работал с JS — откуда у меня может оказаться опыт работы с JS-фреймворками? Тут возникает вопрос — слушал ли мои ответы разработчик или так, в половину уха, и собеседование с разработчиком было чисто формальным? Но если так — тогда зачем тратить на него лишний час. В общем такая невнимательность интервьювера к собственным вопросам производит не лучшее впечатление.
4 года назад в яндексе 8 часов подряд решал логические задачи. Меня даже покормили за счет заведения.
Офер дали, но я отказался, после того как сходил на еще одно собеседование, где просто дали в руки железяку и спросили смогу «оживить», я сказал что смогу. И вот уже 4 года оживляю всякие интересные штуки.

А по заметку могу лишь сказать, что автору с его тонкой душевной организацией явно не повезло (10 мест за 10 лет, тому подтверждение). Проблема не в собеседовании.

>(10 мест за 10 лет…

Это просто СУПЕР. Каждый год менять офис! Завидую.

У меня на годы «на одном месте». ;-)
И у меня та же печаль =(
А что вам мешает менять?

Если через год на работе становится грустно, может надо отрасль поменять? Мои старшие коллеги уже по 25 лет отработали и им все так же интересно и фонтанируют идеями.

>А что вам мешает менять?

Вот не могу себя заставить!

>если через год на работе становится грустно, может надо отрасль поменять?

Вместо того, чтобы уйти в новый офис, страну, работу, зарплату(!)… сочиняю как внедрить новое на одном и том же месте.

Завидую «летунам». ;-)

Иногда за внедрение инициативно — нового получаешь дополнительный багаж на свой горб =) Тут конечно от компании зависит. В одной из которых я работал, разработал по своей инициативе железяку. Дали мне типо бонус, внедрили в производство (с контрактниками я лично договаривался по изготовлению и монтажу на их линии). Зато потом на мою шею чуть — ли не покупка, склад и доставка компонентов на контрактное производство не легло.
С анкетированием была интересная история — меня в приёмной, совмещенной с шумной частью офиса (несколько человек постоянно разговаривали) заставили заполнять анкету, которая один в один повторяла пункты резюме отправленного им ранее. Дальше интереснее: программисты у них сидят как швеи на китайских фабриках — в небольшой комнате много столов, стоящих впритык и узкий проход. В конце туннеля сидит начальство в отдельном большом кабинете. Собеседовали в 2 этапа: сначала опросил тимлид, потом на те же вопросы отвечал начальнику, который подошёл заметно позже. Периодически еще и HR присутствовал. Перекрёстный опрос — вообще весело. Было ощущение, что меня пытаются продавить. Из обязанностей работа со всеми видами CMS на всех видах популярных веб технологий. Единственные, кто настаивал на подписании контракта, хотя бы на год. Можно было бы даже почувствовать себя голливудской звездой, если бы не предлагаемая оплата. Апофеозом был вопрос: «Почему вы хотите работать в нашей фирме?» Честно ответил, что я не хочу.
Есть такие конторы, которым нужен не творческий программист-разработчик, а кодер-шестерёнка, механически набивающий всё новые отчётики, экранчики, таблички с минимальными отличиями в имеющейся монструозной системе.
>Есть такие конторы…

Возможно и есть. Но обычно проекты меняются часто и просто так «набивать отчётики» из одного в другом не получится. Меняются как технологии сборки, среды разработки, тестирования, библиотеки, фреймворки, языки и прочая и прочая…

Так что либо начинаешь осваивать новое и быстро — либо… становишься не нужен.

А так да — возможно и есть конторы…

Работал с сишником, который уже 15 лет поддерживает одну систему. Он нужен этой системе (ибо только он владеет информацией о кое-каких ей частях), у него отличные мозги, но сможет ли он сменить работу без существенных потерь в з\п — большой вопрос.
>Работал с сишником, который уже 15 лет поддерживает одну систему.

Верно. Но сишники — они могли бы и 30 лет писать на С. ;-)
Это наверное исключение из правил.

Сейчас появляются люди которые на SQL пишут лет 20.
Это второе исключение из правил.

Есть и Java-программисты по 15 лет пишущие.
Это третье исключение из правил.

И всё. :-)
Не понимаю, чем плохо анкетирование. Ты ответил на пятнадцать простых вопросов или прошёл онлайн-тест и сэкономил себе и людям кучу времени. Взамен они не будут спрашивать тебя всякую очевидную ересь и сэкономят время и настроение тебе. По-моему понятно, что если до тебя собеседующий успел пообщаться с двадцатью неудачными кандидатами, то на тебя у него не осталось ни сил ни мотивации.

Вообще, если не хотите идти «с общим потоком», сделайте что-нибудь, чтобы вас заметили и вы не приходили на собеседование как очередной Вася Пупкин №123.
Потому что анкету по резюме мог бы заполнить и кадровик или кто там приглашает. Если вдруг чего не оказалось из обязательных полей их hh-системы, предложить недостающее заполнить кандидату. По этому моменту вполне видно отношение фирмы к соискателям. Вместо опросника на 300 вопросов по психотипу тоже можно что-то более вменяемое придумать. Будут хранить потом эти анкеты/результаты опросника непрошедших кандидатов?.. Но ведь люди меняются, меняются их знания, меняются цели.
Мне как-то отказали в должности только потому, что «работник на эту позицию на работу должен приезжать на личном автомобиле, и этот автомобиль должен выглядеть респектабельно». Серьезно повысили настроение)
Я имел ввиду исключительно техническое анкетирование — вопросы, которые нельзя вычислить по резюме. Переспрашивать ту информацию, которую кандидат уже предоставил — это конечно же запредельное хамство.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий