Comments 21
А я думал только у меня по-дурацки проходят интервью) Надо просто чаще ходить на собеседования, чтобы привыкнуть.)) Ненавижу писать код на бумажке, отчасти потому что в голове решение формируется не в виде лингвистических форм языка, а в виде абстрактных предметов, взаимодействий и прочей каши с пробелами и пароходами в большом театре, что потом воплощается в конкретное решение, под которое подбираются средства конкретного языка с их особенностями или даже нескольких языков.
У меня все описанные типы собеседований были, кроме одного, с открытием офиса. Еще было успешное тех интервью, после которого сказали, что готовы выставить офер с вопросом "вы же в Питере?". Я говорю нет, мол. "Как так, мы же в Питер собеседуем".
Давным-давно, пригласили меня на собеседование в одну контору, условно на ул. Ленина 12. Решил уточнить как лучше к ним добраться - "езжай до станции метро Какая_то_там". Я в задумчивости - не помню я у нас такой станции. Уточняю город - Москва, а я в Новосибирске :)
Всё таки плюсовики - очень своеобразные люди.
Можно заметить, что язык оказывает большое влияние не только парадигмами, под который он "заточен", но и историей языка, подходу к технологиям, и восприятия понятия "программист" в целом.
Писать код на бумажке? В 2021? Боюсь что встретив такое, прогеры на большинстве других языков просто сразу скажут "досвиданья".
Выбирать сотрудников на основе предпочтительного текстового редактора или исходя из оформления или формата резюме? Разве что это будет дизайнер UI.
Ну и немного о заданиях. То, насколько подробно вы составляете ТЗ для тестовой задачки тоже о многом говорит.
Создать игру "жизнь"? Вы задачки по проекту точно так же будете ставить?
Напиши библиотеку "обработчик сообщений". И прогер такой "ОК!, завтра будет"
То, насколько подробно вы составляете ТЗ для тестовой задачки тоже о многом говорит. Создать игру "жизнь"? Вы задачки по проекту точно так же будете ставить?
Что-то недопонимаю претензию. Во-первых, там подчёркивается «естественно, предлагаю задавать дополнительные вопросы». Во-вторых, поясняется, зачем это нужно: посмотреть, будет ли человек задавать вопросы и какие. Если считать такое ТЗ очевидно недостаточным — то как раз сразу можно увидеть, какие из кандидатов это понимают, и это поможет выбрать лучшего. В чём проблема-то?
Видя очевидно недостаточное ТЗ у меня начинается подгорание жопы, и сомнения в компетенции его составителя.
Я могу понять, когда какие то пункты в задаче могут быть забыты или сознательно пропущены.
Но от столь вопиющего игнорирования правил банального приличия у меня возникает желание отдать в качестве решения простыню кода на brainfuck, и сказать "задавайте вопросы, если что то непонятно"
И да, на собеседовании не только работодатель смотрит на кандидата, но и кандидат на работодателя. И если к такой задачке от девочки HR ещё можно отнестись снисходительно, то для тимлида подобное ТЗ совершенно недопустимо, и выглядит как намеренное оскорбление из разряда "мне настолько плевать, что я даже не буду заморачиваться с формализацией"
Думаю, если вы реально напишете простыню на brainfuck, то это довольно много скажет о вас как о кандидате, то есть цель опять же будет достигнута :)
Тогда задам такой вопрос. Как вы считаете, по какой причине люди изначально стали делать подробные ТЗ: потому что это «правила банального приличия» или потому что без чёткого ТЗ результат не соответствовал желаниям заказчика?
Как вы считаете, по какой причине люди изначально стали делать подробные ТЗ: потому что это «правила банального приличия» или потому что без чёткого ТЗ результат не соответствовал желаниям заказчика?
По причине знакомства с множеством граблей, в случае отсутствия нормального ТЗ.
И если заказчик не способен составить ТЗ самостоятельно - то делать это придётся мне, задавая кучу глупых вопросов и тратя на этот процесс кучу своего и чужого времени.
Однако общение в данном случае ведётся с тимлидом, который как минимум должен понимать важность чёткого разграничения полномочий, требований, и допустимого инструментария для решения задачи.
Если по каким то вопросам ожидается что я должен сам принять решение, то очень бы хотелось услышать это в явном виде.
Подумал и понял, что вижу как-то так.
Когда условия тестового задания (не только этого, любого) очень строгие и конкретные, по результату можно оценить конкретные скиллы. А когда расплывчатые — тут по действиям кандидата можно получить представление о том, как он вообще мыслит, принимает решения, справляется со сложностями, что ему ближе. Даже если вакансия не предполагает принятия ключевых решений по проекту, все эти вещи важны. И если сразу конкретизировать задание, о таких вещах поймёшь меньше.
Поэтому, когда ТЗ расплывчатое, это может означать не «было лень составлять правильное». Для своих целей оно и есть правильное.
Что при этом надо проговаривать в явном виде — сложный вопрос, и мы оба не видели, как именно выглядел текст в обсуждаемом случае. Но для меня лично такая постановка задачи звучит примерно как «напишите игру "Жизнь" так, словно это ваш пет-проект» (там как раз засчитали случай, где это и было пет-проектом). Если бы там была такая приписка, в этом случае у вас претензии были бы или нет?
Создать игру "жизнь"? Вы задачки по проекту точно так же будете ставить?
Справедливости ради, если к такому заданию будет идти ремарка "я знаю, что ТЗ очень расплывчатое, мне хочется посмотреть на то, как вы будете его уточнять" — то я бы к этому отнесся крайне положительно.
Если без такой ремарки — то да, попахивает пренебрежением.
Особенно прикольно, кстати, что дальше по тексту статьи другой из участников жалуется, как ему поставили задание "сделать таймлайн в гуглмапсах". А это как раз тот же подход.
Чуть-чуть лучше бумажки: https://code.yandex-team.ru/
интересно было узнать мнение про многопоточность в С++.
Эххэ. Это то что ... Я как то спросил у собеседуемого разницу между tcp и udp. Знаете что услышал ? ... tcp это в windows а udp в линукс. Сказал как отрезал.
Для написания игры "жизнь" лучше всего подходит Pascal.
program Life;
begin
end. 
Отшить чувака после того как он дал кошечке 9 жизней? Я б от такого снобизма сам бы сбежал...
«Это что! А вот у меня на собесе было…», или Байки с технических интервью