Комментарии 78
Кто-то ещё в Яндекс идёт?
Ну вот! Спалила тему! ))
я очень обрадовалась
Я просмотрела
Автор: JShipov
Хм.
https://github.com/JShipov вроде как, Лиля
Женщина или мужчина, какая разница то вам?
И зачем это все? Вопрос риторический, но всё же.
Программисты никому не нужны, а нужны разработчики. Если ты бэкендер на джаве и не умеешь работать с Кафкой и Кубером, то будь хоть чемпионом Литкода, работу не получишь
И зачем это все? Вопрос риторический, но всё же.
Могут себе позволить отсеять хороших разработчиков, т.к. поток большой
На таких объемах пользователей, запросов и кол-ва данных, какие есть у яндекса, умение на практике реализовывать оптимальные алгоритмы намного большую важность имеет, чем в мелких конторах, где квадратную сложность на типичных рпсах будет не видно
Это не оправдание яндекса, потому что процесс найма ужасный. Пока ты все этапы пройдешь, в других местах тебе уже офферов накидают.
Вероятно, это можно сделать иначе и без насилия над разработчиком, но т.к. поток людей большой, то так проще и работает приемлемо.
Из заголовка могло показаться, что в процессах что-то изменилось и статья именно об этом, но оказалось что не поменялось ничего.
Если ты бэкендер на джаве и не умеешь работать с Кафкой и Кубером, то будь хоть чемпионом Литкода, работу не получишь
Ну зачем такая дихотомия? Это ведь не исключает друг друга. Можно быть и чемпионом литкода и уметь работать с кафкой и кубером. Плюс в некоторых областях кафки или кубера может и не быть. Может быть не на джаве, но всё же.
Если ты бэкендер на джаве и не умеешь работать с Кафкой и Кубером, то будь хоть чемпионом Литкода, работу не получишь
Сразу скипаю вакансии, где пишут про конкретный стек и ищут code-monkey под него, а не разработчика, который в принципе всегда сталкивается с чем-то новым. А это новая мода на бекендера вешать задачи девопса, но не добавлять к зп... Какой-то совиный грипп что ли?
Мне пригодился бы хороший программист на Java, даже если он не умеет работать с Кафкой и Кубером.
На моем проекте их все равно нет, да и не нужны они в разработке плагинов для IDE.
И Кафка и Кубер осваиваются ну за месяц наверно. На уровне обычного разработчика который использует ваш уже написанный код и что-то строит дальше. Если разработчик получше или ваш код получше, то и пары недель хватит.
А вот умение писать на Джаве с какими-нибудь приколами вроде отладки многопоточки или отладки распределенных систем и реальный опыт из этого получать надо получать годами.
Так что берем просто хороших разработчиков. Из технологий требуем только то что все работавшие должны знать. SQL, Spring и наверно все. Запрос с джойной и групбаем написать может? Как работают бины в общих чертах представляет? Ну и хорошо, дальше проверяем что код писать умеет.
И Кафка и Кубер осваиваются ну за месяц наверно
А вот умение писать на Джаве с какими-нибудь приколами вроде отладки многопоточки или отладки распределенных систем и реальный опыт из этого получать надо получать годами.
Тут вроде про литкод речь. Он за тот же месяц осваивается. И многопоточка осваивается, если каждый день сталкиваешься. Не за месяц, но в близкой перспективе.
Абсурд же в том, что есть всё это множество навыков разработчика, но всех интересует конкретный один - и при этом даже не прикладной.
Он за месяц осваивается или очень способным человеком, или если это скорее в рамках повторения уже имевшихся знаний. Среднестатистический разраб за месяц стабильно решать задачи уровня medium не натренируется. Не говоря о харде.
Кафка с Кубером за месяц тоже далеко не на 100% осваиваются. Но достаточно для работы. Литкод нет смысла задрачивать до харда, если задача пройти собес и забыть этот невероятно полезный навык. А в этой ситуации месяца хватит, особенно если без работы сидишь.
Кафка с Кубером за месяц тоже далеко не на 100% осваиваются.
А что нужно знать про Кафку и Кубер разработчику? То есть, тому, кто их использует, а не администрирует (устанавливает/настраивает).
Предположим, что разработчик знает про Очереди и Контейнеры. Если собрать всю требующуюся ему информацию о Кафке или Кубере в один документ, какого объёма документ получится (1 час/10 часов/100 часов)?
Иногда все "администрирование" заключается в том, что вам просто сообщают, где развернуты эти сервисы. Дальше разработчик сам. Насколько ты понимаешь, что делаешь, - так оно и будет. Я не говорю, что это классно и правильно, но так бывает. В часах не считал, но не все всегда получается хорошо слёту. Люди вон целые статьи пишут, как они по подводным камням бродили.
С другой стороны если вы в бигтехе работаете, то у вас там вся кафка это какой-то интерфейс с 2 функциями send и receive, который написала команда платформы. Тогда и 5 минут хватит, чтобы "кафку освоить".
удалил дубль
Какая разница между программистом и разработчиком? В каких книгах почитать?
С шарпами такая же ситуация
Уже никто из уважающих себя разработчиков не идет работать в яндекс. А что там делать? Зп низкие, а требования очень высокие, при этом работать там надо на 200%. Тот яндекс который когда то был, куда все хотели попасть ради отметки в трудовой, что ты работал в Яндексе, после чего тебе все двери были открыты, такого уже давно нет.
Мне они постоянно спамят во все мессенджеры, с предложениями по работе, отказов не понимают, даже грубых. Что говорит о явном дефиците кадров.
Если тебе хорошую зарплату не предложили, мб дело в тебе, а не в Яндексе?:)
Подтверждаю предыдущего. ЗП ниже рынка
Тогда зачем спамить?
Если тебе хорошую зарплату не предложили, мб дело в тебе, а не в Яндексе?:)
А если хорошую зарплату предложили все кроме Яндекса, то дело наверное в Яндексе.
Ну это же чистой воды демагогия. Где цифры? Я вот захожу на levels.fyi и вижу, что у Яндекса средняя зарплата на том же грейде выше, чем в Сбере, вк, озоне, wb...
Смотрю к себе в кошелек и вижу там зарплату выше рынка.
А потом захожу в комменты на Хабре и тут мне сообщают, что я нищий и компания моя всем недоплачивает.
Может поделитесь, откуда информация, что в Яндексе ниже рынка платят?
Человек пояснил, что по себе судит. Ему в других местах больше дали. Возможно на том же грейде в других компаниях работают специалисты послабее. Но платят им столько же.
Хорошую работу спам-боты не рекламируют.
Лет 6 назад ради интереса прошел все интервью и получил офер на юи-щика на 100к с таким видом, что это лучшее предложение в моей жизни. В то время получал в 2 раза больше. До этого делал навигатор который лучше работал на мобилках и мог строить маршруты в офлайн на древних андроидах. В бэкэнд и навигацию даже не позвали.
Опишу свой опыт, 3 года назад прошел собеседование в Яндекс на старшего разработчика (успешно) и они предложили мне ЗП ниже зарплаты, чем в то время на моем текущем месте (даже с учетом подписного бонуса если его включить в годовой доход), несколько раз они оффер переписывали, примерно добили до моего текущего уровня (это с подписным бонусом, который выплачивается в первый год и премиями). Сказали если хочешь больше, то переезжай в Москву, в итоге на этом расстались.
В то время я получил 4 оффера и от Яндекса была самая маленькая сумма.
p.s. и еще не понравилось, то что HR давит постоянно. У вас есть 3 (или 7 дней точно не помню)дня для принятия решения (у них там очередь за забором), потом еще 7 дней дали, потом пропали и через 3 недели еще раз вернулись спросить не передумал ли я.
На литкоде такой замечательный банк задач по SQL. И SQL - это, блин, реальность, с которой каждый бэкендер столкнется. Но нет, давайте до посинения считать подстроки в строках.
Вот кстати реально SQL же постоянно используем, почему бы его на лайвкодинге не спрашивать вместо алгоритмических задач...
Помимо литкода, кстати, ещё на codewars есть большой банк задач по sql.
Какой смысл спрашивать sql? Если человек умеет программировать на нормальном языке, то sql учится за день. За два дня можно свой инстанс наиболее используемой БД поднять и прямо на нем потренироваться.
Но в обратную сторону не работает, если человек знает sql и не умеет прогать, то знание sql ему не поможет примерно никак.
Последняя задача ввела в ступор конечно, ибо не любитель геометрии. Точки из набора имеют целочисленные координаты. Окей. А прямая должна иметь целочисленные координаты? Вертикальная, значит, нас интересует только x что бы задать прямую. Окей. Симметричные точки относительно прямой это как? Мол, если на прямой есть коориданата (x, y), то симметричные ей точки это (x + a, y) и (x - a, y)? Нууу, вот так сразу вообще ничего в голову не приходит как её даже теоретически можно начать решать. Кажется, что x нас очень интересует. Можно попробовать отсортировать набор точек по координате x, поскольку ищем симметричный набор точек, то таких точек будет чётное количество, значит, надо взять среднеарифметическое двух центральных точек из отсортированного массива, провести через эту среднюю точку вертикальную линию, и от этой линии влево и вправо сравнивать точки. Если они не симметричны, то набор не симметричен. Если дошли до конца, значит, набор симметричен. Может я в чём то ошибаюсь
Все верно. Только центральные точки - это не очень удобно, надо сравнивать влево и вправо. Берём первую и последнюю, берём их среднее по координате Х, и идём двумя указателями с конца и с начала до встречи указателей и проверяем, что Х1-Х2-Хцентра == 0. Если на всех точках условие выполнялось, значит такая линия есть.
Да, немного подумав над граничными случаями понял, что надо идти с концов. Сказано что симметричны должны быть точки не на прямой. Т.е. в исходном наборе не обязательно чётное количество. Может быть так, что исходно точек пять, симметричны две, а три лежат на прямой. В таком случае двигаться с концов удобнее
Задачу вроде бы можно свести к задаче "является ли строка палиндромом?"
struct Point
{
int x, y;
}
using Points = std::vector<Point>;
Points sorted(Points p)
{
std::ranges::sort(p, [](const auto& a, const auto& b)
{
return a.x < b.x;
});
return p;
}
bool is_palindrome(const Points& p)
{
if (p.size() >= 2)
{
size_t l = 0;
size_t r = p.size() - 1;
while (l < r)
{
if (p[l].y != p[r].y)
return false;
++l;
--r;
}
}
return true;
}
bool solve(const Points& p)
{
return is_palindrome(sorted(p));
}Вот, кстати, интересная тема. Мне понравилось ваше рассуждение. Я считаю, что именно так должен рассуждать кандидат на собесе. И вопрос в том, допустим, рассуждает кандидат хорошо, но код либо напишет плохо либо не сможет перенести мысль в код. Как тут быть тогда? Лично считаю, что кандидат, все-таки, "больше" прошел интервью, чем "не прошел". В контраст, кандидату, который, подумав, понял, что тут нужна сортировка + "два указателя", к примеру. Но вербально он не может объяснить и больше на интуицию полагается, чем на рассуждения "на подумать". Просто за завесой заучивания и нарешивания всех этих алгоритмических паттернов, сложно увидеть тех, кто реально будет думать над задачей, потому что такие кандидаты, могут не решить средненькую задачу, потому что они будут реально "думать" над ней, а не сканировать свои заготовки в голове.
Лично считаю, что кандидат, все-таки, "больше" прошел интервью, чем "не прошел". В контраст, кандидату, который, подумав, понял, что тут нужна сортировка + "два указателя", к примеру.
Это значит, что контрастный кандидат либо знает конкретно эту задачу, либо прорешал достаточно много задач, что бы понять какой способ нужен для решения задачи. Данный кандидат не тратит время на рассуждения, поскольку при рассуждениях человек блуждает в мыслях и в конце приходит к решению. Но контрастный кандидат имеет навык, поэтому его блуждания минимальны.
Собеседующие хотят посмотреть на умение рассуждать, но опытный кандидат затрудняется в рассуждениях, поскольку он не мыслит словами. Он приходит к решению не через диалог и рассуждения, а как-то просто натренированная нейросетка быстро выдаёт ответ. Поэтому у собеседующих не получается посмотреть, как кандидат рассуждает. В то же время, если не решать эти задачи вообще, то есть большой риск не решить задачу в рамках отведённого времени, продемонстрировать незнание и провалить алгоритмическую секцию собеса.
Вы же когда пишите цикл по всем элементам массива не задумываетесь как писать цикл?
"Тут объявим переменную, а чему она равна, а равно 0 потому что с 0, тут должно быть условие, а что условие представляет собой, ну раз проходим по массиву, то условием будет пока не пройдём весь массив, значит надо длину указывать, тут увеличиваем переменную что бы она менялась, поскольку надо пройтись по всем элементам, то и увеличиваем на 1..."
В начале пути изучения программирования, у человека, который первый раз в жизни видит цикл, примерно такие мысли и будут. А у человека, который 100 раз циклы написал, написание не займёт умственных усилий и при написании будет думать над более важными вещами в своей задаче.
Как мне кажется, с одной стороны, такой скил "не думать и просто писать" ускоряет написание базовых вещей, с другой, в повседневной работе спрашиваемые на собесах алгоритмы у большинства людей не входят в каждодневную кодовую базу. Кажется, что умение быстро писать такие штуки полезно, но не ультимативно - нельзя сказать, что человек, который натренировал лучше того, который не натренирован, ведь это лишь один пазл и общей картины, а у другого человека картина может состоять из других вещей, которые в целом будут не хуже, чем у натренированного
Ко мне в телеграмм постучалась очень приветливая и милая девушка HR из Яндекса, с предложением о работе.
Недавно решил на несколько таких предложений откликнуться... По итогу сделал вывод, что таким способом предлагают всякий "неликвид" вакансий, где либо какой то треш на собеседовании, либо компания сама не знает кого она ищет - поиск ради поиска.
независимый эксперт, хотя я не поняла, в чем разница, кроме той, что он был визуально строг
Это не "независимый эксперт". Это проверяющий собеседующий. Задача про вертикальную ось симметрии как раз из небольшого набора задач, которые они дают.
Суть секции с ним -- поддерживание минимальной планки нанимаемых разработчиков (а не подъём средней, как устроено с институтом bar raiser в Amazon). Провал этой секции -- гарантированный провал всего собеседования, даже если все остальные секции прошли хорошо, покуда проверающий собеседующий имеет право вето.
А суровость его вида связана, вероятно, с тем, что они проводят собеседования куда чаще среднего разработчика и посему для них этот процесс куда менее увлекательный.
Несмотря на предыдущие скептические комментарии, я по своему опыту считаю, что работать в Яндексе хорошо, интересно и с годами компенсация может стать вполне внушительной, если понять, как устроена система мотивации.
И да, в Яндексе работают вполне адекватные люди, многие из которых не питают иллюзий по поводу оторванности от жизни литкод-собеседований. Все понимают, что они дают много ложноотрицательных срабатываний, приводящих к отказам достойным кандидатам. Особенно, если они не готовятся к собеседованию, хотя заранее хорошо известно, как эти собеседования проходят. Но это отдельная долгая тема, почему это так устроено во всех бигтехах.
А потом на работе вы будете делать из этого... ничего, и самым сложным в работе так и останется собеседование.
Если это шутка, то хорошая, но всё равно поделюсь мнением.
Выглядит, что задачки из поста проверяют базовые навыки написания кода и умения чуть-чуть подумать, так как довольно простые. Реальная работа сложнее, требует больше навыков и умения рассуждать. Если не хватает навыков для решения задач из поста, то вероятнее всего стоит немного набраться опыта, иначе будешь спотыкаться при решении более серьезных проблем.
Странно, что примитивное оперирование структурами данных(типо прохода по массиву) здесь считают очень тяжелым испытанием, которое никогда не пригодится разработчику.
Моё предположение, что вы не замечали, как делали подобное много раз, ведь это очищенная выжимка того, что мы делаем, когда используем любые структуры.
Всегда было интересно, а какие у решений этих литкодовских задачек практические применения.
Я вот просто не могу себя заставить написать даже 1 строку кода без нормального объяснения, на кой именно чёрт он нужен в реальной жизни. Это не по-инженерному.
И в проде мне подобное за 25 лет встречалось ну может всего-то пару раз, а предметных областей и направлений деятельности я за это время перебрал целую кучу... Более того, писать чё-то такое с n-граммами / векторами / разбиениями с нуля такое вообще оказывалось не рационально, потому что есть готовые решения — и на крайняк код можно утырить оттуда, и подрихтовать как требуется.
Ценность в возможности хотя бы даже предположить существование более эффективного решения, чем очевидный перебор вложенными циклами. А будет дальше этот код утырен, или же самостоятельно написан — уже не столь важно.
какие у решений этих литкодовских задачек практические применения
Какие альтернативы в компании на 10к+ раработчиков, с тысячами собеседующих и миллионами кандидатов? Где нужен конвеер и стандарт, чтобы компания не превратилась в набор несвязанных команд с рыночными отношениями.
Почему эти альтернативы не применяются в шести из семи крупнейших компаний по уровню капитализации (про нефтяников Saudi Aramco не скажу, но остальные компании списка -- Alphabet/Google, Nvidia, Apple, Microsoft, Meta/Facebook, Amazon), почему в них поголовно пишут литкод?
Из-за особенностей визы L1 и разницы в уровне жизни в Индии и США.
Без понятия. Собеседователи из этих контор мне не смогли объяснить, когда я их об этом напрямую спрашивал.
БТВ, это всё похоже на какой-то тупой ритуал.
Если мне самому надо пособеседовать кого-то, то я беру список из ~150 релевантных для вакансии тем, и рандомно гоняю кандидата по нему. За час вполне можно составить представление о том, соответствует человек ожиданиям, или нет.
Такое мнение можно найти про все, что требует усилий. Так уж устроен человек.
И вместе с тем, есть люди увлеченные, готовые чем-то заниматься уже только потому, что это интригует.
Позвольте под вашим комментарием разместить манифест о том, что учиться очень хорошо и полезно, это развивает мозг и формирует личность.
Возможно ли сконфигурировать прикладное решение, не прочитав ни одной книги и заработать на этом? Да, конечно. С ростом опыта еще и время эффективно потратив.
Так то эти задачки придумали для собеседований, чтобы как-то формализовать отбор, чтобы рекрутеры могли высокомерно рассуждать о квалификации кандидата, не утруждаясь значению слов. И вот конкретно в Яндекс задачи третьей секции выбирают откровенно глупые, наверное потому, что сложные не каждый интервьюер сможет. И эти интервьюеры еще наплевательски относятся к собеседованию: опоздал, ну да и ладно, зато неспеша начнем, как раз поболтать захотелось и есть идея про задачу (неправильная). Кроме молодых ребят, которые на первых двух этапах, те волнуются и серьезны, причем у них и задачи интереснее бывают, чем на "алгоритмической" секции.
Так вот, задачи глупые, а собеседования пафосный бардак.
Но алгоритмы это круто и алгоритмы это не пара трюков из однострочных задачек. Можно не учить и не знать, но не нужно таких специалистов смешивать в одном ряду, они из разных сфер. Кто-то уже все сделал, что можно использовать готовое? Так оно не само готовым сделалось.
К слову, для сотрудников того же Яндекс одно время читал лекции Максим Бабенко.
Из первой задачи:
if (s.length() < k) { return s.length(); }
И с чего это правильно?
Пусть k = 4, s = "aaa".
Тогда ответ: 1, а не 3.
почему 1? возвращается длина строки, она равна 3?
По условию задачи:
Задача 1
Для заданной строки s и целого числа k вернуть длину самой длинной подстроки s, содержащей не более k различных символов.
Если строка s состоит из одного и того же символа, то длина самой длинной подстроки s, содержащей не более k различных символов = 1. Символ же один и тот же.
Сколько вы видите различных символов в строке "aaa"? Ну и принцип Дирихле, если не ошибаюсь.
Понятно, это я перепутал формулировку задачи. Всё ok с этими строчками.
Мне кажется, или Яндекс потихоньку пытаются "отбелить"? Сколько было статей про многоступенчатые, аля Вавилонская башня, собеседования, алгоритмы, долгие согласования с разными людьми, а сейчас пошли статьи что-то в духе: "да не, не так уж там и страшно, там норм".
Причём недавно попадался ролик какой-то девочки HR из Яндекса, где она жаловалась, что нет java-разработчиков уровня middle; мол, пишите, все дела. Так может и не пишут, потому что куча собеседований + алгосики?
Автор, претензия не к вам. Просто наблюдения, что будто пытаются отбелить имидж компании)
Алгоритмические задачи, конечно, на бэкендера вообще не сдались. Они хороши для каких-нибудь мейнтейнеров ядра Линукс, разработчиков енкодеров всяких, в конце концов писателей софта под роверы на Марсе, но точно не бекедера. 99% работы бэкендера - это вытянуть правильно данные из базы, поработать над ними и положить обратно. И вот тут полно неучей которые не умеют запрашивать связи в ORM для избегания N+1 запросов, не умеющих составлять сложные запросы оптимально, да даже тупо индексы в таблице не могут правильно расставить.
Да нормально выяснить, знает ли человек что нибудь про алгоритмы и их сложность. Только формат нужен другой. Написать руками за пол часа даже элементарный бинарный поиск на собеседовании будет сложно (а при учёте всяких граничных условий - невозможно), если человек специально не тренируется. А вот какой в этом смысл совсем не понятно. Думаю, если человек просто расскажет словами про сложность алгоритма и как его реализовать, этого будет вполне достаточно.
Так-так, подождите, я вот системщик и постоянно ковыряю то ядро Linux, то U-Boot, то FreeBSD, зачем мне алгоритмические задачи то? Куда их впихивать при разработке драйверов?
Я даже начал склоняться к мысли, что литкод интервью более "честные" что ли. Получил задачу - решил нет/да, показал рассуждения.
А то приходишь на интервью уровня сеньер и тебя как и 8 лет назад спрашивают одни и те же JAVA вопросы :
> связи в ORM для избегания N+1 запросов
> как работает хешмап
> что такое flyway ))
> и прочая полуджуновская, полуотсебятина от интервьюера которая явно дает понять, кто в это место может попасть и кто твои будущие коллеги
Алгоритмы и структуры данных понимать нужно, но не в таком виде как на собеседованиях справшивают.
Есть вполне адекватные способы проверить понимает ли человек сложность того или иного алгоритма, будет ли он городить O(n^4) циклы и прочее без задрачивания его подстроками и прочим.
Также вполне можно понять понимает ли человек отличия хеш-таблицы, дерева, массива и т.п. В каких случаях использовать одно или другое. Просто поговорив и задав несколько вопросов, подискутировав об этих вещах - это сразу видно.
Куча народу просто отваливается на вопросах в духе "вот тебе нужно сделать кольцевой буфер обычный, какую структуру данных удобно использовать?". Начинают отвечать в духе "нууу, наверное хеш-таблица..."
Собеседование в Яндекс v.2023г
На календаре 01.11.2024 ...
особенно потому, что рынок IT в 2023 очень нестандартный :-)
Поясните, что означает "нестандартный". А он когда-то был "стандартным"? Что бы это ни значило.
По первой задаче решил набросать решение дабы проверить себя, не прибегая к каким-либо подсказкам, но в Android Studio. Так вот я оказался не молодец, которым должен быть согласно картинке выше, поскольку заняло у меня это больше часа. Потупив, после проб и ошибок с запуском под дебагом, я пришёл к решению, которое, справедливости ради, получилось более компактным по сравнению с тем, что в посте. Попутно также выяснилось, что немного изменённый код решает другую задачу. Пишу на Котлине.
Вот что вышло:
fun longestUniqueSubstring(s: String, k: Int): Int {
require(k >= 0)
var result = "" if (k > 0) { for (index in s.indices) { val set = mutableSetOf<Char>() for (i1 in 0..index) { val c = s[i1] for (i2 in 0..index) { if (c == s[i2]) {
set.add(c) } } } if (set.size <= k) { val subst = s.substring(0, index + 1) if (subst.length > result.length) { result = subst } } else { break } } } return result.length }
Если переформулировать задачу так:
Для заданной строки s и целого числа k вернуть длину самой длинной подстроки s, содержащей не более k одинаковых символов.
то решение может быть следующим (извняюсь за отсутствие форматирования, хабр не позволяет):
fun longestNotUniqueSubstring(s: String, k: Int): Int {
require(k >= 0)
var result = ""
if (k > 0) {
for (index in s.indices) {
val map = mutableMapOf<Char, Int>()
for (i1 in 0..index) {
val c = s[i1]
// количество вхождений символа c в текущую подстроку до index
var count = 0
for (i2 in 0..index) {
if (c == s[i2]) {
count++
}
}
map[c] = count
}
if (map.values.max() <= k) {
val subst = s.substring(0, index + 1)
if (subst.length > result.length) {
result = subst
}
} else {
break
}
}
}
return result.length
}
Таким образом, ни о каком написании решения по данной задаче в онлайне перед кем-то не идёт и речи (если только нет желания опозориться). Понятно, что это принципиально для того, чтобы устроиться в Яндекс (в котором я не могу и не хочу работать), но если смотреть в целом, насколько критичен невывоз подобного лайвкодинга в общем случае?
По задаче
Перенести нули в конец массива, сохранив порядок остальных элементов
Я бы сделал вот так (Котлин):
val result = mutableListOf<Int>()
val zeros = mutableListOf<Int>()
array.forEach {
if (it != 0) {
result.add(it)
} else {
zeros.add(it)
}
}
result.addAll(zeros)
return result.toIntArray()
Так нельзя или это чем-то плохое решение?
Неплохо покормили читателей хабра отборной пастой.
Буквально неделю назад проходил собес в Яндекс java-разработчиком. В конце второго этапа просто изчезли. Через несколько дней отписались, что я им не подхожу. Аргументировали, что им не хватило "чистоты кода и проверок на null". Моя просьба представить более развёрнутый фидбек ни к чему хорошему не привела. Я обе собеса прошёл почти идеально, решил все задачки, написал тесты, даже время ещё оставалось.
Сталкиваюсь с таким уже второй раз с их стороны. Кстати Тинькофф в этом плане тоже далеко не ушёл, но там хотя бы ближе к практике собеседования.
В общем, никому не советую проходить 5+ собеседований, только если вы не джун - олимпиадник, который не ценит себя.
Собеседование в Яндекс v.2023г