(UA) IT/Tech Ukrainians in Canada
-
Увидел выше дискуссию "собеседовать литкодовскими задачами или нет". С комментариями типа "если не литкод, то тогда собеседовать под определенные фреймворки и т.п., а это не всегда лучший подход". С моей точки зрения литкодовский подход отличен, если речь идет о собеседовании студентов - которые алгоритмы, предполагается, только что выучили. А рабочего опыта почти нет, поэтому об остальном спрашивать смысла мало. По мере же того, как человек набирает опыт, литкодовские задачи все меньше полезного демонстрируют. Я в Гугле, например, за 4 года видел 2 алгоритма, выходящие за рамки "а давайте добавим HashMap / unordered_map". И то один из них был на 4 строчки - что-то типа "если длина массива больше N - сделать по нему бинарный поиск, а иначе - тупо перебрать все элементы". Основная сложность работы была не в алгоритмах. Об алгоритмах самое полезное было - это в принципе представлять, какие основные есть, чтобы в нужной ситуации уловить схожесть и загуглить нужное решение. В Гугле хватает людей, которые обоснованно боятся быть подопытными кроликами для собеседователей, тестирующих новую задачку - потому что имеют основание считать, что не решат алгоритмическую задачу, которую должны решать кандидаты на собеседованиях. И когда речь шла о втором из увиденных мною двух алгоритмов, я получил одобрение моего решения, хотя в нем была ошибка. Эту ошибку не увидело два TL'я. А еще в Гугле хватает людей, которые отлично знают алгоритмы и пишут много разного кода, но ни с ними, ни с их кодом невозможно работать - потому что гений может быть хорош в вакууме, но когда тебя без толкового словаря невозможно понять, а чрезмерно сложный код выглядит так, что "угадал все буквы, но не смог назвать слово", то толку от такого гения мало. А еще хватает очень энергичных инженеров, которые пишут отличный код и вообще котики, но вся их работа никому нахрен не нужна. Потому что когда ты пишешь продукт для условного клиента (включая внутреннего), но с этим клиентом не общаешься, то ты пишешь продукт не для клиента, а для себя. Я видел людей, которые месяцами не могли толком понять, что производит команда. Видел продукты, на которые клиенты махали рукой, так как никто не будет тратить месяцы на попытку понять, что вы там такое хитрое написали. Поэтому, с моей точки зрения, альтернатива литкоду - это не интервью о конкретных фреймворках. Это - интервью на читаемый код, на простоту тестирования, на проджект менеджмент, азы которого должны быть в голове каждого инженера - например, в плане разбития задачи на более мелкие, приоретизации, оценки сложности реализации, рисках и т.п. На продакт менеджмент - азы тоже полезны всем, например - чтобы человек мог рассказать, почему у него интерфейсы такие, а не другие, чтобы мог минимальную документацию написать. И вот потом человека можно оценивать по набору оценок в разных номинациях, а не "хорошо ли зазубрил depth first search".
-
Но вообще у меня впечатление, что даже это - больше подход для всяких performance review, а не для собеседований. Потому что большинство проблемных людей проблемны по двум причинам: - либо вообще не соображают; - либо с ними нельзя работать даже если они все знают, например - потому, что они будут тебе говорить, что все сделали, даже если сами знают, что это не так. Первых можно относительно просто отфильтровать вопросами типа "вот вам массив, отсортированный по возрастанию, отсортируйте его по убыванию". Вторых собеседованиями просто не отловить. Они становятся видны, когда начинаешь с ними работать. И вот тут нужно просто принять agile - что вы можете собеседовать как угодно, но у вас будут проходить собеседования люди, с которыми иметь дело - себе дороже. И что лучше не усложнять собеседования, а обзавестись системой, которая позволит вам от таких людей избавляться как можно быстрее и безболезненнее. А дальше - можно, например, брать людей спокойно контрактерами на время, давать им реальную работу, платить за нее - что лучше, чем давать тестовые задания, которые занимают несколько дней, и результат которых нахрен никому не нужен. И вот в процессе работы смотреть - подходит ли человек, или нет. Если подходит - делать полноценным сотрудником и стараться сделать так, чтобы человеку не хотелось от вас уходить. Неопытного часто можно обучить. А мудака перевоспитать - почти нереально.
-
Ну так всі фаанги на це і роблять наголос, там пʼять етапів інтерв’ю і на більшості з них ви отримаєте алгоритмічну задачу, щоб перевірити, чи ви взагалі вмієте мислити. І навіть не завжди обов’язково її розвʼязати до кінця. А потім пів інтервʼю будуть говорити з вами про біхейвіорал питання. І в принципі їм пофіг яка суть відповіді з технічної точки зору, вони перевіряють як ви розмовляєте і поводите себе як людина. І кожен етап з новим інтервʼюером, щоб зібрати комплексний фідбек, а не від однієї людини, котра може бути упередженою.
-
Я не знайомий з деталями того, як співбесіди проводять інші фаанги. Але Гугл відкрито на питання "а що якщо людина просто знає, які відповіді ви хочете почути в behavioral співбесідах, і каже вам це, хоча думає інакше" відповів: "якщо людина на це здатна, то це - ознака інтелекту, нам такі люди потрібні". Приблизно те саме компанія каже про олімпіадників, які звикли розв'язувати алгоритмічні задачки на час: "ну то й що, що це для них звично, - такі люди нам і потрібні". Наскільки мені відомо, на таких змаганнях не принципово, чи пишеш ти зрозумілий код, якій підходить для подальшої роботи - головне вирішити завдання швидко. Тобто Гугл каже прямо, що по behavioral'ам набирати маніпуляторів, а по алгоритмічним співбесідам - тих, які пишуть код тяп-ляп, але складний і швидко - це нормально. Ну і після такого відбору з'являється культура, коли менеджер каже: "навіщо ти допомагаєш людині, яка навіть не в нашому проекті?" Тому що персональні досягнення означають більше, ніж якість продукту та досягнення команди.
