Комментарии 14
нужен список типовых вопросов и задач;
Это просто подарок для паровозика волков.
Причём этот паровозик был уже даже в кинематографе описан (в фильме A Family Man, который российские надмозги перевели как Охотник с Уолл-стрит). Но всё равно, все продолжают превращать собеседование в ЕГЭ в поисках рок-звезд программирования.
нужна пошаговая методичка, чтобы процесс был примерно одинаковый у разных интервьюеров;
...
Эта ошибка появляется, когда интервьюер строго придерживается методички и не может вести свободный диалог
Проблема в том, что кодеры при прокачке не вкладывали очки в психологию, харизму, красноречие и проницательность. Так что наличие методички приводит только к тому, что идут по методичке. Интервьюера, который копнет и расколет кандидата надо прям растить. А этим не занимается никто. Гораздо проще написать методичку с вопросами типа "как устроена хэшмапа" и "чем спринг отличается от спринг бут".
убрать дубликаты из массива:
Для массива произвольных объектов это в общем случае совсем не простая задача, если что. И скорее всего будет иметь сильно разные решения в реальной жизни, в зависимости от дополнительных условий.
доп. условие к ней такое: решить в самом простом виде, конкретно для этого массива. Все объекты простые: одна буква, одна цифра, никаких 0, null, undefined, глубокой вложенности и т.п. Любой подход (при условии что порядок конкретно этих объектов может быть любой). Если можно просто и в лоб, можете сделать просто и в лоб.
В общем случае случае (когда для объектов определена только функция isEqual, возвращающая true / false) вроде возможно же только решение с полным перебором за О(n^2). Для хотя бы О(n*log_2(n)) нужно как-то определить операцию сравнения между объектами, возвращающую больше/меньше/равно. Или определить какую-то внятную хеш-функцию Можно попробовать использовать JSON-представление объектов, но стандартный JSON.stringify не подойдёт, из-за того что будет давать разный хэш при разном порядке следования полей, например сравнение
JSON.stringify(JSON.parse(`{"b":1,"a": 1}`)) === JSON.stringify(JSON.parse(`{"a": 1,"b":1}`)) вернёт false. Соответственно нужно написать свой. На циклические ссылки проще всего наверное проверять запуском стандартного JSON.stringify и выдавать таким объектам отдельный кэш. Потом по кэшу сложить объекты в уже стандартный Map или Object. Объекты с одинаковым кэшем потом проверять уже полным перебором. Если повезёт, то коллизий будет не очень много, и сложность будет близка к О(n).
Всё вместе это по-моему довольно длинная задача. Если вы ждали просто аккуратный полный перебор, то ОК.
Разный хэш при разном порядке будет для объектов где больше одной буквы, а по условию:
конкретно для этого массива. Все объекты простые: одна буква, одна цифра, никаких 0, null, undefined, глубокой вложенности и т.п.
const input = [{ a: 1 }, { b: 2 }, { a: 1 }, { a: 2 }, { d: 4 }];
const output = [...new Set(input.map(JSON.stringify))].map(JSON.parse);За предположение и рассуждение "+", а вот решения, лично я, требую самое топорное, которое придет в голову. Короткое решение + объяснение, где и как оно может развалится в будущем и какие ограничения. Есть другая ачивка, которую соискатель случайно не должен выбить на собесе — «переусложненние». Меня самого за это пару раз срезали и я стал более внимательно к этому относится.
В жизни просто массив в Set запихнут, который гарантирует уникальность. Просто, понятно, минимум возможностей отстрелить себе ногу, и вполне пригодно для большинства ситуаций.
К нам пришли пара человек после собеса в тиньке. Там иногда собеседует чувак с прической "дискотечный додик из 80-х". У нас стала крылатой его фраза "здесь я решаю про коммуникации девопс или нет".
Люди бывают разные, некоторым противопоказано получать хоть какую-то власть, даже на время собеседования.
Поэтому не стоит пропускать «банальные задачи» только по тому, что вы увидели в резюме кандидата «20 лет опыта решения алгоритмов в Google».
Прямо сейчас я вам рекомендую надеть какую-нибудь одежду, которую не жалко и защитить лицо шлемом. Сейчас полетят какахи :)
Почти со всем согласен, чувствуется, что автор практик. Часто подобные статьи пишут люди, которые провели максимум пару собеседований (а то и вовсе были на собесах только в качестве кандидата) и решили, что теперь самое время учить других :)
"Пример решения подобной простой задачи от «синьора помидора, 12 лет опыта»"
Я бы тоже начал писать бред, если бы ранее на предыдущем вопросе мне капали на мозг вздором "а без for? а без замены var? а без этого? а без того?". При этом ранее по тексту писалось про "встал и ушёл с собеседования" — как раз идеальная ситуация для такого.
По поводу тестовых задач: насколько часто вы сталкивались не с абстрактными задачами (типа той-же обработки массивов или сортировки деревьев) - а с задачами, приближенными к реальным задачам на проектах? По моему опыту - это редкость, но я не до конца понимаю причину этого.
С одной стороны, сталкивался редко. С другой стороны, свой опыт, в этом плане, переосмыслил.
Начнём с причин:
На реальном проекте задача часто имеет большой контекст и историю вопроса. Трудно вырезать её из контекста и в компактном виде представить на собеседовании.
Большая часть задач на большинстве проектов достаточно банальны. Ты полу-копированием по образцу пишешь простой код по перекладываю JSON`ов.
Чтобы решить эти проблемы:
делаем маленькие обособленные задачи;
рассматриваем в них ту самую меньшую часть, где нужно подумать;
И в этот момент может оказаться, что далеко не все задачи «про алгоритмы», на самом деле «про алгоритмы». Переосмысливая пройденные алгоритмические секции, сейчас я понимаю, что 50% кода там это и были задачи про бизнес.
Например, на фронте: задача проверки анаграмм;
Решение в «классическом» виде покажет, что человек понимает узкие места производительности. Если взять его в команду, то вряд ли мы потом получим тех. долг вида «всё тормозит, работать невозможно».
Решение «в лоб» (через кучу методов массива) говорит о том, что он хорошо знает базовое API и скорее всего в рабочих задачах часто сможет решить проблемы обычным способом, не создавая на проекте «ад зависимостей», которые потом через пару лет мы физически не сможем обновить или удалить малой кровью.
ТОП ошибок тех. интервьюеров