Comments 124
Два менеджера по персоналу — опытный и стажёр — сидят в офисе и обсуждают дела. Молодой достает огромную пачку резюме, штук 300:
— Мы должны просмотреть их все, чтобы подобрать кандидатов на эту вакансию.
Опытный хладнокровно берет у него пачку, делит ее пополам, одну часть — на стол, вторую — в корзину.
Молодой изумленно:
— А как же претенденты?!
Опытный невозмутимо:
— А зачем нам неудачники?..
Выбрасывать резюме запретили, но претендентов по прежнему слишком много, вот и отсеивают с помощью сверхсложных задач на первом собеседовании. Компании по прежнему не нужны неудачники.
вот вы будете смеяться, но увы.
я лет десять тому назад занимался собеседованиями (угу, молодой был, горячий).
Сейчас, оглядываясь назад, могу только сказать «все почти так».
Задавали алгоритмы, но реально нужно было 1-2 человека из 10, и нанимали не «тех кто решил задачку» — таких было много, а разбивали на группы по 5 человек и нанимали «тех, кто решил задачку лучше всех в его группе» + рассказал «почему оно работает» (ака софтскилл)…
Почему-то меня посещает уверенность, что на самом деле такое происходит и сейчас.
PS: зато треть нашего отдела были программистки!
PPS: собеседованиями я больше не занимаюсь ни как испытующий, ни как испытуемый.
я лет десять тому назад занимался собеседованиями (угу, молодой был, горячий).
Сейчас, оглядываясь назад, могу только сказать «все почти так».
Задавали алгоритмы, но реально нужно было 1-2 человека из 10, и нанимали не «тех кто решил задачку» — таких было много, а разбивали на группы по 5 человек и нанимали «тех, кто решил задачку лучше всех в его группе» + рассказал «почему оно работает» (ака софтскилл)…
Почему-то меня посещает уверенность, что на самом деле такое происходит и сейчас.
PS: зато треть нашего отдела были программистки!
PPS: собеседованиями я больше не занимаюсь ни как испытующий, ни как испытуемый.
Автор словно подсмотрел мой опыт и написал его так точно как только смог. Только в моём случае, устав от этих невероятное-резюме-давайте-поговорим-очное-собеседование-НЕТ, я вернулся к фрилансу, где, к счастью, всё ещё смотрят на достижения и рекомендации других заказчиков, а не на умение перевернуть список отсортированных гномиков.
P.S. На нескольких собеседованиях попробовал задать встречный вопрос из области "tell me about a time when you...". Все как один несли несусветную чушь, которая никоим образом не отвечала на поставленный вопрос. Это всё, что нужно знать про поведенческие (behavioral) собеседования. В следующий раз попробую задач встречный вопрос на алгоритмы.
«Шо, опять?!» (с) известный мультфильм.
(присаживается поудобнее в кресло-качалку, накрывается клетчатым пледом, наливает в кружку что-то горячее с молоком, отхлебывает)
А ведь я застал-с те времена, когда знание алгоритмов всяческих там сортировок, деревьев и прочих списков было обязательным, да-с…
Лет двадцать пять назад, когда программы были маленькие, а 640 килобайт еще многим хватало, я непосредственно и всегда использовал эти самые алгоритмы и структуры данных. В этом было целое искусство — как бы так написать, чтобы втиснуться в требования задачи…
Вся работа начиналась вот примерно с таких креативов
в тяжелых случаях вытаскивался препроцессор
На этом полет креатива не останавливался — появлялись mutex для параллельной работы, списки менялись на деревья и прочая, а для работы со структурами данных изобретался паттерн visitor в стиле «лямбд пока не завезли»:
Это сейчас за такое я джуновлуплю по рукам линейкой не одобряю, а тогда… тогда даже строки были квадратно-колесными, и в приличном проекте их было полдюжины разных. Роднило их только одно — все они умели в char*, а наиболее грамотные — еще и в const char*.
Это сейчас за попытку изобрести свой аналог std::string ваш лид спросит — в своем ли вы уме, а 25 лет назад он бы поинтересовался, как это удалось сделать copy-on-write и при этом работающую форму
Следом обычно шел кастомный аллокатор, современный tcmalloc() тогда тоже еще не завозили, и героическая борьба с memory leaks…
И вот когда я в очередной раз читаю проштурм вершин изучение алгоритмов для собеса, я вспоминаю эти уже далекие времена.
Вот честно сказать, если бы я в то время ушел «на руко-водящую работу», больше бы не программировал (ну кроме макросов в экселе), и мне бы вдруг! надо было бы отсобесседовать молодежь — я бы вспомнил именно про алгоритмы :-)
Ну, просто потому, что на «а вот тут у нас в шаблоне дуал байндинг», или «а тут я сделал автомаппинг дэтэошек на доменную модельку через аннотации», «а тут у нас стандартный рипазиторий», «а спрингбутовый тест я сделал через рест темплейт», я бы смог только выдавить «че?...»
А вот когда я грозно бы спросил про о-большое в случае реализации ArrayList на вставку в середине — я бы и произвел нужное впечатление на молодняк, и хотя бы смог бы понять их ответ :-)
(присаживается поудобнее в кресло-качалку, накрывается клетчатым пледом, наливает в кружку что-то горячее с молоком, отхлебывает)
А ведь я застал-с те времена, когда знание алгоритмов всяческих там сортировок, деревьев и прочих списков было обязательным, да-с…
Лет двадцать пять назад, когда программы были маленькие, а 640 килобайт еще многим хватало, я непосредственно и всегда использовал эти самые алгоритмы и структуры данных. В этом было целое искусство — как бы так написать, чтобы втиснуться в требования задачи…
Вся работа начиналась вот примерно с таких креативов
struct foo_nlist {
struct foo_nlist* next;
...
};
struct foo_nlist* foo_lookup(struct foo_nlist* root, ...);
struct foo_nlist* foo_insert(struct foo_nlist* root, ...);
struct foo_nlist* foo_remove(struct foo_nlist* root, struct foo_nlist* elem);
в тяжелых случаях вытаскивался препроцессор
#pragma pack(1)
struct nlist_header {
struct nlist_header* next;
};
#define DECLARE_LIST_ENTRY(foo_nlist_name, foo_type) \
struct foo_nlist_name { \
struct nlist_header header; \
foo_type value; \
}
struct foo {
...
};
struct bar {
...
};
#define TO_VALUE(header, foo_type) \
((foo_type*)((char*)(header) + sizeof(struct nlist_header)))
#define TO_LIST(value) \
((struct list_header*)((char*)(value) - sizeof(struct nlist_header)))
DECLARE_LIST_ENTRY(foo_nlist, struct foo) foo_root;
DECLARE_LIST_ENTRY(bar_nlist, struct bar) bar_root;
struct nlist_header* nlist_lookup(struct nlist_header* root, ...);
struct nlist_header* nlist_insert(struct nlist_header* root, ...);
struct nlist_header* nlist_remove(struct nlist_header* root, struct nlist_header* elem);
На этом полет креатива не останавливался — появлялись mutex для параллельной работы, списки менялись на деревья и прочая, а для работы со структурами данных изобретался паттерн visitor в стиле «лямбд пока не завезли»:
#define FOR_EACH_NLIST(foo_type, item, nlist) { \
for(struct nlist_header* hdr = (nlist); hdr; hdr = hdr->next) { \
foo_type* item = TO_VALUE(hdr, foo_type);
#define FOR_EACH_END() \
}\
}
...
FOR_EACH_NLIST(struct foo, foo_item, foo_root)
if (foo_item-> ..) {
FOR_EACH_NLIST(struct bar, bar_item, bar_root)
...
FOR_EACH_END()
}
FOR_EACH_END()
Это сейчас за такое я джунов
Это сейчас за попытку изобрести свой аналог std::string ваш лид спросит — в своем ли вы уме, а 25 лет назад он бы поинтересовался, как это удалось сделать copy-on-write и при этом работающую форму
str[n] = 'a';result = a + "\\" + b +"\\" + c + "." + d; Следом обычно шел кастомный аллокатор, современный tcmalloc() тогда тоже еще не завозили, и героическая борьба с memory leaks…
И вот когда я в очередной раз читаю про
Вот честно сказать, если бы я в то время ушел «на руко-водящую работу», больше бы не программировал (ну кроме макросов в экселе), и мне бы вдруг! надо было бы отсобесседовать молодежь — я бы вспомнил именно про алгоритмы :-)
Ну, просто потому, что на «а вот тут у нас в шаблоне дуал байндинг», или «а тут я сделал автомаппинг дэтэошек на доменную модельку через аннотации», «а тут у нас стандартный рипазиторий», «а спрингбутовый тест я сделал через рест темплейт», я бы смог только выдавить «че?...»
А вот когда я грозно бы спросил про о-большое в случае реализации ArrayList на вставку в середине — я бы и произвел нужное впечатление на молодняк, и хотя бы смог бы понять их ответ :-)
Все осталось… И велосипеды и прочее. Только применяется для всяких avr, stm и тд…
Это сейчас за попытку изобрести свой аналог std::string ваш лид спросит — в своем ли вы уме,
И вот тут у меня возникает вопрос — а как сейчас в эту строчку std::string помещают значение какой-либо переменной? Аналог sprintf, то есть. А то я по старинке sprintf использую до сих пор в таких случаях.
640 КВ? Да вы, батенька, зажрались. Мы писали систему сбора данных с датчиков, обсчета разных параметров и трехмерной эмуляции ядерной реакции в активной зоне (диффуры в частных производных), все в реальном времени, на 128 КВ — и там же работала ОС. В-)
std::stringstream ss;
ss << anything_you_want;
std::string s = ss.str();Все так же — кто во что горазд. Вплоть до сумрачных фантазий из 90х, типа такого
Да, второй вариант категорически неправильный. Но что с правильным?
str.reserve(1024);
...
sprintf(str.c_str() + ::strlen(str.c_str()), " %d %d:", i, j);str.reserve(1024);
...
str += " " + std::to_string(i) + " " + std::to_string(j) + ":";Да, второй вариант категорически неправильный. Но что с правильным?
std::stringbuf buffer;
std::ostream os (&buffer);
os << str << " " << i << " " << j << ":" ;
os.flush();
str = buffer.str();Спасибо!
Собственно, не просто так в 20-й стандарт добавили новую библиотеку для форматирования строк https://en.cppreference.com/w/cpp/utility/format
это как бы не сильно лучше :-)
Визуально хоть пытается выглядеть не ужас-ужасом, не?
Визуально хоть пытается выглядеть не ужас-ужасом, не?str.reserve(1024); ... str += " " + std::to_string(i) + " " + std::to_string(j) + ":";
Зато сколько тут копирований и вызовов небесплатного и недешевого аллокатора… вроде бы (вроде бы!) мы не должны за это все радостно платить, а по факту — ух!!!
Давайте попробуем удешевить.
str.reserve(1024);
str += " " += std::to_string(i) += " " += std::to_string(j) += ":";str.reserve(1024);
(((((str += " ") += std::to_string(i)) += " ") += std::to_string(j)) += ":");Не, в Java/C#
str = (new StringBuilder(N)).append(...).append(...).toString();Пайтонисты и дотнетчики пошли еще дальше — и у них в строчках прямо переменные указывать можно, типа такого
str += $" {i} {j}:";Вы спросите, так а чем не нравится путь комитета? Тем более stringstream завезли, стало чуть проще…
std::stringstream ss;
ss << << str << " " << i << " " << j << ":" ;
str = ss.str();Давайте вспомним, как часто и зачем нам надо в коде много форматирования? Вот именно, логи! И что, нам теперь по три строчки каждый раз вставлять, и плодить локальных переменных? Не, конечно можно… но лениво.
Неужели все так плохо?
По счастью, нет. В новейшем стандарте завезли std::format!
Что делать
#include <memory>
#include <string>
#include <stdexcept>
template<typename ... Args>
std::string string_format( const std::string& format, Args ... args )
{
size_t size = snprintf( nullptr, 0, format.c_str(), args ... ) + 1; // Extra space for '\0'
if( size <= 0 ){ throw std::runtime_error( "Error during formatting." ); }
std::unique_ptr<char[]> buf( new char[ size ] );
snprintf( buf.get(), size, format.c_str(), args ... );
return std::string( buf.get(), buf.get() + size - 1 ); // We don't want the '\0' inside
}И зачем я это все вспомнил -\_(o^o)_/-
std::string foo = "bar";
Аналог sprintf — std::format / fmt::format (лучше по всем параметрам).
А в std::format можно сделать простым способом вывод числа с n-дополненными нулями до запятой и m-цифр после запятой?
И тут уже писали, что это 20 стандарт.
И тут уже писали, что это 20 стандарт.
Если я вас правильно понял, то да: godbolt.org/z/37Y8Yh
fmt::format, на котором основывается std::format, доступен даже на древних компиляторах.
fmt::format, на котором основывается std::format, доступен даже на древних компиляторах.
Да, это именно то, что я и спрашивал. Спасибо! Посмотрю это вариант. Хотя вот тут была статья на эту тему. Там тоже в комментариях советуют fmt.
Вот честно сказать, если бы я в то время ушел «на руко-водящую работу», больше бы не программировал (ну кроме макросов в экселе), и мне бы вдруг! надо было бы отсобесседовать молодежь — я бы вспомнил именно про алгоритмы :-)
А почему, если вы сами же только что сказали, что сейчас это не нужно? Эффект утенка?
Он же написал — потому что сам бы не осознавал, что это уже ненужно (он много лет занят другим) ну и потому что в этом он (не реальный, тот, из примера) разбирается, а в современных реалиях разработки — нет.
Вот насчет «не нужно» — споры как раз и идут. Оно наверное все еще полезно, уметь в структуры данных, обычно это хэштаблицы-списки-кольца-деревья, графы уже сильно реже. Но это неточно :-)
Шутка в том, что я еще помню, как задача транспонирования матрицы занимала несколько суток, занимая при этом весь объем — нет, не тогдашней оперативы, а тогдашнего жесткого диска! и я тогда самолично изобретал — как это в почти 3 мегабайта кэша воткнуть работу с матрицей, которая сводится к треугольному виду методом Гаусса. Lookahead и вот это вот все, чтобы диск не трещал так жалобно своими головами.
Причем даже не «повысить перформанс», а потому что «в лоб» предыдущий диск за выходные сгорел. :-)
Уже в двухтысячных — такие матрицы просто помещались в оперативе, их сводили стандартным матпакетом или на пайтоне, и перформанс вообще никого не волновал.
Теперь сотни мегабайт воспринимаются как «лабораторная работа», тут вообще нечего делать. Что тут оптимизировать?..
Соответственно в мейнстриме и «тюнинг» структур данных и алгоритмов вокруг них — нет, не исчез! но сильно изменился :-)
Шутка в том, что я еще помню, как задача транспонирования матрицы занимала несколько суток, занимая при этом весь объем — нет, не тогдашней оперативы, а тогдашнего жесткого диска! и я тогда самолично изобретал — как это в почти 3 мегабайта кэша воткнуть работу с матрицей, которая сводится к треугольному виду методом Гаусса. Lookahead и вот это вот все, чтобы диск не трещал так жалобно своими головами.
Причем даже не «повысить перформанс», а потому что «в лоб» предыдущий диск за выходные сгорел. :-)
Уже в двухтысячных — такие матрицы просто помещались в оперативе, их сводили стандартным матпакетом или на пайтоне, и перформанс вообще никого не волновал.
Теперь сотни мегабайт воспринимаются как «лабораторная работа», тут вообще нечего делать. Что тут оптимизировать?..
Соответственно в мейнстриме и «тюнинг» структур данных и алгоритмов вокруг них — нет, не исчез! но сильно изменился :-)
Вот насчет «не нужно» — споры как раз и идут.
Не понятно, что тут спорить. В каких-то задачах — нужно, в каких-то — нет.
Самое бтв забавное тут то, что знание структур и алгоритмов весьма опосредованно помогает в решении всяких задачек.
и я тогда самолично изобретал — как это в почти 3 мегабайта кэша воткнуть работу с матрицей, которая сводится к треугольному виду методом Гаусса. Lookahead и вот это вот все, чтобы диск не трещал так жалобно своими головами.
Ну а сейчас эти 3мб надо упаковать в процессорном кэше ;)
Лет двадцать пять назад, когда программы были маленькие, а 640 килобайт еще многим хватало, я непосредственно и всегда использовал эти самые алгоритмы и структуры данных. В этом было целое искусство — как бы так написать, чтобы втиснуться в требования задачи…
И сейчас оно никуда не делось. Есть почти во всех Сишных библиотеках. Например, в ffmpeg этого добра навалом. Чтобы прикрутить более-менее сложную фичу, 20% времени тратишь на разработку, остальные 80% изучаешь особенности работы кастомных аллокаторов и контейнеров типа FIFO очередей. Потом обновляешь конфигурации в Makefile'ах.
Вкратце: получаешь незаменимый и нерелевантный опыт.
Маааам, дедушка опять забыл принять свои таблетки!
Господи, зачем я все это понимаю… ^_^
Хаха, готовился три месяца и думал, что готов к гуглособесу. Салага…
Странно, почему игра Жизнь оценивается автором так высоко; там же простейший цикл по клеткам минут за 10 пишется, в отличие от других упомянутых им алгоритмов.
У наивной реализации Жизни ужасная производительность
CUDA поможет с этим справиться. :)
Мне кажется, там линейная зависимость от числа клеток поля, и написать что-то с худшей асиптотикой — еще надо постараться. Или я не прав?
Я сомневаюсь, что на телефонном собеседовании хотели бы увидеть hashLife какой-нибудь.
Тупое наивное решение, которое работает, позволило бы пройти дальше. Там единственный спецэффект вокруг обработки границ может быть. Ну еще можно запутаться в 8 одинаковых кусках кода, если не додуматься до констант сдвигов dx и dy, или хотя бы двух вложенных циклов -1...+1.
Для сильного кандидата предполагается, что останется время пообсуждать, как это можно ускорить: Распараллеливание, векторизация, битовое сжатие всякие. Писать всякие хитрости тут 100% не требуется.
Телефонные собеседования имеют весьма низкую планку.
За гугл могу сказать что «планка» на телефонных интервью точно такая же как на onsite. (не путать с предварительным hr-скринингом) и критерии оценки те же самые. В которые, внезапно, софт скиллы входят в полной мере, просто оцениваются они опосредованно по результатам диалога в процессе решение. Ну и да, решение задачи как таковое — не самоцель.
За гугл могу сказать что «планка» на телефонных интервью точно такая же как на onsite
Не совсем.
Если вы проводите интервью в гугле — поищите "technical phone screen guide". Первая же ссылка будет содержать слова вроде "you would want to cast a wider net than during an onsite". Цель телефонных интервью — отсеять совсем слабых кандидатов. Поэтому планку там рекомендуется понижать.
Конечно, зависит от конкретного интервьюера, да и инструкции и реальность могут различаться на практике. Но предполагается, что TPS легче on-site.
UFO just landed and posted this here
Удивительньнее всего, что по таким собеседованиям кажется что там работают сверх люди.
Наоборот же, там работают люди, которые сами не прошли бы в свои критерии ;-)
Да ровно так же везде. Сначала на собеседовании тебя долго пытают пишите ли вы тесты, как пишите, почему пишите, что делаете чтобы писать лучше, а после найма выясняется что тесты в компании по древней легенде пишут 1.5 человека и никто не знает как их зовут.
Я тут недавно недавно запоем наконец-то проглотил «Мистера Робота». Сериал, конечно, потрясающий, но я сейчас не о том.
АХТУНГ!!! НИЖЕ СПОЙЛЕР!!!
Мне понравился комментарий одного обзорщика на ютубе, который «оборзел» некоторые самые популярные вопросы, которые возникают после просмотра сериала. Итак, вопрос: как же так, почему не заработало (и, судя по всему, и не должно было) титаническое устройство Белой Розы, на которое он и его соратники положили свои жизни и жизни кучи невинных людей? Ведь это был такой серьёзный суперпроект, которым занимались такие серьёзные люди!
А ответ прост. Это известное в психологии когнитивное искажение (которым, кстати, успешно пользуются мошенники на доверии): почему-то все уверены, что если солидное лицо, в галстуке, с умным выражением физиономии и не менее умными словами изо рта, да ещё и с правильной «корочкой», что-то делает — то это априори что-то очень важное, нужное, умное и куда уж туда нам, со свиным рылом в калашный ряд. А на самом деле, если отбросить галстуки и вот это всё — ведь это самые обычные люди в большинстве случаев, если не хуже (ну, может, чуть более наглые и самоуверенные). Которые, в полном соответствии со словами киношного Мюнхгаузена, с умным выражением лица постоянно творят несусветную чушь.
Так что поменьше верьте галстукам и баззвордам, it's a trap :))
АХТУНГ!!! НИЖЕ СПОЙЛЕР!!!
Мне понравился комментарий одного обзорщика на ютубе, который «оборзел» некоторые самые популярные вопросы, которые возникают после просмотра сериала. Итак, вопрос: как же так, почему не заработало (и, судя по всему, и не должно было) титаническое устройство Белой Розы, на которое он и его соратники положили свои жизни и жизни кучи невинных людей? Ведь это был такой серьёзный суперпроект, которым занимались такие серьёзные люди!
А ответ прост. Это известное в психологии когнитивное искажение (которым, кстати, успешно пользуются мошенники на доверии): почему-то все уверены, что если солидное лицо, в галстуке, с умным выражением физиономии и не менее умными словами изо рта, да ещё и с правильной «корочкой», что-то делает — то это априори что-то очень важное, нужное, умное и куда уж туда нам, со свиным рылом в калашный ряд. А на самом деле, если отбросить галстуки и вот это всё — ведь это самые обычные люди в большинстве случаев, если не хуже (ну, может, чуть более наглые и самоуверенные). Которые, в полном соответствии со словами киношного Мюнхгаузена, с умным выражением лица постоянно творят несусветную чушь.
Так что поменьше верьте галстукам и баззвордам, it's a trap :))
В статье обсуждается гугл… У них где-то утекал миллиард учетных записей? Ну или что-то типа того?
У Микрософта, когда-то были похожие собеседования. Попытался я перейти с Ёкселя 2003 на 2010. В логе с прибора десять столбцов примерно по 20000 точек. Десять графиков.
2003-й перерисовывает весь экран десяток раз (по числу графиков). 2010 — порядка 100( примерно n^2). Более двух минут. Это пусть и на стареньком, но i7. Куда, мать их, все эти чудо-алгоритмисты подевались?
2003-й перерисовывает весь экран десяток раз (по числу графиков). 2010 — порядка 100( примерно n^2). Более двух минут. Это пусть и на стареньком, но i7. Куда, мать их, все эти чудо-алгоритмисты подевались?
Ничего не могу сказать про microsoft. Возможно это издержки их stack ranking, который просто помножил на 0 все старания инжинеров.
Думаю не зря в FAANG нет буквы M.
Еще один все понял (с).
Автор конечно молодец, однако, как мне кажется, не до конца разобрался с тем как эти интервью все-таки работают. И возможно в этом и заключена его проблема. Задача на
этих интервью в большинстве своем просто повод поговорить, ее даже не обязательно решать до конца, чтобы пройти (более того, скорее всего она будет усложнена в случае успешного решения, так, чтобы человек не успел ее дорешать до конца) и автор очень зря считает что софт скиллы во время этих интервью не оцениваются. Возможно причиной отказа было не то, что алгоритм плохо получился, а как раз плохая оценка по софт скиллам. Есди автор во время собеседования угрюмо молчал, не шел на контакт с интервьюрующим, рассказывал какие все в текущей компании мудаки и он один в белом пальто стоит красивый, вполне… вполне вероятно что не прошел именно по софт скиллам. Именно потому что все работают в команде и это важно.
Плюс после изначального «телефонного» интервью в гугле и других подобных компаниях идет уже серия интервью пара из которых как правило чисто разговорные (ну там «дизайн» и «за жизнь» например). Но даже в чисто алгоритмических интервью в критерии оценки входит часть с «софт» скиллами. Даже в изначальном телефонном интервью.
Автор конечно молодец, однако, как мне кажется, не до конца разобрался с тем как эти интервью все-таки работают. И возможно в этом и заключена его проблема. Задача на
этих интервью в большинстве своем просто повод поговорить, ее даже не обязательно решать до конца, чтобы пройти (более того, скорее всего она будет усложнена в случае успешного решения, так, чтобы человек не успел ее дорешать до конца) и автор очень зря считает что софт скиллы во время этих интервью не оцениваются. Возможно причиной отказа было не то, что алгоритм плохо получился, а как раз плохая оценка по софт скиллам. Есди автор во время собеседования угрюмо молчал, не шел на контакт с интервьюрующим, рассказывал какие все в текущей компании мудаки и он один в белом пальто стоит красивый, вполне… вполне вероятно что не прошел именно по софт скиллам. Именно потому что все работают в команде и это важно.
Плюс после изначального «телефонного» интервью в гугле и других подобных компаниях идет уже серия интервью пара из которых как правило чисто разговорные (ну там «дизайн» и «за жизнь» например). Но даже в чисто алгоритмических интервью в критерии оценки входит часть с «софт» скиллами. Даже в изначальном телефонном интервью.
забавно, но я на таком интервью фактически до конца не решил ни одной задачи (правда, рассказал каким образом я бы их доделал если бы был поумнее время не закончилось) и был совершенно уверен, что интервью я с треском провалил, хотя с интервьюерами общение было довольно теплым и приятным. В любом случае опыт получился весьма интересным, я его положил в собственную копилку и успокоился. Каково же было мое удивление, когда через пару дней мне перезвонили и сообщили, что интервью пройдено успешно, при этом с неплохим(!) результатом. Что это было, черт возьми?! Как?!
К сожалению, сотрудничество в итоге так и не состоялось в силу иных причин, но о прецеденте до сих вспоминаю с улыбкой.
К сожалению, сотрудничество в итоге так и не состоялось в силу иных причин, но о прецеденте до сих вспоминаю с улыбкой.
Однажды собеседовал парнишку на его первый настоящий контракт. В тестовых заданиях последним пунктом шла задача на алгоритм, которую мы в принципе не требовали (важен был процесс мышления), тем более от джунов. Но он написал и так ладно объяснил, что хотелось посмотреть, до куда можно докопать. В итоге кучей дополнитедьных вопросов я его вывел на оптимизацию алгоритма. Когда я уходил из той компании он рассказал, что был уверен, что на моих вопросах засыпался и работа у нас ему не светит. А на самом деле ещё до конца интервью мы решили, что сорвали джекпот и дали добро на найм.
Мне кажется, что сейчас компании больше боятся нанять плохого кандидата, чем радуются возможности нанять отличного.
Парниша, об этом крупные компании во всеуслышанье заявляют! False negatives are okay. Вот ты гениален и тебя не наняли — и фиг с ним. Лишь бы не получилось false positive — когда ты бревно, а тебя наняли.
False negatives are okay.
Почему одновременно с этим все те же самые лица ноют (да, именно «ноют» и именно «все те же самые»), что специалистов всё сложнее и сложнее искать? Выглядит как методичный отстрел своей ноги с жалобами, что чё-то больно.
ну раньше они (те, которые ноют) были молодыми модными стартапами, а теперь свежие сверхумные ребята идут в свои стартапы (которые «внезапно» — другие компании). Понятно, что «это обидно» (сарказм моде офф)
К тому же в стартапы таки проще попасть.
UFO just landed and posted this here
Да пёс с ними, пусть ноют. Что нам, жалеть их, что ли? Кто бы мелкие компании пожалел, а эти как-нибудь уж проживут, можно не беспокоиться.
Я сам искал и сам ходил по собеседованиям. На одном, перед тем как собирались, я услышал разговор. Типа хотят найти спецов, но чтобы работали за морковку.
Я там не прошёл, там был завод. И мне уже потом рассказали. Пришёл чувак, начальник отдела, который рос с низов и его не взяли. Его просто по приколу притащили.
По мне, это моё личное мнение. Если человек может разобраться в новой теме и начать делать — ценнее, нежели гуру какой-то одной технологии, которая лет через 5 умрёт.
Интересный факт что большинство HR-щиков очень медленно читает. Часто даже не могут осилить и прочитать в резюме несколько связных предложений. Это странно.
Вывод — нужно меньше нервничать и просто делать свое дело (искать работу)?
Для тех кто видит себя на месте автора. Если вы умеете программировать и не комплексует быть нердом ботаном — идите во фриланс. Там это щедро оцениться звонкой монетой. После пары лет во фрилансе работа во всех этих компаниях будет казаться детским мышиной возней (чем она в общем то и является).
UFO just landed and posted this here
Ну нет же. Иначе из этих крутых лавок не выходила бы всякая говнотека ± среднего индусского уровня. Они не набирают самых крутых, они набирают квадратно-колёсных, подходящих для локального прокрустова ложа. В том то и дело, что реально уровень инженера оценивать не умеют / не научились / лень / etc.
из этих крутых лавок не выходила бы всякая говнотека ± среднего индусского уровняЭто вещи слабосвязанные.
Можно любого «крутяка» укатать, устрой ему кранчей на пару месяцев нон-стоп, «патамушта-бызнесь-хочет-вчера». И как инженер ни крут, а сидит и херачит по тикетам, с дейли митингами и ретроспективами. И каждый день оправдывается — почему не успевает.
И выбора у него нет — говнокод или говнокод :-)
А бывает еще круче. Бывает что саентисты по скраму должны выдавать прорывные инвеншены по тикетам (сам такое видел
Коллеги, вы упускаете еще одну большую брешь в собеседованиях — личность и амбиции того, кто собеседует. Эти люди тоже неидеальны, имеют свои страхи и гордость. Сколько собеседований было провалено, просто потому, что техлид побоялся взять человека, который, вероятно, лучше чем он сам. Из личных наблюдений — был на собеседовании, где последнее слово было за уже уволившимся сотрудником, который пообещал «помочь пособеседовать людей» после увольнения. Так этот сотрудник просто тешит свое ЧСВ без каких либо последствий для себя.
Это мало относится к гуглу, у гугла система такая что собесетуют «в общем», в гугл в целом. И вероятность того что собеседующий и собеседуемый хотя бы пересекутся впоследствии крайне, как говорится, мала. После успешно пройденного собеседования уже начинается собственно подбор команды. Ну на линейные позиции по крайней мере.
Хочу еще добавить, что в гугле решение принимает не один человек-интервьювер, а аж целый комитет, который читает отзывы интервьюверов. Я, как интервьювер, не могу сказать "не нанимать этого". Я должен сказать, "кандидат плохо программирует, потому что вот его код. Вот подсказки, которые я давал, но за 30 минут кандидат ничего нового не сделал". И так по нескольким критериям — все с обоснованиями. Конечно, есть возможность, что интервьювер выдумает весь отчет, чтобы провалить персонально противного ему кандидата, но это должно быть редкостью. И отчетов аж 4-5 штук для одного кандидата! Даже если один из них strong no hire, могут кандидата нанять.
Вот именно поэтому я сразу отказываюсь от всего процесса собеседований, если он предполагает домашнее задание, типа, "всего на день работы". Да пойдут они лесом.
Ваш подход — это примерно как при выборе жилья отказываться смотреть квартиру в доме, если вам не понравился цвет дверной ручки в подъезде.
У вас некорректная аналогия. Домашнее задание — это скорее уборка квартиры перед ее просмотром.
P.S. Не отказывался смотреть из вежливости, но заранее отбрасывал вариант если мне по тем или иным причинам не нравился подъезд.
P.S. Не отказывался смотреть из вежливости, но заранее отбрасывал вариант если мне по тем или иным причинам не нравился подъезд.
Тут смысл не в аналогии, а в том, что наличие/отсутствие тестового задания при приёме на работу вообще не имеет никакой корреляции с тем, хорошее будет по факту место или плохое. Это надо выяснять на собеседовании с непосредственным начальником и с потенциальными коллегами. А на тестовое задание внимание не обращать, по крайней мере, если оно не такое, что требует от вас реальных усилий и траты рабочего времени.
Если люди не ценят моё время, то это уже звоночек, что работать с ними может быть тяжело
Хз, если задание интересное — можно и сделать. Чисто по фану.
Ну, тут ведь ещё надо понимать, что дело было наверняка в Америке, автор наверняка просил хорошую зарплату и всем этим компаниям был нужен не ответ на вопрос «умеет ли он найти К-наибольшее значение в бинарном дереве», а ответ на вопрос «нужно ли нам нанять вот этого американца здесь и сейчас вместо трёх индусов или украинцев удалённо, даст ли он больший выхлоп для нашей компании, чем они?». И поэтому если он просто «да, смог» — то ответ на второй вопрос «он ничем не лучше других». Вот если бы он это смог за полторы минуты, или из 5-ти возможных вариантов сразу выдал лучший, или сослался на свою же статью с обзором возможных вариантов решения этой проблемы — вот тогда ответ был бы «да, этот лучше других, надо брать».
Кстати, вы упомянули Америку,
Это действительно правильный вариант действий при собеседовании?
я эмпирически пришел к такому выводу на собеседованиях в РФ, что надо не тупо решать задачу в лоб, а вести диалог по поводу её решения и вообще адекватности
интересно насколько такой подход применим за бугром
или сослался на свою же статью с обзором возможных вариантов решения этой проблемы
Это действительно правильный вариант действий при собеседовании?
я эмпирически пришел к такому выводу на собеседованиях в РФ, что надо не тупо решать задачу в лоб, а вести диалог по поводу её решения и вообще адекватности
интересно насколько такой подход применим за бугром
Это действительно правильный вариант действий при собеседовании?
Это скорее удачное совпадение, которое возможно, если у тебя таких статей за плечами тысяча и, конечно, невозможно, если их тупо ноль. Диалог о решении — однозначно лучше, чем молча тупить в пустой экран. Но хуже случая, когда ты всё-таки сразу пишешь лучшее решение :)
Такой подход из-за бугра и пришел.
Задачу «в лоб» кстати решать не то чтобы прям не надо. Зачастую наивная реализация очень быстра и дает правильную базу для дальнейшего конструктивного диалога.
Задачу «в лоб» кстати решать не то чтобы прям не надо. Зачастую наивная реализация очень быстра и дает правильную базу для дальнейшего конструктивного диалога.
дело было наверняка в Америке, автор наверняка просил хорошую зарплату и всем этим компаниям был нужен не ответ на вопрос «умеет ли он найти К-наибольшее значение в бинарном дереве», а ответ на вопрос… можно ли его отшить так, чтобы он не подал на нас в суд за дискриминацию по Х признаку
Очень занятно, было интересно почитать и подчеркнуть для себя что-то. Спасибо.
UFO just landed and posted this here
FAANG не могут взять всех, кто к ним подается, поэтому можно решать все на A+, и все равно получать отказы. Хотя задачки, которые они задают на интервью – иногда за гранью разумного, особенно с учетом временных ограничений и того, что интервью идут четыре-пять часов подряд, одно за другим.
С другой стороны, без кодинга на интервью не обойтись, потому что каждый второй кандидат – с роскошным резюме, увешан референсами и soft skills, но не может найти максимум в массиве.
С другой стороны, без кодинга на интервью не обойтись, потому что каждый второй кандидат – с роскошным резюме, увешан референсами и soft skills, но не может найти максимум в массиве.
И то и другое плюсую. Найди максимум в массиве, обойди js-объект и замапь одну структуру на другую — это реально надо спрашивать, ну должен ты это уметь. Но задачки на динамическое программирование, ну е-мое.
Вы просто поймите что эти задачи совершенно необязательно дорешивать до конца чтобы «пройти». Более того хороший интервьювер все равно будет модифицировать и усложнять условия таким образом чтобы вы ее не решили. Зато то, докуда вы дорешали, КАК именно вы это делали и вели себя в процессе (обосновывая какие-то логические выводы, проверяя граничные условия, задавая уточняющие вопросы, показав что вот в принципе так решать вот дорешал бы) — вот это важно.
Немного покритикую статью.
1) Сейчас на алгоритмических интервью в основном все-таки спрашивают задачи где надо придумать алгоритм (при этом можно не особо знать хоть какие-то алгоритмы вообще), либо «составить» эффективный алгоритм, благодаря знанию «алгоритма». Примерами здесь могут быть как раз та самая задача, упомянутая в статье про K-тый максимум (эта задача уже баян баянистый), который по сути опирается на знание работы быстрой сортировки. Либо, задачки на промоделировать что-то в лоб (только обойтись наименьшим количеством кода). Видел только один раз когда спрашивали написать почти напрямую алгоритм Дейкстры.
По поводу того, что задачу необязательно дорешивать: частично правда. Но нужно хотя бы словами успеть рассказать эффективный алгоритм.
2) Можно конечно бесконечно ныть, что алгоритмы не нужны. Можно попробовать их все-таки освоить (готовясь к интервью) и оглянуться на свой код, который когда-либо был реализован. Возможно, станет сюрпризом, что что-то можно было сделать проще, эффективнее, быстрее.
3) По поводу soft skills и behavior questions. В настоящее время рекрутеры снабжают информацией о базовых принципах компании. На каждый из этих принципов нужно подобрать (придумать в крайнем случае) историю. Встречный вопрос интервьюверу тут неуместен, так как он(а) не придумывал(а) историю, идя интервьювировать. В целом это несложное интервью, если готовы истории заранее. Главное распознать про какой принцип хотят поговорить интервьверы. Очень круто, если истории универсальные.
Мой опыт: 1 успешное собеседование в Яндекс, 2 успешных собеседования в Microsoft (Прага, Редмонд), 1 успешное собеседование в Google (Мюнхен).
1) Сейчас на алгоритмических интервью в основном все-таки спрашивают задачи где надо придумать алгоритм (при этом можно не особо знать хоть какие-то алгоритмы вообще), либо «составить» эффективный алгоритм, благодаря знанию «алгоритма». Примерами здесь могут быть как раз та самая задача, упомянутая в статье про K-тый максимум (эта задача уже баян баянистый), который по сути опирается на знание работы быстрой сортировки. Либо, задачки на промоделировать что-то в лоб (только обойтись наименьшим количеством кода). Видел только один раз когда спрашивали написать почти напрямую алгоритм Дейкстры.
По поводу того, что задачу необязательно дорешивать: частично правда. Но нужно хотя бы словами успеть рассказать эффективный алгоритм.
2) Можно конечно бесконечно ныть, что алгоритмы не нужны. Можно попробовать их все-таки освоить (готовясь к интервью) и оглянуться на свой код, который когда-либо был реализован. Возможно, станет сюрпризом, что что-то можно было сделать проще, эффективнее, быстрее.
3) По поводу soft skills и behavior questions. В настоящее время рекрутеры снабжают информацией о базовых принципах компании. На каждый из этих принципов нужно подобрать (придумать в крайнем случае) историю. Встречный вопрос интервьюверу тут неуместен, так как он(а) не придумывал(а) историю, идя интервьювировать. В целом это несложное интервью, если готовы истории заранее. Главное распознать про какой принцип хотят поговорить интервьверы. Очень круто, если истории универсальные.
Мой опыт: 1 успешное собеседование в Яндекс, 2 успешных собеседования в Microsoft (Прага, Редмонд), 1 успешное собеседование в Google (Мюнхен).
Позвольте спросить, в каком году было последнее собеседование в гугле например, я слышал тенденция в том, что получить оффер в гугле в 2010 и в 2019 например требовало несоизмеримых трудозатрат. Могу ошибаться.
Интервью, как описал apodavalov, было у меня в 2016 году.
Могу еще добавить, что в задаче на k-ый максимум можно было еще делать и piority queue, или даже какой-нибудь std::set, поддерживая в нем k элементов. Не обязательно знать QuickSelect. Бонусный вопрос был на распараллелить это и тут надо было придумать, как слить множество отсортированных списков побыстрее (опять применив priority queue). При этом доаются подсказки, которые не являются жирным минусом при оценке интервью.
По ощущениям, сейчас интервью проходят так же как в 2016. Только, может быть, добавилось немного болтовни на проверку soft skills.
Проходил интервью в марте 2019 в Google и Microsoft. Яндекс, Microsoft: начало 2017 года.
yadi.sk/i/Qni2rzVc7BG1sA — то, что я знаю для прохождения алгоритмических секций (возможно даже список еще не совсем полный).
yadi.sk/i/Qni2rzVc7BG1sA — то, что я знаю для прохождения алгоритмических секций (возможно даже список еще не совсем полный).
UFO just landed and posted this here
Как здесь уже упомянули, проблема в том, что на рынке избыток рабочей силы.
Поэтому вообще неважно, какие вопросы задавать, главное чтобы
1) Они выглядели как «конкурс» (формальное основание).
2) Они позволяли отсеять 90% кандидатов.
Поэтому вообще неважно, какие вопросы задавать, главное чтобы
1) Они выглядели как «конкурс» (формальное основание).
2) Они позволяли отсеять 90% кандидатов.
что на рынке избыток рабочей силы.
не на рынке, а у ворот топ-IT компаний
На рынке, на рынке.
Компания, которая не готова платить человеку достаточно денег для жизнедеятельности и расширенного воспроизводства — это не часть рынка, он её мгновенно решает. Она успевает как раз только немножко поныть о том, что «негде брать людей», подразумевая, что нет специалистов, согласных работать за еду и «большую честь».
А настоящий рынок — компании, которые платят люди достаточно денег для жизнедеятельности — в работниках буквально купаются, отсюда и такой отбор. И это не обязательно топ-ИТ, а любая такая компания.
Компания, которая не готова платить человеку достаточно денег для жизнедеятельности и расширенного воспроизводства — это не часть рынка, он её мгновенно решает. Она успевает как раз только немножко поныть о том, что «негде брать людей», подразумевая, что нет специалистов, согласных работать за еду и «большую честь».
А настоящий рынок — компании, которые платят люди достаточно денег для жизнедеятельности — в работниках буквально купаются, отсюда и такой отбор. И это не обязательно топ-ИТ, а любая такая компания.
это не часть рынка, он её мгновенно решает
А вы не забывайте что бОльшая часть рынка — это не чисто ИТ компании, где разработка софта это не основной вид деятельности, и «решать рынку» если она платит не как в FAANG там нечего.
Я работал в крупной международной корпорации, которая хоть и имела прямое отношение к IT но я не скажу чтобы прям сильно нуждалась в супер-специалистах, зарплаты там были чуть ниже рынка, проблемы с наймом даже миддлов — были, но из-за того что основой вид деятельности зависел от ИТ лишь коственно — это совершенно ни на что не влияло в её жизни
И именно такие компании задают «рынок», FAANG лишь небольшая его часть в глобальном масштабе, буквально это самая вершина горы, куда далеко не каждый пойдёт (я например, во всяком случае сейчас и линейным программистом)
люди отбракованные топами — всёравно кудато пойдут, а пойдут они в такие компании и у них свой «рынок», гораздо более крупный.
решение задачек разное бывает
тот же поиск дубликата — кто-то эн-квадрат сравнением кинется перебирать, кто-то отсортирует и найдет два подряд идущих одинаковых… а кто-то посчитает сумму по массиву, вычтет из нее n(n+1)/2 и сразу получит профит
как-то раз на собеседовании попросили сделать обработку пересекающихся курсов
думаете, скалярные произведения наше всё? да вот чёрта с два, нашим всем оказалось умение нагромоздить и сориентироваться в груде ифов!
как говорится, можно вывезти девушку из деревни…
тот же поиск дубликата — кто-то эн-квадрат сравнением кинется перебирать, кто-то отсортирует и найдет два подряд идущих одинаковых… а кто-то посчитает сумму по массиву, вычтет из нее n(n+1)/2 и сразу получит профит
как-то раз на собеседовании попросили сделать обработку пересекающихся курсов
думаете, скалярные произведения наше всё? да вот чёрта с два, нашим всем оказалось умение нагромоздить и сориентироваться в груде ифов!
как говорится, можно вывезти девушку из деревни…
Одна из лучших статей про собеседования (из-за второй части, там, где выводы).
И вот что подумалось.
Неужто ещё не придумали компанию, ноу-хау которой — антипаттерн типичног собеса? Которая могла бы проводить для других действительно качественные интервью? Понятно же, что сущестующие практики легко отсеивают действительно стоящих инженеров по рандомным критериям («спросили такой-то алгоритм, а я его как-раз вчера вспоминал»). Предварительный отстрел кандидата происходит после 1-2 случайных вопросов, которые, как верно заметили, редко встречаются в повседневной деятельности.
При этом куча действительно дорогих знаний и навыков (опыт, софт-скиллс, личная философия, мотивации и т.д.) просто как-будто не стоят ничего на собеседовании (но почему-то требуются при работе непосредственно на проектах: никто не хочет иметь просто болванчика по поиску деревьев, всем нужен самостоятельный мотивированный самообучающийся сеньор).
В других отраслях как-то с этим справлялись. Например, в советской авиации и космонавтике был хороший опыт по составлению экипажей, люди действительно рассматривались во всей полноте своих навыков.
Если уже заявляется, что самое главное в индустрии XXI века — это люди (логично, ведь экономика знаний), то почему до сих пор так топорно, рандомно их отбирают?
И вот что подумалось.
Неужто ещё не придумали компанию, ноу-хау которой — антипаттерн типичног собеса? Которая могла бы проводить для других действительно качественные интервью? Понятно же, что сущестующие практики легко отсеивают действительно стоящих инженеров по рандомным критериям («спросили такой-то алгоритм, а я его как-раз вчера вспоминал»). Предварительный отстрел кандидата происходит после 1-2 случайных вопросов, которые, как верно заметили, редко встречаются в повседневной деятельности.
При этом куча действительно дорогих знаний и навыков (опыт, софт-скиллс, личная философия, мотивации и т.д.) просто как-будто не стоят ничего на собеседовании (но почему-то требуются при работе непосредственно на проектах: никто не хочет иметь просто болванчика по поиску деревьев, всем нужен самостоятельный мотивированный самообучающийся сеньор).
В других отраслях как-то с этим справлялись. Например, в советской авиации и космонавтике был хороший опыт по составлению экипажей, люди действительно рассматривались во всей полноте своих навыков.
Если уже заявляется, что самое главное в индустрии XXI века — это люди (логично, ведь экономика знаний), то почему до сих пор так топорно, рандомно их отбирают?
Прочитайте вот этот мой комментарий если пропустили — habr.com/ru/post/512160/#comment_21881264
Оценивается и опыт и софт-скиллы и интервьюверы могут менять задачу в процессе, если видят что кандидат не справляется (хотя это и довольно серьезный сигнал) и интервью аж пять штук в том же гугле для того чтобы «случайно» после 1-2 вопросов не отстреливать и оценка результатов собеседования делается отдельными людьми, которые не встречались с кандидатом лично. В целом оно как-то работает. Оно настроено на найм крепких середняков, которые «могут копать», как выше заметили, а не рок-звезд и это в целом нормальная практика, рок-звезды плохо скейлятся.
Оценивается и опыт и софт-скиллы и интервьюверы могут менять задачу в процессе, если видят что кандидат не справляется (хотя это и довольно серьезный сигнал) и интервью аж пять штук в том же гугле для того чтобы «случайно» после 1-2 вопросов не отстреливать и оценка результатов собеседования делается отдельными людьми, которые не встречались с кандидатом лично. В целом оно как-то работает. Оно настроено на найм крепких середняков, которые «могут копать», как выше заметили, а не рок-звезд и это в целом нормальная практика, рок-звезды плохо скейлятся.
Sign up to leave a comment.
Пугающая антиутопия интервью для программистов