«много интересных задач, автоматическое решение которых может пригодиться для создания удобных инструментов для разработчиков» — типичная ситуация, когда лень одного человека оборачивается головной болью остальных. Вы поставили телегу вперед лошади: это не сообщение к коммиту должно отражать содержимое, а наоборот: коммит должен отражать идею разработчика, а сообщение содержать внятное описание того, зачем этот коммит понадобился. Напрашивается аналогия с поворотниками у автомобиля: поскольку есть категория водителей, не утруждающих себя обозначением маневра сигналами поворотников, взять и «изобрести» девайс, который будет включать их сам при повороте руля… Тоже как бы «автоматическое решение для удобства», только теряется сам смысл.
Поскольку я ярый поборник дисциплины в использовании Git, написании точных и осмысленных комментариев, я бы хотел использовать ссылку на данную разработку как пример антипаттерна. Буду очень благодарен, если вы приведете пример комментария, который система выдает на коммит, содержащий сортировку пузырьком.
Чтобы немного подсластить пилюлю: с академической точки зрения работа интересная. Возможно, она имеет смысл для аннотирования старого легаси кода. Но ее практическое применение именно для автоматической генерации сообщений к новому коммиту способно нанести немалый вред.
«Отнимают массу времени на подготовку», «Добавьте к этому тот факт, что сеньоры стеснены во времени (у них есть неотложные задачи и часто значительные личные обязанности), и всё это идеальный шторм.»
Что же предлагается:
я бы предложил вам дать очень короткое задание (которое занимает не более часа или двух и выполняется им дома). Большинство должны быть в состоянии найти небольшое количество времени для выполнения такого задания, особенно по той причине, что оно исключает работу по подготовке, необходимую для собеседования с программированием, и может быть разбито на временные отрезки, которые лучше вписываются в их напряженный график.
Дополнительное преимущество — тот факт, что соискатель может посвятить этому упражнению как можно меньше или как можно больше времени, позволяет вам понять, что ими движет. Внимательны ли они к комментариям? Подумали ли они о тестировании? Структурировали свой код разумно и понятно? Насколько они сосредоточены на качестве работы? Другими словами, вы будете знать, могут ли кандидаты программировать и могут ли они программировать хорошо и в более реалистичных обстоятельствах.
Ой! Ненавижу такие задания. Вместо одного часа лимитированного по времени задания тебе теперь приходится делать уже неограниченную сверху работу, вылизывать каждую строчку в меру своего перфекционизма и угадывать, на что же именно будут обращать внимание. IMHO лучше время от времени поддерживать свои базовые навыки в надлежайшем состоянии, чтобы при случае не испугаться какого-нибудь динамического программирования… И времени уходит меньше, и на порядок полезнее.
Никакой проблемы в собеседованиях с программированием не вижу, гораздо хуже поведенческие вопросы.
«Назовите самый challenging проект». Ну извольте: работал в токсичной компании в наспех собранной команде (по рассказам, большую ее часть набирал директор, не имеющий технического образования, руководствовался только резюме, на собеседованиях знаний не проверял, ибо не имел компетенций). На момент моего присоединения к команде та успела продолбать все сроки. В итоге, с одной стороны, ты ни в чем не виноват, с другой — с тебя требуют результат уже завтра (с явным видом, что бы опоздал еще вчера, до того, как прислал им резюме). В процессе выясняется, что с командой полностью отсутствовала обратная связь, и о том, что в ней происходит, начальство узнавало исключительно из редких отчетов (никаких демонстраций не было отродясь). При ближайшем рассмотрении оказалось, что первая половина этих отчетов — выдавание желаемого за действительное, а вторая половина — откровенная ложь. Часть работ, про которые начальство было уверено, что у нас все сделано от и до, даже не была начата (при том, что успешное окончание было отрапортовано). Не шучу. В команде были полные разброд и шатание, инженеры не умели базовых вещей: чем сеньористее было звание, тем больше были пробелы, и тем яростнее такие инженеры воспринимали критику, предпочитая всячески вокруг себя мутить job security. На удачу в команде оказались два не-сеньорных полу-студента, которые быстро схватили тему и смогли заменить всех оставшихся (со стороны замененных job security вырос с простого бойкота до откровенных подковерных жалоб начальству). Историю о том, как начальство пожадничало на новый сервер, а старый закрыло в маленькой комнате без вентиляции, где в летнюю жару благополучно был потерян весь data storage, оставлю за кадром. Несмотря на все это одной третью команды удалось дать результат на 3 месяца раньше финального дедлайна (после которого обещалось всех разогнать). В итоге проект был закрыт, а наиболее адекватная часть команды была уволена, т.к. лживые отчеты директору нравились больше, чем героическая правда.
Интервьюер: вы нам не подходите. Ваш опыт не соответствует культуре нашей команды.
В контексте статьи — тот, который бы вы разместили в заголовке вакансии. Если вы посчитаете, что с этой задачей лучше всего справится разработчик на VBA, то VBA ;).
Подозреваю, что знание C/C++ было бы в разделе must have, ну так, на всякий случай.
Вставки вставками, но real-time накладывает ограничения на все приложение, а не только на некоторые процедуры. Как минимум, нужен адекватный менеджер памяти без сборщика мусора.
Сомнителен антирейтинг C/C++. Во-первых, их нечем заменить: на ассемблере что ли предлагаете real-time разрабатывать? Во-вторых, у них высокий порог вхождения, и низкие зарплаты не оправданы ничем, кроме провальности проектов, эти позиции предлагающих. Или иначе: невозможностью нанять адекватных профессионалов и довольствование дешевыми; при этом невозможностью заменить технологию более простой.
Плюсы с точки зрения изучения хороши емкостью инвестиций времени: изучать можно долго и много, и постоянно повышая собственную ценность. Ну и опять же: замена не подоспела.
Использовать ли ASCII графику или текст — это вторично; главное, чтобы понятно было.
Мне другое интересно: как заставить разработчика тратить чуть больше времени на описание коммитов, нежели на формальное «Update blablabla». По моему опыту сопротивление этой практике со стороны команды очень сильное.
Ревью кода в тот же день — практика сомнительная. Лично я разрешаю сотрудникам тяпляпать что им угодно и как им угодно дотех пор, пока они не будут готовы дать отмашку на ревью. И вот тогда-то начинаю придираться.
В противном случае человек больше думает о форме, но не о содержании.
«Данная статья является кратким обзором...»
Если вдаваться в подробности, то придется рассказывать основы молекулярной биологии, например, какую именно рестриктазу применяли для того, чтобы бактерия могла «резать» свой ДНК, какой именно ген модифицировали, как отсеивали немодифицированных бактерий и т.д. Думаю, эти подробности будут неинтересны техническому сообществу, которых на сайте большинство.
Общая идея статьи: простые и всем известные задачи могут найти совершенно иное применение в областях, никак не связанных с первоначальной областью применения.
Поскольку я ярый поборник дисциплины в использовании Git, написании точных и осмысленных комментариев, я бы хотел использовать ссылку на данную разработку как пример антипаттерна. Буду очень благодарен, если вы приведете пример комментария, который система выдает на коммит, содержащий сортировку пузырьком.
Чтобы немного подсластить пилюлю: с академической точки зрения работа интересная. Возможно, она имеет смысл для аннотирования старого легаси кода. Но ее практическое применение именно для автоматической генерации сообщений к новому коммиту способно нанести немалый вред.
Что же предлагается:
Ой! Ненавижу такие задания. Вместо одного часа лимитированного по времени задания тебе теперь приходится делать уже неограниченную сверху работу, вылизывать каждую строчку в меру своего перфекционизма и угадывать, на что же именно будут обращать внимание. IMHO лучше время от времени поддерживать свои базовые навыки в надлежайшем состоянии, чтобы при случае не испугаться какого-нибудь динамического программирования… И времени уходит меньше, и на порядок полезнее.
«Назовите самый challenging проект». Ну извольте: работал в токсичной компании в наспех собранной команде (по рассказам, большую ее часть набирал директор, не имеющий технического образования, руководствовался только резюме, на собеседованиях знаний не проверял, ибо не имел компетенций). На момент моего присоединения к команде та успела продолбать все сроки. В итоге, с одной стороны, ты ни в чем не виноват, с другой — с тебя требуют результат уже завтра (с явным видом, что бы опоздал еще вчера, до того, как прислал им резюме). В процессе выясняется, что с командой полностью отсутствовала обратная связь, и о том, что в ней происходит, начальство узнавало исключительно из редких отчетов (никаких демонстраций не было отродясь). При ближайшем рассмотрении оказалось, что первая половина этих отчетов — выдавание желаемого за действительное, а вторая половина — откровенная ложь. Часть работ, про которые начальство было уверено, что у нас все сделано от и до, даже не была начата (при том, что успешное окончание было отрапортовано). Не шучу. В команде были полные разброд и шатание, инженеры не умели базовых вещей: чем сеньористее было звание, тем больше были пробелы, и тем яростнее такие инженеры воспринимали критику, предпочитая всячески вокруг себя мутить job security. На удачу в команде оказались два не-сеньорных полу-студента, которые быстро схватили тему и смогли заменить всех оставшихся (со стороны замененных job security вырос с простого бойкота до откровенных подковерных жалоб начальству). Историю о том, как начальство пожадничало на новый сервер, а старый закрыло в маленькой комнате без вентиляции, где в летнюю жару благополучно был потерян весь data storage, оставлю за кадром. Несмотря на все это одной третью команды удалось дать результат на 3 месяца раньше финального дедлайна (после которого обещалось всех разогнать). В итоге проект был закрыт, а наиболее адекватная часть команды была уволена, т.к. лживые отчеты директору нравились больше, чем героическая правда.
Интервьюер: вы нам не подходите. Ваш опыт не соответствует культуре нашей команды.
Подозреваю, что знание C/C++ было бы в разделе must have, ну так, на всякий случай.
Плюсы с точки зрения изучения хороши емкостью инвестиций времени: изучать можно долго и много, и постоянно повышая собственную ценность. Ну и опять же: замена не подоспела.
К сожалению, ничего это не значит, кроме отсутствия дисциплины в команде.
Мне другое интересно: как заставить разработчика тратить чуть больше времени на описание коммитов, нежели на формальное «Update blablabla». По моему опыту сопротивление этой практике со стороны команды очень сильное.
В противном случае человек больше думает о форме, но не о содержании.
Знания лишними не бывают. Но ты решаешь эти задачи на собеседовании (легко и слету), а на работу тебя все равно не берут. Потому что Google.
Где-то в сети я видел красивую флешку, где эксперимент демонстрируется в игровой форме, если найду, тоже дам ссылку.
Если вдаваться в подробности, то придется рассказывать основы молекулярной биологии, например, какую именно рестриктазу применяли для того, чтобы бактерия могла «резать» свой ДНК, какой именно ген модифицировали, как отсеивали немодифицированных бактерий и т.д. Думаю, эти подробности будут неинтересны техническому сообществу, которых на сайте большинство.
Общая идея статьи: простые и всем известные задачи могут найти совершенно иное применение в областях, никак не связанных с первоначальной областью применения.