A. Rudenets

О, радует, что моя позиция по этому вопросу откликается в других людях. Тоже придерживаюсь именно этой истории. Но тут вот какое дело: чтобы понять, что человек перекрывает слабые стороны команды, нанимающему специалисту нужно хотя бы на уровне теории всё равно погрузиться в тему, где произошёл провал по квалификациям, чтобы смочь составить предметный разговор и сбрить ребят, которые и сами ничего не понимают.

Крутейшая статья о том, почему программировать что-то, что связано со временем, как-то тяжеловато. С историями, примерами и даже решениями некоторых проблем.

В общем-то посты о том, чего я не знаю, я могу больше не писать. В этом т.н. «минимуме» упаковано материала на десятки лет вперёд, и до пенсии этих тем мне точно хватит :)) Осталось только понять, зачем.

Та структура собеседования, которая описана в статье, отчасти напоминает тот процесс, к которому я в конце концов пришёл по ходу кампании найма сотрудников в Trucker.

Не так давно мне предложили собрать команду из новых разработчиков и стать её тимлидом. Я начал общаться с кандидатами, опираясь на старую структуру собеседования, которую разработал ещё на прошлом месте работы. Однако я быстро понял, что нанимать своих клонов и задавать закрытые вопросы прямо как на экзамене – плохая идея.

Цель тимлида в таких ситуациях – собрать команду, которая будет решать любые задачи бизнеса. Для того, чтобы это обеспечить, команде нужны совершенно разные компетенции, а не только те, в которых силён её руководитель. Надеюсь, что скоро допишу пост, где расскажу свой рецепт для технического собеседования, к которому я пришёл за эти полтора месяца, и опишу мысли, чего мне в нём не хватает.

В воздухе давно витает идея перенять для разработки ПО практику журналирования архитектурных решений у «аналоговых» архитекторов — тех самых, которые проектируют дома. И вот, кажется, хорошая методика, по которой можно вести эти самые архитектурные журналы. Возьму на вооружение.