Увидел выше дискуссию "собеседовать литкодовскими задачами или нет". С комментариями типа "если не литкод, то тогда собеседовать под определенные фреймворки и т.п., а это не всегда лучший подход".
С моей точки зрения литкодовский подход отличен, если речь идет о собеседовании студентов - которые алгоритмы, предполагается, только что выучили. А рабочего опыта почти нет, поэтому об остальном спрашивать смысла мало.
По мере же того, как человек набирает опыт, литкодовские задачи все меньше полезного демонстрируют. Я в Гугле, например, за 4 года видел 2 алгоритма, выходящие за рамки "а давайте добавим HashMap / unordered_map". И то один из них был на 4 строчки - что-то типа "если длина массива больше N - сделать по нему бинарный поиск, а иначе - тупо перебрать все элементы".
Основная сложность работы была не в алгоритмах. Об алгоритмах самое полезное было - это в принципе представлять, какие основные есть, чтобы в нужной ситуации уловить схожесть и загуглить нужное решение.
В Гугле хватает людей, которые обоснованно боятся быть подопытными кроликами для собеседователей, тестирующих новую задачку - потому что имеют основание считать, что не решат алгоритмическую задачу, которую должны решать кандидаты на собеседованиях. И когда речь шла о втором из увиденных мною двух алгоритмов, я получил одобрение моего решения, хотя в нем была ошибка. Эту ошибку не увидело два TL'я.
А еще в Гугле хватает людей, которые отлично знают алгоритмы и пишут много разного кода, но ни с ними, ни с их кодом невозможно работать - потому что гений может быть хорош в вакууме, но когда тебя без толкового словаря невозможно понять, а чрезмерно сложный код выглядит так, что "угадал все буквы, но не смог назвать слово", то толку от такого гения мало.
А еще хватает очень энергичных инженеров, которые пишут отличный код и вообще котики, но вся их работа никому нахрен не нужна. Потому что когда ты пишешь продукт для условного клиента (включая внутреннего), но с этим клиентом не общаешься, то ты пишешь продукт не для клиента, а для себя. Я видел людей, которые месяцами не могли толком понять, что производит команда. Видел продукты, на которые клиенты махали рукой, так как никто не будет тратить месяцы на попытку понять, что вы там такое хитрое написали.
Поэтому, с моей точки зрения, альтернатива литкоду - это не интервью о конкретных фреймворках. Это - интервью на читаемый код, на простоту тестирования, на проджект менеджмент, азы которого должны быть в голове каждого инженера - например, в плане разбития задачи на более мелкие, приоретизации, оценки сложности реализации, рисках и т.п. На продакт менеджмент - азы тоже полезны всем, например - чтобы человек мог рассказать, почему у него интерфейсы такие, а не другие, чтобы мог минимальную документацию написать.
И вот потом человека можно оценивать по набору оценок в разных номинациях, а не "хорошо ли зазубрил depth first search".
