Comments 156
Помню однажды меня позвали в "mail.ru". Я пришёл, в надежде, что меня соблазнят чем-то интересным. Первым же вопросом было "Почему вы хотите работать в нашей компании?". Надо ли говорить, что дальнейшее общение не задалось?
Как я понял, у них, как и у любой другой большой компании, всё сильно зависит от отдела/подразделения в которое зовут. Мне попались очень адекватные ребята. Хорошо пообщались, узнал что-то новое и остались только положительные впечатления.
Частый вопрос. Раньше отвечал что-то конкретное. Сейчас честно говорю, что исходя из того, что происходит в жизни последние несколько лет, мне самому интересно узнать что же будет ещё через пару лет.
У меня было интересное: компания нашла моё резюме на hh, выяснили, что я работаю в одной компании с их бывшим сотрудником. Узнали у него мой email (он у меня уточнял, мне аж интересно стало), и прислали на него анкету начинающуюся именно с этого вопроса… Я до сих пор не знаю что это за компания была, но вроде даже мягко послал их им ответ, что так делать нехорошо.
Про способы поиска данных о кандидате нужно отдельно писать. Там свой большой и странный мир. Некоторые компании очень спорные вещи для этого делают.
В общем случае, все хотят побольше гарантий адекватности в долгосрочной перспективе. Но способы получения информации иногда приносят больше вреда, чем пользы. Некоторые явно спрашивают поручителя/рекомендацию. Некоторые лезут в соц.сети и начинают оттуда выгребать всё что могут. Кто-то начинает искать через знакомых, знакомых знакомых и тд. Кто-то всё сразу делает и хочет узнать о человеке всё. По мне так, это сомнительное занятие. Да хочется знать больше, но в рамках разумного. И лучше уж прямо у кандидата спросить всё что интересует, чем в КГБшника играть. В книге "Обнимите своих сотрудников" несколько интересных вещей по этому поводу написано.
Справедливости ради, Mail.ru уже от этого отучилось. Свой процесс найма они неплохо отдебажили.
Подобные проколы — личный косяк HR'а, и судить по ним о компании в целом, наверное, не стоит. Хотя неприятно, конечно, особенно если ты время потратил, приехал и выяснилось, что на вакансию обязательно нужен навык, которого у тебя отродясь не было и в резюме не указано.
Сильно от человека зависит. Кто-то на публике выступать может спокойно, а кто-то накосячит трижды в элементарном задании в риалтайме когда над душой неизвестный дядя стоит, но в более спокойной обстановке сделает всё как надо. Если уж давать риалтайм, то что-то очень простое на проверку базовых навыков и вслед за этим что-нибудь посложнее на 30-60мин для оффлайн решения. Тогда будет полноценная картина: навыки программирования плюс приспособленность к психологическим нагрузкам. Так в Microsoft было у меня.
Представьте что вам нужно сделать микросервис, который проводит сделки пользователей из трех различных регионов. У каждого пользователя есть некий баланс средств и он не может совершать сделки на отрицательном балансе. Для простоты сделка полностью проводится внутри микросервиса. Каждый пользователь прикреплен к ближайшему к нему датацентру и к одному из датацентров в качестве резервного. Необходимо сделать микросервис прототип, который позволит продолжить торговлю без остановок в случает падения одного из датацентров. Необходимо продумать все стресс сценарии когда могут возникнуть проблемы с расхождениями баланса и придумать пути их решения. Также желательно продумать схему масштабирования на большее число датацентров и возрастающие объемы сделок.
Да ладно, довольно интересное задание. Другое дело, что потратив кучу времени на его выполнение ожидаешь, что на приём тоже потратят достаточно времени, чтобы разобраться почему применяются те или иные решения. И уж точно не хочется слушать реплики в духе "мы решили вам отказать, так как ваше решение не является законченным продуктом и вообще не работает" из-за того, что приёмщик не смог без ошибок скопипастить строку вызова из документации.
Конфетно-букетный период
+1
не стесняйтесь задавать вопросы о причине отказа. В лучшем случае вы получите информацию для размышления и саморазвития, в худшем случае — не получите ничего и составите соответствующее мнение о компании
Из личного опыта, пару раз получал ответ в стиле «пока что проект заморожен, и вакансия закрыта», при том что я точно знал, что вакансия все так же открыта. Зачем HR'ам так тупо врать — до сих пор не понимаю, но, как говорится, «осадочек остался».
соискатели хоть и не получили приглашение на работу, но уходили абсолютно довольными
Аналогично, после первого собеседования (несмотря на то что оно было по телефону, без предварительной подготовки и довольно сумбурное), понял, где мое самое слабое место (как оказалось, это был английский), подучился, и в последущем все прошло как по маслу:)
Из личного опыта, пару раз получал ответ в стиле «пока что проект заморожен, и вакансия закрыта», при том что я точно знал, что вакансия все так же открыта. Зачем HR'ам так тупо врать — до сих пор не понимаю, но, как говорится, «осадочек остался».
Тоже такое бывало.
Причем даже в случае отказов бывало HR-ы могут написать, что-то «весёлое», а уж спрашивать о причинах можно только в исключительных случаях.
Из смешного запомнился кандидат, который спросил у нас зачем мы спрашиваем его про nginx, elk, linux.
-Ваши обязанности будут включать работу с web-серверами, вы текст вакансии изучали же?
-Я столько раз уже резюме своё рассылал, в каждой вакансии написано куча всего, все их читать что ли?
С собеседованием большого количества кандидатов та же фигня. Если нет HRа, просмотрев пару сотен резюме в лучшем случае об отобранных кандидатах можно запомнить только какую то одну яркую деталь, и то, если она была.
Какой-то дикий поток собеседований у вас. Честно не представляю больше одного хорошего интервью в день. Работу работать легче, чем так активно мозгом шевелить, как хотят на хороших собеседованиях.
Нашли меня в LinkedIn, пригласили на собеседование: " Приглашаем к сотрудничеству программиста/ведущего программиста .NET, в будущем руководителя отдела разработки...".
Собеседовали сначала по скайпу (сотрудник вроде как в командировке), что было несколько непривычно, собеседника я не видел.
Задавали вопросы — я отвечал, вроде всё хорошо прошло. Поговорили о проектах… У меня есть свой «домашний проект» который приносит мне некоторую прибыль и не отнимает много времени…
Потом подошел еще один сотрудник, задал несколько вопросов, пообщались. Я не настаивал на какой-то конкретно вакансии, более того, я сказал, что несмотря на имеющийся у меня опыт готов начать с просто программиста, чтобы узнать внутреннюю кухню и потом уже на что-то рассчитывать (у них и в настоящее время открыты вакансии, которые мне озвучили). Выказал свои ожидания…
В итоге сообщили, что через пару дней пригласят на повторное собеседование на котором конкретно договоримся по работе/деньгам…
Через несколько дней письмо от HR менеджера компании — отказ — что-то вроде " вы нам не подходите".
Хм, думаю, что… вообще? Попросил пояснить причину — уже 2 месяца тишина…
Вот, думаю, это нормальное поведение для приличных компаний?
Это личные домыслы или реальные случаи были? Просто очень интересно почему hr самостоятельно принимает такое решение, а не коллегиально вместе с руководством и прочими заинтересованными сотрудниками?
P.S. несостоявшийся начальник был поражен больше меня, особенно, когда ничего с этим поделать не смог.
Ну и что тут отвечать?
Хотел бы — а зачем ушли?
Не хотел бы — вы конфликтный человек?
Хм, а может это такой контрольный вопрос, чтобы избавиться от кандидата, по неизвестным причинам.
А может от вас хотели услышать рассказ о собственном росте в виде осознания проблем на прошлом месте, либо описание причин почему вы ушли оттуда и что нужно изменить, чтобы вы захотели там снова работать и ещё много различных "может"...
— Почему ушли?
— Работы было много
— А вам значит надо, чтобы работы было мало?)
В двух словах и не объяснишь, почему считаешь что много и сколько это вообще. Но потом я придумал хороший ответ. Я говорю: «А вы считаете, что работы много не бывает?)». И обычно сразу всем всё становится понятно.
Сначала было интервью по скайпу, потом личное (пришлось ехать из другого города). В результате мне позвонили и предложили оффер. Я взял время на то, чтобы подумать и пройти оставшиеся запланированные собеседования. Договорились, что я постараюсь побыстрее закончить собеседования и что они мне перезвонят через неделю. Через неделю не перезвонили. И чрез 2 тоже. Достучался я до них только через месяц, когда уже свернул все другие предложения, и узнал, что мой оффер отклонен.
Получается, они обнадежили меня оффером, заставили завершить остальные собеседования, после чего целый месяц динамили, поленившись хотябы сообщить, что мою кандидатуру больше не рассматривают.
Только мне не нравится, когда мне не могут озвучить мой оклад при работе у них.
Когда HR-ам задаешь вопрос про оклад, они отмалчиваются. А потом при личной встрече называют смешные суммы.
Вакансии без вилки зп — это совсем неприлично. Такое, обычно, делают либо те, кому стыдно показать реальную вилку, но нужно любым способом найти сотрудника, либо большие компании, про которые все и так знают что окладом не обидят и у которых реальный разброс окладов для одной и той же должности может быть очень большим.
По личному мнению, оптимальное количество собеседующих — двое. Первый — непосредственный руководитель, второй — hr.
То есть если высокоуровневых руководителей на интервью пускать нежелательно, то первые две ступени руководства там быть просто обязаны.
Так сколько руководителей-то надо в итоге?
Обычно же собеседования идут в несколько этапов. Я как раз их имел в виду. На технической части собеседования (обычно это первые этапы) достаточно пригласить непосредственного руководителя. Хотя, чаще всего, он и проводит собеседование. На финальной части, когда технические вопросы выяснили и все всеми довольны, хорошо бы привлечь руководителя на одну ступень выше.
Для SQL, у меня, например, есть задача, которая проверяет большинство основных принципов языка при помощи одной таблицы с одной колонкой. Людям нравится, особенно когда объяснишь назначение задачи.
Можете озвучить задачу и её назначение?
Озвучил в личку. Назначение простое: быстро понять на сколько соискатель знает SQL (умеет "думать на нём" и умеет его применять).
Можно мне тоже? Интересно посмотреть :)
Выкладывайте уж в открытую :-) Хорошая задача так и так по рукам рразойдётся.
select distinct author from ( select book from author_book group by book having count( author ) > 1 )
Правильный ответ?
Хотя на графе запрос по проще будет:
select distinct( author ) from books where authors.length > 1
А что не так?
create table author_book (author varchar(100), book varchar(100));
select distinct author from ( select book from author_book group by book having count( author ) > 1 );
SELECT DISTINCT author FROM books WHERE book IN (SELECT book FROM books GROUP BY book HAVING count(author) > 1);
Результат вроде верный получается, но наверняка есть более красивое решение
Из моего опыта:
9 Лет опыта в Angular.js в требованиях
2 года опыта в Angular.js 2 в требованиях.
Так же очень низкие зарплаты для фулл стека (под 20 вакансий) порядка 8кРублей
На том же сайте junior angular/node.js/php за 15 килорублей без опыта.
Во время собеседования:
Почему мы должны взять вас? На собеседовании на фулл стек 12кРублей.
Ответ: Я единственный кто пришел на собеседование. Потом взял и вышел. Позвонили и получили отказ.
"Чем отличается класс от структуры?" из собеседования к Node.js.
"Как объявить глобальную переменную в Node.js?" Ответил через global. Отказали сказав что через windowS (Именно с С в конце)
И многие глупые вопросы.
У меня пару раз были собеседования где про С# собеседовали с++ники, не имеющие понятия про сборку мусора и освобождение памяти в шарпе. Для себя решил, что в следующий раз так и скажу — давайте меня будет собеседовать специалист по требуемой технологии, а не черти-кто. Лучше пойду на конфликт, чем буду тратить свое время.
«Сколько будет 2^8?»
Этот вопрос проверяет навыки возведения в степень в уме, или кандидат должен помнить таблицу степеней двойки?
Вот даже не знаю что он должен проверять. Но у меня сразу же начинается подозрительное отношение к программисту, который за 2-3сек не может выдать ответ. Скорее всего это обусловлено тем, что при наличии хоть какого-то технического образования и/или после прочтения хотя бы пары книжек по алгоритмам, теории программирования, архитектуре ЭВМ и им подобным, степени двойки запоминаются сами собой.
Помню случай в институте был. Пара какая-то была, кажись по общей алгебре. Что за задание было уж не помню, но суть в том, что нужно было степени чисел записывать и что-то делать на их основе. Вся группа хором диктовала степени двойки до 2^15… а потом то же самое попросили для тройки: все дружно поплыли после 3^4, а преподаватель бодро продиктовал до той же 10 или 15 степени. Так что это, можно так сказать, отличительная черта IT-шника, приобретаемая автоматически.
степени двойки запоминаются сами собой.
У меня они не запомнились. Увидев этот вопрос я стал в уме высчитывать степень двойки, примерно так: 2^3 = 8, значит 2^4 = 16, и 16 * 16 = 256
Но большинство читало книги, связанные с их профессиональной деятельность. Вуз — необязательный атрибут и не только из него такое знание может получить. У меня, например, из сравнительно недавно изученного: What every programmer should know about memory и русский вариант. Степени повсюду. Если вдумчиво читать, то запомнятся сами собой… нет от них спасения и в голове они жить будут всю профессиональную жизнь.
Это выступление — хороший пример:
- Как делать не надо.
- Как под использование какой-нибудь фичи за уши притягиваются примеры.
- Многим, кто пытается учить других, не хватает системного взгляда на то, чему они учат.
- Многочисленным конференциям не хватает рецензирования, а то иногда такую чушь порят, что уши складываются.
Похоже я промахнулся веткой. Это ответ на этот комментарий: https://habrahabr.ru/post/314654/#comment_9900130
Решить можно вообще не возводя в степень и не помня точно таблицу степеней двойки. Лично мне как-то накрепко запомнилось, что 2^10 примерно равно 10^3, а значит точно равно 1024; отталкиваясь от этого факта и зная как вообще работает возведение в степень, разделим 1024 на 2 и еще раз на 2 :)
Писать код на листочке перестал просить с момента как менеджер сообщил после интервью, что «если после исправления ошибок компиляции заработает — то возьмём» и, что ожидаемо, нормального программиста не взяли.
Решить можно вообще не возводя в степень и не помня точно таблицу степеней двойки. Лично мне как-то накрепко запомнилось, что 2^10 примерно равно 10^3, а значит точно равно 1024
Ну тогда надо вспомнить, что 2^10 примерно равно 10^3, что равносильно "помнить степени двойки"
А мне вот код на листочке писать проще, чем возводить 2ку в степень. Я безнадёжен?
А фронтенд, нынче, за разработчиков не считается и базовой компьютерной грамотности обучен быть не должен? Не понимаю я вас.
А можете описать случай, когда бэкендеру нужно это помнить?
Это выступление — хороший пример:
- Как делать не надо.
- Как под использование какой-нибудь фичи за уши притягиваются примеры.
- Многим, кто пытается учить других, не хватает системного взгляда на то, чему они учат.
- Многочисленным конференциям не хватает рецензирования, а то иногда такую чушь порят, что уши складываются.
ибо это ограничение на однобайтовое беззнаковое целое.
У опытного разработчика должно отскакивать от зубов не задумываясь.
Если человек пишет на языке высокого уровня, то какое ему дело до того, сколько там чисел можно одним байтом записать? Он может что в целом это равно двойке в степени n, где n — кол-во битов. Но зачем ему помнить, что 2^8 = 256, а не 512?
Вы множеством комментариев упорно стараетесь отрицать основополагающие вещи. Если вы пишете на чём-то высокоуровневом и считаете себя хорошим программистом, то обязаны знать нижележащий слой: как он выглядит, как работает, какие особенности. А то с таким подходом уж столько безобразия натворили люди. То кто-то не в курсе про GIL и свято верит в "натуральность" многопоточности, то бездарно берёт bigdecimal и прочие надстройки для длинных чисел и хранят там значения от 1 до 100, а потом удивляется: "чего это всё тормозит и памяти много куда-то уходит?!".
В программировании фундаментальные знания — это теория плюс низкоуровневая реализация. Без этого из джуниора не вырасти никогда. Если вы отрицаете это и считаете что уровень языка освобождает от необходимости знать как там всё устроено, то я вам сочувствую.
Так знание основополагающих вещей — это помнить степени двойки? Программист, который будет думать, что 2^8 = 512 хуже? Я не понимаю как знание конкретного числа коррелирует с остальными вещами.
> В программировании фундаментальные знания
Фундаментальные знания — это не знание цифр, а понимание как все работает.
> Если вы отрицаете это и считаете что уровень языка освобождает от необходимости знать как там всё устроено
Я нигде этого не отрицал, я лишь усомнился в том, что необходимо помнить степени двойки :)
Программист, который будет думать, что 2^8 = 512 хуже?
А программист, который будет думать, что 2*2 = 5? Или что pi в военное время равно 4? Правильно, зачем нам математика, компьютер сам посчитает.
Фундаментальные знания — это не знание цифр, а понимание как все работает.
Вычисление 2^8 связано со свойствами двоичной системы. Двоичная система — это фундаментальные знания для программиста. Так же как знание десятичной для всех остальных специальностей, связанных с расчетами. Возьмете на работу бухгалтера, который не может посчитать, сколько будет 10^8?
я лишь усомнился в том, что необходимо помнить степени двойки
Мне кажется, в том и дело, что это не обязательные знания, которые требуются каждый день. Но если человек «в теме», это запоминается — из статей, книг, или примеров при изучении программирования. Поэтому и вывод — раз знает эту мелочь, значит имеются и более нужные знания.
Этот человек очевидно не знает как умножать. Это заставит задуматься. А вот, если он не будет помнить, что 9 * 9 = 81 и начнет это считать, то у меня не возникнет вопросов.
> Вычисление 2^8 связано со свойствами двоичной системы. Двоичная система — это фундаментальные знания для программиста.
Как и 2^16, 2^24, 2^32, 2^64, 2^128… Вы помните чему равны степени двойки? В какой момент какая конкретно степень двойки становится «обязательной» для знания хорошим программистом?
> Мне кажется, в том и дело, что это не обязательные знания, которые требуются каждый день.
Да, именно поэтому они и забываются. Я вот после этого спора запомнил 2^8 и 2^10, но, возможно, через год уже не вспомню и придется в уме считать.
> Поэтому и вывод — раз знает эту мелочь, значит имеются и более нужные знания.
Может ли быть так, что требуя от человека знания чему равно 2^8, вы отсеете много таких людей, кто в силу каких-то обстоятельств это не запомнил, но во всем остальном является хорошим разработчиком?
Требовать помнить значение степени двойки — это как требовать помнить наизусть какой-нибудь метод из библиотеки языка, который еще и не используется никогда.
А вот, если он не будет помнить, что 9 * 9 = 81 и начнет это считать, то у меня не возникнет вопросов.
Ну, удачи вам с бухгалтером.
В какой момент какая конкретно степень двойки становится «обязательной» для знания хорошим программистом?
В тот момент, когда число бит в общепринятом байте меняется, степень двойки равна этому числу. Сейчас везде применяются 8-битные байты. Здесь вам правильно написали. Это же к вопросу «который еще и не используется никогда».
но во всем остальном является хорошим разработчиком?
Мне сложно представить хорошего разработчика, который не знает, что такое байт и сколько в нем возможных значений.
А вы, кстати, чем занимаетесь, можно ли где-то ваш код посмотреть? Может вы действительно хороший разработчик, и я не прав.
Мы обсуждаем, случай, когда разработчик знает, что в байте 8 бит и 2^8 значений, но не помнит чему равно 2^8. Именно об этом весь этот тред.
2^18 я тоже сходу не назову, но не знать 2^8 выглядит странно.
Я, например, в своей карьере чаще сталкивался с ограничениями 4 байтовых чисел (поскольку они реально используются в языках и СУБД, которые я использую), чем с 1-байтовыми.
В любом случае, это не единственный критерий, и к тому же можно просто посчитать в уме. Уж это-то хороший разработчик должен уметь)
Может потому, что для многих эта фича является источником проблем?
А что там получается, если выпилить GIL? Другие языки как-то живут без него и ничего, справляются.
https://docs.python.org/2/library/struct.html
Тут указано, что вы можете закодировать один байт знаковый или беззнаковый. Нигде не указано, что при этом вы можете закодировать число до 127 или 255 включительно (хотя иногда в таких случаях указывают), потому что подразумевается, что для любого разработчика это очевидно как божий день.
Я уж молчу о C++, который вообще говоря высокоуровневый и char там никто не отменял.
Почему-то подумал, что вопрос с подвохом, и нужно спросить, не XOR ли имеется ввиду.
Часто спрашивают типичные задачи на логику, и всех компаний они почти одинаковы и которых полно в гугле. Один раз сказали собирать кубик Рубика и я совсем не понимаю зачем все это и как это поможет делать интерфейс на реальном проекте.
Когда искал разработчиков, придерживался принципа "всем писать реальную причину отказа". Проверял тестовые задания, писал список огрехов и присылал тем, кто не подходит. Это же очень круто когда тебе аргументированно указывают на твои ошибки.
В ответ 90% людей писали оскорбленные злые письма в стиле "Дурачек что ли? А что ты хотел от тестового задания? Я же делал его кое как. Это же тестовое задание. Но в реальности то я делаю гораздо круче.".
Через 2 недели выгребания помоев и личных оскорблений из почты, перед тем как отправить фидбек, задумываешься: "А может просто написать ему формальную отписку и все?".
Не повезло как-то вам с соискателями… а может вы слишком критично изъяснялись?
Я, обычно, в тестовом задании пишут как тут должно было быть (и, иногда, сколько нужно на это времени), если бы это нужно было для продакшена (или если за это достаточно заплатят). В итоге, получается эдакая демо-версия. С одной стороны имеем умеренные трудозатраты в рамках тестового неоплачиваемого задания, а с другой стороны видно, что не только "накаленочные" решения подразумеваются и человек понимает ограничения и пути улучшения архитектуры.
Вы прямо заинтриговали! Что же это за специалист такой? Как должность называется, если не секрет?
Есть автомат который выдает сдачу из имеющихся у него монет.
Написать алгоритм который будет возвращать сдачу минимальным количеством монет.
Интересно то, что у меня было 4 собеседования подрят с разными людьми и два из них задали эту задачу. Задачу я решил, но позже, в спокойной обстановке.
Интересно что крупные компании типа Амазона, не объясняют что именно было не так, просто отказ и все.
Первые же вопросы — с трудом дотягивают до теста джуниора.
Кого мы собеседуем? Зачем нужно тщательно собеседовать каждого интерна, если проще это сделать на испытательном сроке? Для первичного отбора, для интернов-джуниоров будет достаточно пробраться через гуманитарный барьер сотрудниц отдела HR, чтобы попасть на техническое интервью.
Для сеньоров задавать вопросы типа сколько будет 2^8 степени?…
Проще сразу взять реальные задачи из проекта, возможно даже прошлые уже решенные проблемы и попросить предложить гипотетическое решение, а главное обосновать.
Не спорю, сумбурно и местами в кучу навалено. Но если раскладывать по полочкам, по полочек будет много, а лежать на них будет мало и часто будут пересечения. Поэтому решил всё одной "портянкой" написать. Суть мне видится именно в озвучивании этих пунктов, а определение целевой аудитории для их применения решил оставить на откуп читателя. Поэтому да, извините за сумбур.
Я вот совершенно согласен, что если программист редко навскидку скажет что такое ^8 или ^12, то просто знать вплоть до 65536 и уметь быстро просчитать 8 или 12 степеней в уме должен любой джун.
Не забывайте, что по закону, ушлый перец может к вам устроиться, если докажет слабую мотивировку отказа. И снять с компании тыщ 300 за время испытательного срока, откуда его тоже не так-то просто уволить.
Конечно, такая фишка в основном действует для высокооплачиваемых топ позиций, но кадровики правильно делают, что перестраховываются.
Так вот откуда ноги растут....
Ведь раз есть требование, что мотивировка отказа должна быть быть НЕ слабой, то, когда нет отказа, требование не выполнено. Когда нет мотивировки в отказе — требование не выполнено.
Тоесть, такая перестраховка кадровиков не обеспечивает выполнение требования, и должна приводить как раз именно к тому самому сценарию, от которого они страхуются.
Обидно, что у таких фидбэк от тех спецов далее hr не уходит.
В дцатый раз про собеседования