Comments 294
Одна, совсем маленькая, директор сидит в полутемной комнатке, заваленной хламом. Конечно, у них полно иностранных заказчиков, и миллиардные бюджеты, кто бы сомневался. Собеседовал лично директор. Задавал задачи на логику. Одну задачу я решил, вторую не стал. Я пытался завести разговор на технические темы, но очень быстро понял, что он в этом не шарит. Когда я сказал, что работаю только по ТЗ, он сказал, что у них научная фирма и им нужны творческие люди, а не исполнители, работающие по ТЗ.
В другой фирме я написал тестовое задание, сдал экзамен на сертификат, мне HR сказала, что всё очень хорошо, я пришёл, там было два человека, они задавали вопросы, я отвечал в меру своих знаний, потом они сказали, что к ним приходит по несколько человек в день на интервью, и что они мне позвонят. Разумеется, никто не позвонил.
Потом, правда, позвонила HR из этой же компании, предложила работу в другом отделе, где я сейчас и работаю. А про тех ребят, она сказала, что я их испугал.
им нужны творческие люди, а не исполнители, работающие по ТЗПлавали, знаем: через месяц начинаются крики «за что я вам зарплату-то плачу, где результат!?!»
Да, слишком умным тоже не надо быть. На… собеседовании. ;-)
Я высказал о нем все что думаю. Я так сделал в первый и последний раз в жизни.
Означает ли это, что вы пожалели об этом? Или вы не так выразились, или я вас не понял.
Давайте для статистики стек технологий озвучте.
> кроме наличия умения решать головоломки.
Вот интересно, а людям, которые как старый патефон повторяют эту заезженную фразу, не приходит в голову, что собеседующему в команде могут быть нужны люди, именно что умеющие решать головоломки?
Говнокодеров мне в любой момент пачку любое рекрутинговое агентство подкинет.
А что вы скажите об умении решать кроссворды?
Я не смог распарсить, к какой части моего комментария относится этот вопрос, простите.
Я не понимаю, что такого странного в том, что к себе в команду я набираю людей, которые соответствуют моим представлениям о хорошем разработчике?
Я же не настаиваю на том, чтобы все остальные вели себя так же. Просто нам с теми людьми, которым неуютно разговаривать на собеседовании про круглые люки — не по пути, вот и все. И лучше всего понять это как можно раньше.
>Я не смог распарсить, к какой части моего комментария относится этот вопрос, простите.
(а ведь это была _даже_ не головоломка...) Решать головоломки того типа, что вы задаёте на собеседованиях?
>Просто нам с теми людьми, которым неуютно разговаривать на собеседовании про круглые люки — не по пути, вот и все. И лучше всего понять это как можно раньше.
А, то есть вы говноголоволомщиков себе набираете? Ну, это бывает :)
Итог — собеседуйте пожалуйста адекватно. Не нужно спрашивать криптограффию или предлагать сиюминутно решать задачи на тему коэффициента трения при увеличении скорости объекта, когда на проекте придётся писать только пединги и маргины (я утрирую но надеюсь суть понятна).
Понятно что каждый владелец компании пытается приувеличить как свою значимость, так и значимость компании в целом но будьте адекватнее. Если задаёте задачки на логику и гоняете человека, то хотябы для себя будеть уверены что данному кадидату именно с этим и работать.
Сами пишут в требованиях фигню всякую, а потом возмущаются: «ай-ай-ай, какие редиски приходят — головоломки решать не хотят».
Вы придержите полет своей фантазии в следующий раз.
Ну и да, раз уж зашел: программист, не умеющий и не желающий решать головоломки, называется «говнокодер», и, как я уже сказал, их пачками подгоняют агентства.
Там все было не совсем так. Писать код она могла — но она просто не знала современных способов его написания. Плюс все это было наложено на ноду с ее тотальной асинхронностью на колбеках.
Да, умение писать код — базовый навык, который никто не отменял. Людей, которые умеют только писать код в последнее время вокруг очень много. Из них нужно выбирать, понимаете?
Еще я умею в голове создать правильную модель, выделить абстракции, понять, какие из них являются лишними, выбрать инструментарий.
Все, сказанное в последнем предложении — умение решать головоломки, на сколько-нибудь сложном проекте.
Есть люди, которые любят собирать паззлы, а есть, которые не любят — тоже самое с головоломками, которые есть ни что иное, как антипаттерн от HR, которые в большинстве своём в теме разработки ПО совсем не разбираются, но человека «отобрать надо», а значит они дают головоломку и, по их словам, «смотрят как он её решает — само решение не важно». Типичная туфта от человека, который один раз грамотно и удачно её применил и все дружно бросились её повторять, надеясь, что эта фича поможет им отобрать супермегапрограммистов.
Не поможет. А просто покажет выдержанность наблюдаемого — будет ли решать или психуя скажет: «ну вас нафиг и сгрызёт карандаш».
Типичная проверка на адекватность, а раздули невесть что.
Программист, не умеющий и не желающий решать головоломки, называется "программистом не умеющим и не желающим решать головоломки". Ни больше и ни меньше. Он с равным успехом может писать как хороший, так и плохой код, но вы этого с высоты своей осины, ограниченной дремучестью, не узнаете никогда - потому что вы его не наймёте.
Мало того, вы вон в обычной беседе уже дважды контекст теряли: вам на это я сейчас указываю и @avostчуть раньше указывал - в вещах, которые "даже не головоломки" вы потеряли суть. Являетесь ли вы на основании этого плохим "головоломщиком"? Вас наняли по ошибке (ещё не было фаната-головоломщика вроде вас, чтобы НЕ нанять вас)? Или вы являетесь говнокодером? Вообщем тут целый спектр вопросов о вашей компетенции, основанной на банальной невниматьельности.
Вы называете людей, которые не подходят по вашим ограниченным (и ИМХО глупым) критериям - говнокодерами. Хотя они могут писать намного лучший код чем вы - просто не любят решать головоломки.
P.S. Не указывайте что мне делать и я не буду советовать вам направление куда идти. ;)
Я буду обновлять комментарии, честно =\
собеседующему в команде могут быть нужны люди, именно что умеющие решать головоломки
Серьёзно?
Так вы не программиста ищете, а решателя головоломок?
И большинство задач у вас состоит из хитро придуманных ребусов? Или всё-таки из новых фич, которые надо проектировать и легаси-кода, который надо поддерживать и рефакторить?
Что за компания у вас такая, огласите название, пожалуйста. Уверен, тут найдётся много желающих пополнить свой чёрный возможных список работодателей.
Под ваше решение подходит как минимум еще одна фигура.
Эти известные "гуглевые" задачи не предназначены для выявления программиста. Они предназначены для выявления инженера.
Давайте для статистики стек технологий озвучте.
Месяц назад собеседовался на .Net разработчика, в 4 компаниях.
1. Внешний рекрутер, тест на английский, тест типа IQ, тест на математику, личностный тест общение с лидом (технологии), разговор с лидом и рекрутером.
2. Тестовое задание. Написать простенький сервис, простенький ASP.NET сайт. На все — 4 часа (более чем достаточно). Потом собеседование.
3. Разговор с лидом. Исключительно вопросы о технологиях. Полтора часа.
4. Два собеседования по часу, вопросы личные, технологические, задачки.
Допустим, я собеседуюсь на позицию java junior, передо мной кладут кубик Рубика и просят его собрать. Что покажет мой отказ?Покажет проактивную позицию, т.е. что Вы не тупо кидаетесь выполнять задачу, а сначала думаете зачем и можно ли обойтись вообще без этой задачи. На самом деле, это очень ценное качество.
Хотя на позиции, связанные с Java или с Go, такое вряд ли заценят, там обычно нужны «винтики», тем более на junior-уровне.
Поддеваете ногтём один из 8 угловых сегментов, выковыриваете его, затем разбираете весь оставшийся кубик. После чего собираете его уже правильно раскрашенным, тем самым показывая свои находчивость и умение нестандартно мыслить.
Почему?
Культура собеседований компании позволяет допускать этих умников до кандидатов. Вы не считаете это проблемой компании?
А если все так и было, то далеко не факт, что культура собеседований компании далеко не обязательно позволяет такое. Просто описанный опыт кореллирует с моим личным и я призываю не обобщать основываясь на одной частности.
Ну тоже верно, да.
Ну давайте будем объективны, грибы в таких задачах просто для разбавления сухости и упрощения понимания. С таким же успехом вас могли попросить рассчитать абстрактную величину X.
Все хорошо, но… почти никогда не присутствует ПМ
А ведь при современной постановке разработки — аджайл, скрам, проектные команды, ПМ как главный начальник над командой — именно ваша совместимость с ПМ'ом, начиная от психологической совместимости и заканчивая взглядами на процессы разработки, определяет, насколько плодотворно вы сработаетесь.
Череда интервью в течении дня с 1-3 собеседующими — это более вероятный вариант.
Где-то полгода назад была ситуация, когда собеседовало именно 5 человек. Тех.дир, тимлид, 2 программиста и то ли ПМ, то ли генеральный, уже не помню. Сперва весьма пугало такое численное превосходство, но разговор быстро перешел в приятную беседу. Обговорили и технические моменты, и организационные. Неуютно, но продуктивно.
Не прошёл, но тут сам виноват, ляпнул на паре вопрос лютую дичь.
Бывает так что ваше резюме видели ребята из разных команд и им всем хочется на вас посмотреть… Ничего плохого в это не вижу…
А если серьезно, не всегда возможны раунды. И реально часто лучше собрать человек 5. С другой стороны, я очень сильно сомневаюсь что юниора (мидла) будут 5 человек собеседовать. А сеньёру бояться 5 человек… Ну разве что если он «по стажу» сеньер, а не по сути, тогда да. А так — какая разница, какая аудитория то. Да и чем больше людей, тем интереснее с ними «играть в собеседование.
К чему я это — за час с человеком можно разносторонне обсудить вполне себе интересную задачу, где будет и дизайн, и архитектура. И интересующие куски можно попросить закодить. И мнение составится. За последние 10 лет я интервьюировал много кандидатов в Майкрософт и Гугл — именно на часовых интервью (где я был одним из 5-6 человек у кандидадата за день). И как-то оно все же работает. Не всегда нанимаются правильные люди и иногда правильные не нанимаются, но в общем случае вполне себе система работает.
если кто-то это выдержит — уже нужно брать :-D
Я лично сам пару раз собеседовал, а пару раз мне говорили,
>> там это XX пришёл, если у тебя нет горячих тасков поговори с ним,
Я — Пилю такую фичу, сдавать уже в концу дня
>> Ок.
И идут к следующему столу :D С тем же предложением :D
наплмнил им что я скалист, ответили что заказчик считает что спец. знающий скала лучше чем просто джава разраб, после чего (после первой части по скала которую прошел) сказали что не подойду, неадекватное открытие года))
Выводы: Сказать, что осадочек неприятный остался, значит ничего не сказать. Вели меня, как слепого щенка, не давая полной информации. Ссылок на место\вакансию никаких не было, чисто переписка по почте, так бы сам отказался — ведь не по профилю. Почему я сам не задавал вопросы, ничего не выяснял, приведу следующие аргументы:
1. Просто не ожидал такого предвзятого подхода.
2. Думал раз все расписано в резюме, то hr должен понимать, на что я годен. Есть ведь стек технологий.
3. По сути hr вступила со мной в спор и пыталась доказать, что я идиот. Приходилось сдерживать себя, чтобы не нагрубить. Добившись шаткой положительной позиции, просто хотелось закончить с ней разговаривать.
При отказе можно было бы просто показать требования к стажерам, как причину. Но нет кругом загадки и личный бесконечно богатый опыт.
Много непонятного в работе данного сотрудника. Мое резюме она получила раньше, еще раз там все есть, и вопросы крутились только вокруг него, не затрагивая вопросов по разработке. Зачем назначать собеседование, если заранее собиралась отсеять? Она пришла к выводу отсеять на собеседовании? Так ничего нового я не сказал(резюме). Но даже сбор информации по прошлому непрофильному опыту был неорганизованным. Рекрутер перебивала, скакала с одного периода на другой, чем больше запутывалась. Хотя я хотел начать с самого начала. В итоге все то же самое, но по 20 раз.
Ежу понятно, что это был просто формальный предлог от меня отвязаться, но для меня до сих пор загадка, чем я им так не понравилась.
Был случай: собеседовался в «большой немецкий банк». Меня таскали так, что жесть. Спрашивали такие вопросы, которые могут пригодиться только разве что программисту ядра .NET. После чего сказали что старший разработчик .NET — это такая позиция, где надо будет автоматизировать тестирование. Вот зачем меня тогда все это спрашивали?
Вопрос в Люксе скорее в том, что туда прособеседован, наверное, весь город. Ну и много людей, которых отшили. По разным причинам. Бывает, как на экзамене, спрашивают не то, что знаешь. А бывает что не знаешь и все равно — обидно.
Потом еще несколько раз звонили и снова звали на собеседование. Хотя в конце встречи я явно сказал HR-у, чтобы вычеркнули меня из своей базы навсегда.
А вот на очном было что-то странное. Или вопросы по C, но из серии «что будет, если написать так, как нормальный программист на C не напишет никогда». Или же задачки как бы по программированию, но в совершенно нереалистичных условиях, вроде «найти зацикливание в бесконечном списке за бесконечное время с бесконечной памятью», те же головоломки по сути. Справедливости ради, я так офигел от происходящего, что на пару нормальных вопросов тоже не ответил.
А вы вопрос не перепутали? Я вот слышал про задачу «найти зацикливание в бесконечном списке за конечное время с конечной памятью», это совершенно нормальная задача, разрешимая когда элементы списка уникальные либо разрешено сравнивать ссылки на хвосты списка.
Рассказываю решение: берете два указателя, и пускаете их в цикле по списку от головы вперед, один со скоростью два (три, четыре, всё равно) элемента за итерацию, второй — по одному элементу. Если второй указатель «столкнулся» с первым, значит есть зацикливание, если дошел до конца — нет. Ну, в общем, или догадаешься или не догадаешься. Головоломка.
Живо себе представляю программиста, который таким образом решает задачу в реальном проекте. Особенно в embedded.
А при чем тут добавление полей? И где тут бесконечные память и время?
PS односвязные списки широко используются. Особенно в embedded, где нельзя решить задачу просто накидав 100500 библиотек. Сама задача, очевидно, проверяла насколько хорошо вы знаете односвязные списки.
Порой ответы на это все получаешь потратив тонну времени на тестовые задания, собеседования и т.п.
Из похожих примеров: «Реализуйте двусвязанный список». Реализовать-то можно, но зачем?! Тем более если это должно быть сделано на листе бумаги…
Ну так это же очень печально для собеседующего: он смотрит не умение работы в реальном проекте и решения реальных задач, а абстрактные сортировки в вакууме.
И наймёт людей именно с такими навыками, а не тех, которые умеют работу работать вовремя.
Конечно из написанного кода можно получить полезную информацию: как кандидат соблюдает правила оформления кода, как описывает классы и объекты, простоту решения и т.д.
Но эту информацию можно получить практически из любого кода. Намного интереснее, к примеру, попросить кандидата найти ошибки в оформлении и оптимизировать небольшой кусок кода.
К тому же часто кандидат пишет код упрощённо и может намеренно писать «некрасивый» код, т.к. задача часто ограничена по времени и кандидат считает, что важнее написать что-то рабочее, чем правльно-оформленное. Опять-же задача с оптимизацией существующего кода более наглядна.
Реализуйте умножение матриц алгоритмом Копперсмита-Винограда, и я соглашусь с первым вашим утверждением. Но на самом деле наивно полагать, что любой человек, называющий себя программистом, может реализовать любой алгоритм любой сложности.
Полагаете, давать на собеседовании отрефакторить код гуманнее, чем попросить реализовать сортировку?Смотря что за код, само собой это должен быть специально заготовленный небольшой фрагмент изолированной функциональности, покрытый тестами.
Но на самом деле наивно полагать, что любой человек, называющий себя программистом, может реализовать любой алгоритм любой сложности.Это вопрос времени. Чем сложнее алгоритм, тем больше времени займёт его изложение на языке программирования.
Нет, не напишу и не сильно переживаю по этому поводу.
И я плохо представляю задачу, в которой мне придётся писать какую-бы то ни было сортировку в принципе.
Так что ваше утвержение можно инвертировать: все задачи обычно намного сложнее сортировки и в них чаще всего требуется придумать новый уникальный алгоритм, а не повторять уже ранее реализованный. (Конечно это не отменяет знаний паттернов и часто-используемых алгоритмов, но сортировка в современной разработке к таким не относится.)
Я порой ищу себе различные не фулл-тайм подработки, чтобы мозг не плесневел. По основной специализации — разработчик автоматизированной системы тестирования. Создал весьма сложную систему. Но вот на днях завалил собеседование из-за того, что какую-то мелкую фигню напутал. Т.е. на мой взгляд таким людям, которым до вот таких сортировок охота прикапываться, им важнее, чтобы человек был ходячим гуглом по не важным вещам, чем компетентный «разработчик систем под ключ».
1. Не пытайтесь показать фирму солиднее чем она есть на самом деле. Видел конторы в подвале, у которых были ожидания как у Гугла, а предложить сами они могут немного… (Если у вас небольшая фирма и если вы не можете предложить большую зарплату, то не завышайте планку и старайтесь привлечь нематериальными бонусами: например гибкий график, работа из дома, дружный коллектив, интересные проекты и т.д.)
2. Спрашивайте только то, что может понадобится в текущем проекте или в ближайшем будущем. Есть люди, которые могут «зависнуть» на простейшей логической задачке, но зато выдают на-гора качественный код в очень сжатые сроки. Единственное исключение, это проверить умение искать выход и делать предположения при попадании в незнакомую область знаний и проверить обучаемость…
3. Создайте комфортную атмосферу. Улыбайтесь, будьте дружелюбными. Общайтесь на равных. Не относитесь к кандидату как к просителю. Ведь устройство на работу — это обоюдовыгодная сделка. Было бы приятно видеть хотя бы бутылку с водой и стакан.
4. Не увлекайтесь практическими задачами. Они должны быть, но они должны быть решаемыми за 10-15 минут без помощи Интернета. (Т.е. не делайте упор на конкретную реализацию, а лучше на общее понимание и архитектуру).
5. Лучше всего когда в интервью участвуют 2-3 человека со стороны организации: HR, технический специалист (лучше если из команды проекта), и, возможно, ПМ.
6. Не задавайте глупых вопросов. (в дополнение к п.2). Классические примеры «Кем вы видите себя через 5 лет» или «Почему вы выбрали нашу фирму». Большая часть кандидатов ответят то, что вы хотите услышать, а не то, что думают на самом деле…
7. Уютный офис, светлое помещение, удобные кресла и столы, чистота. — Это то, чем запоминается компания. По своему опыту могу сказать, что отказался от работы в компании только из-за того, что не был готов проводить треть своей жизни в тёмном и неубранном помещении, хотя проекты обещали интересные, а зарплату конкурентоспособную. Ведь если фирма не может даже организовать порядок в офисе, то вряд-ли она сможет грамотно планировать, что приведёт к долгим овертаймам и прочим прелестям…
8. Отвечайте сразу и честно. Если после интервью компания пропала больше чем на неделю, значит на ней можно ставить крест. Намного приятнее получить отказ с объяснением причин или же информацию о том, что кандидатура заинтересовала и через неделю будет 2ое интервью, чем сидеть в неопределённости. Цените чужое время!
PS: Да, работу я в итоге нашел, но повторить все это еще раз… Бррр.
Из плюсов: действительно за вас болеют перед работодателем.
Из минусов:
Заколебали распросами про текущее место работы — сколько зп? Сколько вас человек? Где зарегистрирована компания? Какие в вашей компании бонусы? Как долго компания существует?
Ну какое вам дело? В резюме написано. Интересно — погуглите, это ваша работа. Мы же мои навыки должны проверять, а не пытаться выведать все про текущее место.
Когда озвучил ожидаемую сумму ещё потратили 5 минут, уверяя что я просто ОБЯЗАН сказать сколько сейчас получаю, а то чего это я денег прошу столько. И что вообще у них желания нет сотрудничать с таким закрытым человеком(ну да, оно же мне надо, а не вам заказчики за сотрудников платят).
После тз и ещё 4 нетехнический (серьезно, 4 интервью с вопросами «что вам интересно по жизни». И после каждого звонят из агентства с вопросом «ну как, что сказали?») интервью с самой организацией, предложили зп на 20% ниже озвученного пожелания и получили ожидаемое «мне это не очень интересно» — сказали что это же потрясающее предложение!
А есть у кого-нибудь успешный опыт общения с рекрутинговыми агентствами? Может, мне просто не повезло?
Одно агенство — просто чекнули меня на адекватность, на язык, дали подобную инфу про целевую компанию и процесс найма. Нашли мне два хороших собеседования. Более того, сориентировали меня по зарплатам в регионе (честно проконсультировали, проверял).
Другое агенство — милая девушка, которая писала какие-то странные вещи про оформление резюме. В итоге позволила себя переубедить и нашла отличное собеседование.
Про текущую зп — спрашивали везде. Всегда есть вежливый ответ: цифра под NDA.
Но вообще у меня вопрос — значит ли это, что условный бухгалтер может на каждом столбе писать «зарплата у %User такая-то», и ему ничего за это не будет от государства?
Есть закон «О коммерческой тайне», который говорит, что система оплаты труда не может являться коммерческой тайной. Т.о., сведения о ЗП являются персональными данными сотрудника — т.е. вы можете распоряжаться ими по своему усмотрению, организация не может накладывать ограничения на эти сведения. Сотрудники же организации, в которой вы работаете (бухгалтерия, например), должны распоряжаться этими сведениями, как и другими персональными данными — включая ответственность за разглашение.
Сначала он сам со мной пообщался — подробно объяснил, что за проект, что за роль, какие нужны навыки, выдал кучу информации о компании и стране, в которой нужно будет работать. После этого сказал, что, на его взгляд, я вполне на эту вакансию подхожу и, если я не против, он меня будет туда устраивать.
Перед каждым собеседованием он узнавал, о чем примерно будут вопросы, присылал 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 года, то хорошая анкета часто бывает результатом выдернутых кусков из чужих резюме, как потом оказывается, или кого-то попросили написать. Лучше непосредственно напрямую общаться.
Ну, наверное.
Это одна сторона проблемы. Ведь еще анкеты как сделаны, как будто их не проверяет никто перед созданием. У меня тоже солидное число в области собеседований за 150, и из них всего три раза попадались адекватные анкеты. Дадут листочек, а в нем даже место под ответ не предусмотрено, и вот начинается ужатие текста, мало того что «анкета это так», так еще получается что им и ответы не так важны, потому что вписать туда реальный ответ места не хватает, да и сами вопросы порой это не что. Мне кажется анкетирование должно идти вторым пунктом после собеседования, а не первым.
Но ряд вопросов был слишком, мнэ… Интимен, на уровне «есть ли у вас кредиты? В каких банках? На какие суммы?».
Что любопытно, отказ от заполнения анкеты не вызвал отказ от собеседования и последующего предложения работы.
Больше всего раздражали анкеты, в которых надо заполнять все тоже самое, что есть у меня в резюме. После пары таких анкет, просто разворачивался и уходил.
Сверх наглость была, когда в анкете просили указать свои паспортные данные. Я слал лесом таких. И так делают достаточно крупные компании.
Внезапно! Ваш кэп!!!
А как-то раз пообещали супер-мега вопросы от суперспецов. В результате общение по скайпу с примерно 6-тью лбами, и ни одного нормального вопроса. Больше часа потерянного времени. Все вопросы были стандартными и шаблонными. Причем, такое чувство, что на джуниорский вопрос а-ля «что такое полиморфизм» ожидался джуниорский ответ, заученный из учебника, а не объяснения своими словами. То чувство, когда собеседующие смотрят на тебя свысока, но сами при этом никакие. К собеседованиям должен готовится и собеседующий, и у него есть большой козырь, он может повести разговор в сторону любой технологии. А вот собеседуемому вспомнить технологию, которой он занимался пару лет назад может быть сложно. Касательно логических задачек — бррр… Согласен. Читать и заучивать решения из сети это дурной тон. И оценивать кандидата скорее нужно по оригинальности предложенного решения или варианта. Пусть даже и ошибочного. В этом суть.
PS: собеседования в Люксофт у меня были — понравились.
Причем, когда холодно (кондиционер — прямо над головой) — это особенно плохо, т.к. мозг начинает занимать себя мыслями:
О, да. Однажды я так здорово влип. Темно, холодно, чаю не предложили и «напишите три задачи по SQL на бумажке».
2) Собеседовали в сбертехе. Там есть адекватные отделы (с одним из них я сейчас работаю, будучи в другой компании), но эти ребята были фееричны. Собрали человек 8, каждый из которых не знал, о чём со мной говорить. Я пришёл туда со словами, что для меня этот стек новый, я его не умею, но мне было бы очень интересно попробовать (несколько раз писал об этом до собеседования). В результате мне отказали потому, что я не знаю этот стек :)
3) Ещё в одной компании, которая мне очень понравилась, заранее предупредил, что в силу некоторых обстоятельств меня устраивает только белая зарплата. Две недели общались, друг другу понравились… Когда пришёл договариваться, когда выхожу, сказали, что зарплата серая. Спасибо, до свидания.
4) Ещё в одной выдали домашнее задание с объемом работы на неделю. Ребята, вы простите, но вы не конкурентоспособны — у меня нет столько времени чтобы тратить на потенциального и не слишком сильно выдающегося работодателя. К тому же за эту неделю я нашёл более интересное предложение.
5) Ещё в одной компании искали разработчика на Go. Отлично понимая (плюс им в карму), что их крайне мало, искали адекватных людей с опытом в других языках, чтобы перевести. Как тест, выдали солидное задание… Парарам… На Go.
В общем, слава богу, что я отсеялся и отсеял эти компании. В результате нашёл место работы с хорошим доступным офисом, отличным коллективом, высокой белой зарплатой, и я там востребован со всеми потрохами. Главное было не спешить…
Во-первых, все вопросы однотипные и «понятные» (например, «насколько собеседований вы сходили», «почему ушли с предыдущего места работы», «как давно ищете работу»). На подобного рода вопросы (если кандидат не идиот) легко ответить. Т.е. кандидат понимает, что от него хотят услышать и может совершенно «верно» ответить на них. И довольный hr, что нашёл «отличного» кандидата кричит: «Бери». Из таких кандидатов больше половину составляют лентяи, безответственные личности, не профессионалы, люди, не умеющие работать в команде. Остальная часть это нормальные кандидаты и полная им противоположность.
Эти «противоположности» — это как раз «тот случай», когда ты пьешь 2 дня успокоительные после такого сногсшибательного собеседования.
Также, заметила, в нашей прекрасной компании не любят указывать размер зп. И, зачастую, уже на втором собеседовании (на котором присутствует руководитель) только всплывает этот факт, и кандидат уходит не довольный.
За свой небольшой стаж работы ходила сама много раз на собеседования, видела множество hr'ор. Единственный человек, который был профессионалом своего дела взял меня на последнее место работы (вскоре после моего прихода, этот человек ушёл). Этот человек умел задавать «правильные» вопросы. После которых складывалась полное понимание, что за человек перед тобой сидит. Остальные — молодые девушки с «яркой внешностью», которые не понятно по каким причинам попали на своё место. Совершенно не знающие и не понимающие того, кого необходимо искать. Не понимающие людей.
2) Тестовые задания умопомрачительных размеров, глядя на ТЗ которых, хочется сразу оговорить стоимость выполнения работы. Тестовые задания, которые просят выполнить на «листочке», отнесу сюда же. Одно дело нацарапать что-то на псевдокоде, показав алгоритм решения, и другое, когда начинают задавать вопросы о пропущенных кавычках, в рукописном тексте программы. К таким у меня только один вопрос, у вас что, перо и чернила вместо IDE?
3) Вопросы личного характера. Я могу понять зачем HR хочет узнать есть у меня жена и дети, но зачем ему знать, как и почему я расстался с бывшей?
Когда я общаюсь с девушкой, я понимаю что я у нее не первый. И даже не второй, скорее всего. Но мне не приятно видеть «следы» бывших рядом с собой.
Согласен )
4х-часовое (или больше, не помню) собеседование со всеми членами команды, где вопросы варьировались от нахождения суммы сходящегося ряда до написания рабочего кода для тестовой задачи на своём ноутбуке (не выходя из переговорки). Потом переводы научных статей, обсуждение методов оптимизации производительности кода и т. п. Это всё после череды собеседований по скайпу, каждое около часа (с аналитиком, разработчиком, отцами-основателями). Правда народ там вежливый, было интересно.
HR у них не было, т. к. компания маленькая. Претензии традиционные: 1) на одном собеседовании математика с программированием не дружат. 2) написание работающей программы на собеседовании с компиляцией и разбором исходников — это слишком; алгоритм я могу и на бумажке нарисовать, а разбор краевых случаев — это рутина.
На всех собеседованиях очень сильно помогало наличие pet project'ов на github'е. Вопросов по программированию становилось на порядок меньше, собеседующие просто листали исходники.
В реальной работе, например, как раз приходится дружить математику с программированием, а значит — отличный тест кандидата.
Если работаешь с кодом — математику только читаешь (если она вообще есть). Работаешь с IDE, отладчиком. Важно не только решить задачу, но и прийти к консенсусу с коллегами (архитектом) по способу решения. Это социальная работа с «разбавленной» отдачей в случае достаточного инженерного потенциала в команде. В данном случае адаптация решения к существующей инфраструктуре зачастую первична. Результаты такой работы можно оспорить (например, на код-ревью).
Ни разу не приходилось смешивать математику с программированием (релизным, продуктовым) в течение короткого времени. Это разные контексты, переключение между которыми отнимает время. Если мы говорим о программировании в терминах составления алгоритмов и их реализации в псевдо-коде — пожалуйста, но в этом случае странно требовать проверки граничных случаев, отладки и т. п.
Ну и по самому собеседованию — после второго часа голова уже не работает. Ни у тебя, ни у проверяющих.
У нас есть краевые случаи — вычисление 1го члена ряда и инициализация переменных внутри функции. Вас интересует именно это в первую очередь (как тестировщика).
Меня, в первую очередь, интересует сам алгоритм. Потом — для каких наборов входных данных он будет вызываться, есть ли там повторы, какой типичный диапазон, можно ли развернуть цикл, и т. п. Проще говоря, мне более важен proof of concept. Детали добавим потом, если предложенная идея сработает. И только тогда, когда она сработала, откладываем в сторону карандаш с бумагой, и начинаем кропотливо писать тот код, который уйдёт в конечный продукт.
Можно собеседовать кандидата «обходом графа в ширину», а можно — «обходом графа в глубину». В своём первональном посте я высказал ИМХО о том, что «обход графа в ширину» предпочтителен, и аргументировал точку зрения.
Вы так пишите, как будто краевые случае нужно только тестировать, но программировать не обязательно.
Вычисление тех же чисел Фибоначчи обычно состоит из краевого случая (он же инициализация) и шага цикла.
Детали добавим потом, если предложенная идея сработает. И только тогда, когда она сработала, откладываем в сторону карандаш с бумагой, и начинаем кропотливо писать тот код, который уйдёт в конечный продукт.
Очевидно, что проверка краевых случаев входит в написание кода, который уйдёт в конечный продукт. Также очевидно то, что написание и проверка многих краевых случаев зачастую необязательна на этапе подготовки PoC (пишем те 20% кода, которые будут покрывать 80% рабочих сценариев).
Если на собеседовании со мной будут говорить люди, с которыми мне придется непосредственно работать — то это хорошо. Чем их будет больше — тем лучше, мне тоже очень интересно на них посмотреть. Самое чувствительное для меня — это качество команды, и именно по этому параметру я принимаю окончательное решение. Пусть будет допрос.
2) Ничего не имею против логических задачек на собеседовании. Для меня они маркер, что с этими людьми мне не по пути, спасибо за внимание, отрицательный результат — тоже результат.
Бесит, когда после нормального в целом интервью, когда на все вопросы вроде ответил (потом проверил по мануалам и выяснил, что таки да, ответил), а HR пропадает на неопределенное время или с концами. Не страшно, что не берут, причины бывают всякие, но сложно написать, что ли, что «увы, вы нам не подходите»?
В целом, могу сказать, что с большинством собеседований мне везло. Либо контора сразу признавалась, что у них официально рабочий день 10 часов, либо — серая зарплата, дополнительного времени на них тратить не приходилось. Там, где доходил до тех. сцециалистов — получал оффер… или прокачивал собственный уровень, найдя пробелы в знаниях :))
Однажды мне выслали тестовое задание в стиле университетских методичек. Самого задания как такового не было, была последовательность шагов:
- Откройте Delphi
2-5. Нажмите сюда, сюда и сюда чтобы создать новый проект
6-10. Нажмите сюда, сюда и сюда чтобы бросить такой-то компонент на форму
И тому подобное.
Перезвонил, спросил в чем вообще заключается задание и как его делать C#-программисту. Сказали, что перезвонят когда сами уточнят. Не перезвонили :)
У java и javascript хотя бы синтаксис похожий (фигурные скобочки, например) :) А ведь еще любят путать 1С и C++...
Отличаются всё же. У одних скобочки фигуристые, а у других отступы в коде. ;-)
@ mayorovp >У java и javascript хотя бы синтаксис похожий
И первые четыре буквы совпадают. ;-)
Прихожу я туда, офис — 2 комнатки заваленные хламом. Усадили меня на стул в середине одной из них, почти как на утреннике в детском саду. Все 6 сотрудников фирмы: директор, сисадмин, тим лид и 3 разработчика сползлись на «собеседование», а еще, учитывая мой пол, это точно был цирк с неведомой зверушкой, девушкой-разработчиком. Дали задрипанную бумажку с куском кода и сказали найти 3 ошибки.
Я начала перечислять. Они:
— не, это ж тестовый пример, зачем тут соблюдать MVC (а то, что у меня кровь из глаз потекла от этого — ладно)
— не, представим что база подключается в другом файле (а где тогда подключение этого файла)
— не, подумаешь стили инлайном, что тут такого
— ээээ, ну может да, но мы не эту ошибку имели в виду.
Короче я нашла ошибок 10, и заданные ими 3 тоже))
Потом посыпались дополнительные вопросы, от всех, одновременно. Я даже остановила их и сказала, что не могу понять вопросы, произнесенные одновременно, давайте по очереди.
Вышла я оттуда с точным решением, что я туда не вернусь. А они позвонили и сказали, что я им подхожу. Так первый раз в жизни я отказала работодателю, а не он мне.
Мое последнее трудоустройство прошло слишком быстро. С понедельника по четверг обошел 4 компании, пригласили в 3. Одна из контор сделала 2 попытки переманить к себе предложив больше з.п. чем у конкурента. Я не согласился по двум причинам, хороший коллектив, удобно добираться.
На одном из собеседований, в конце, мне предложили решить задачу — поменять местами 2 переменные не создавая при этом третью. Я сразу ответил, что я сейчас не в состоянии решать задачи, т.к. мозг уже на грани кипения)) Мне ответили, что никуда не торопятся и могут меня подождать. Решил за 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 раза или более.
Разработчика нужно проверять, понимает ли он, как математика «ложится» на устройство компьютера, а не проверять на саму математику.
Разработчики должны создавать читабельный, производительный и масштабируемый код, а не наоборот.
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, т.к. с точки зрения ассемблера это наиболее логичное решение данной задачи:
b = a ^ b
a = a ^ b
b = a ^ b
А вариант со сложением приведёт к переполнению, это Вы правильно догадались.
Мне одному кажется, что в случае, когда мы используем не явно объявленный буфер, а вариант со сложением вычитанием, в памяти создается аж 3 (три) временных переменных (результатов сложения и вычитания), которые потом записываются в переменные, которые нами объявлены явно.
Вам кажется. Если не лень написать на C и дизаcсемблировать результат, то можете убедиться, что одни и те же регистры процессора будут использоваться вместо a и b.
А насчет «Если не лень написать на 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` любит и умеет, он этот пример знает в лицо. А если он привык рожать локальную переменную на каждый вздох — то пусть еще пойдет подучится.
А дальше — ну вот есть два взаимоисключающих флага, которые надо проверить — и ведь каждый раз глаза вытекают от монструозного `if` с 55-ю ветками.
Как говорят отдельно взятые дочери офицера, не все так однозначно: https://en.wikipedia.org/wiki/XOR_swap_algorithm#Reasons_for_avoidance_in_practice
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 для чисел и логики.
Хотя… Логику вашу понимаю, и если намекнуть собеседнику, что именно вы хотите проверить, то вполне. (Чтобы не принять задачу за очередную логическую задачку с неявно определенными допустимыми операциями, и не гадать, чего же от тебя хотят)
Этот пример невозможно забыть, если любишь изящный код. Локальные переменные, помимо прочего, досталяют проблемы некоторым 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, edx)?
Таким образом, вывод все тот же — с точки зрения производительности и экономии памяти/числа операций, задача имеет смысл, только если мы программируем на C/Asm для микроконтроллера,
а для всего остального оптимальным по совокупности причин будет именно заведение буфера (а также можно продемонстрировать и прокомментировать все возможные варианты).
Но что ожидается, когда эта или подобная задача задается кандидату, неясно.
Офис они поменяют. ;-)
Где я работаю уже 5-й офис за годы сменился. Начинали арендой пары комнат на заводе — тьма и ужас!!!
>Потом посыпались дополнительные вопросы
Меня в первом вопросе спросили — что такое «файнели»? — и я завис.
И когда меня стали подводить к правильному ответу, я понял, что спрашивают меня о «финале» ( так я про себя читал в книге слово «finally» ). :-0
Вывод — озвучивайте НОВЫЕ иностранные термины хоть как-то, а не только читайте глазами в книгах. :-)
Но, ничего — приняли. :-)
По моему опыту оценки компаний, куда я ходил на собеседования:
- организационный уровень компании. Eго видно по тем же деталям вроде стопки бумаги и карандашей в переговорке, обязательности HR и т.п. Чем больше компания, тем важнее этот параметр.
- ресурсы, которая компания тратит на HR. К примеру, марафонные собеседования в данном случае плюс — на вас тратят целый день ценного специалиста!
- технический уровень компании. Не нужно стесняться пособеседовать интервьювера — об используемых технологиях, о процессах разработки, тестирования и continious delivery (имхо, самое важное), о сложных задачах.
- отношение компании к персоналу. Внешний вид рабочих мест, кухни, качество воздуха...
Так все это знакомо. Сразу чувствуешь, что человек пишет о своем, о наболевшем.
Все было очень четко оговорено и прошло в итоге замечательно.
Были сложности:
Я был первый день в городе в котором собеседоваля. С самолета, не выспавшийся, в не очень презентабельном виде и с сумкой вещей. HR была в курсе ситуации и этот момент сразу был понят и забыт.
Четкие советы о том, как лучше идти в компанию и что они вообще хотят и прочее.
Удобное место, вежливый персонал в самом HR агенстве.
Само собеседование в компании тоже прошло отлично, но тогда у меня были странные ожидания «по жизни» и сам себе слил вакансию.
После этого когда искал работу не стеснялся звонить по разным вопросам трудоустройства и компаниях.Отвечали, консультировали. Впечатления — супер.
p.s Собеседовался на BI-разработчика в зарубежную компанию
Примерно в то же время ходил к другим HR-ам и вообще конторам. Позабавили ребята, которые хотели, чтобы я работал из дома, постоянно катаясь по городу при этом и собеседовали меня в какой-то столовой бизнес — центра. Я им за себя предложил рыночную зп, они так и не позвонили, хотя хотели сильно больше чем все остальные (обязанности)
Всякое бывает. В итоге меня опять же нашел HR, правда именно самой компании, а не агенства и вот я до сих пор работаю в ней, все отлично и с коллективом сошелся.
В общем ищите и найдете :)
Главное понять что собеседование это не допрос и тот кто тебя собеседует такой же разработчик как и ты.
Все собеседования были по скайпу на позицию системного инженера (вакансия была с релокацией)
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 };
)сколько минимум вы хотите денег
Я хочу зарплату как у Чубайса, но вряд ли вы готовы платить мне столько.
Моя ожидаемая зарплата зависит от того, какие обязанности и какая ответственность будут лежать на мне. Давайте сперва обговорим это, я присмотрюсь к вам, вы — к мне, и если мы друг другу понравимся, вы сделаете предложение, основываясь на моей ожидаемой полезности…
Тут просто. Кто первый назовёт цифру то и… проиграл. ;-)
Когда меня спросили — сколько ты хочешь? — я ответил, сделав паузу, — что знакомый программист подаётся в Норвегию и будет получать там столько-то.
— Эка, — сказали мне, — мы бы сами туда подались на такую зарплату то.
Но цифру моей зарплаты всё же первые произнесли они, в два раза большую чем я рассчитывал. ;-)
Кто первый назовёт цифру
Обычно я примерно знаю, сколько могут дать, а часто зарплатная вилка указана в объявлении. Но суть не в том. Я честно говорю: «Абсолютный минимум вот столько, но это при наличии многих других интересных мне бонусов». И даже список интересных бонусов перечисляю. А потом следует предложение в стиле «никаких бонусов не обещаем, но вы нам очень понравились, предлагаем вам зарплату на 10% меньше вашего минимума»…
1. Не перезвонить. (не)отписаться по результатам. Традиция, вызывающая глубокое недоумение у меня.
2. Вопрос об оценках. Некоторым нравится нанимать усердных рабов, причем сами наниматели(сотрудники коллектива) учились не на 5 и даже не на 4.
У них обязательно на это будет оправдание.
Ограничение по возрасту по тем же причинам и с теми же комментариями.
3. Некоторые люди не способны не протрепаться несколько часов только для того, чтобы высказать свое мнение, скорее всего не экспертное, при этом уже в начале разговора решив не брать человека. Затем следуют пункт 1.
4. Приукрашивание текущей ситуации в компании что может в будущем проявится в виде пустой траты времени для обеих сторон.
5. Странные понятия о ЗП сотрудника. Почему-то некоторые люди думают, что стаж работы должен сильно перевешивать вклад в работу и его результат. Групповое заболевание, ведущее к деградации.
На выходе имеем обычную картинку, люди воодушевленно говорят о команде, когда им предстоит лишь смаковать результат и много ноют, спихивают на других свои огрехи, когда спрашивают с них.
Собеседование собеседованием, а хотел бы почитать как самому отбраковывать собеседующих, сразу или на испытательном сроке.
Только мне после прочтения как текста, так и комментариев, показалось что уж сильно мы, господа и дамы, закушались?
Иногда тестировщикам задают вопросы как про JS, или C++ или SQL — чтобы… хоть как-то просеять, когда слишком много на одно место приходят. ;-)
Офер дали, но я отказался, после того как сходил на еще одно собеседование, где просто дали в руки железяку и спросили смогу «оживить», я сказал что смогу. И вот уже 4 года оживляю всякие интересные штуки.
А по заметку могу лишь сказать, что автору с его тонкой душевной организацией явно не повезло (10 мест за 10 лет, тому подтверждение). Проблема не в собеседовании.
Это просто СУПЕР. Каждый год менять офис! Завидую.
У меня на годы «на одном месте». ;-)
Если через год на работе становится грустно, может надо отрасль поменять? Мои старшие коллеги уже по 25 лет отработали и им все так же интересно и фонтанируют идеями.
Вот не могу себя заставить!
>если через год на работе становится грустно, может надо отрасль поменять?
Вместо того, чтобы уйти в новый офис, страну, работу, зарплату(!)… сочиняю как внедрить новое на одном и том же месте.
Завидую «летунам». ;-)
Возможно и есть. Но обычно проекты меняются часто и просто так «набивать отчётики» из одного в другом не получится. Меняются как технологии сборки, среды разработки, тестирования, библиотеки, фреймворки, языки и прочая и прочая…
Так что либо начинаешь осваивать новое и быстро — либо… становишься не нужен.
А так да — возможно и есть конторы…
Верно. Но сишники — они могли бы и 30 лет писать на С. ;-)
Это наверное исключение из правил.
Сейчас появляются люди которые на SQL пишут лет 20.
Это второе исключение из правил.
Есть и Java-программисты по 15 лет пишущие.
Это третье исключение из правил.
И всё. :-)
Вообще, если не хотите идти «с общим потоком», сделайте что-нибудь, чтобы вас заметили и вы не приходили на собеседование как очередной Вася Пупкин №123.
Мне как-то отказали в должности только потому, что «работник на эту позицию на работу должен приезжать на личном автомобиле, и этот автомобиль должен выглядеть респектабельно». Серьезно повысили настроение)
Что мы ненавидим в собеседованиях?