Неэффективно: "Коллеги, по задаче №2: говорили, что будет человек. Подскажите, когда появится?"
Эффективно: "Иван Иванович, в этом месяце мне нужен программист для разработки программы лояльности (задача №2). Когда дадите?"
В чём разница?
- Ответственное лицо. В первом варианте каждый коллега подумает, что ответит кто-нибудь другой, более осведомлённый, и ответа вы не получите. - Сроки. Ведь ответ "в ближайшее время" вас не устроит. - Суть задачи. Что там было в задаче номер два кроме вас уже никто не помнит. Коллеги полезут в жиру и отвлекутся на свои задачи.
Говорите не с конца, а с главного. Счёт матча — не конец, счёт матча — главное. Не пытайтесь найти волшебный шаблон, думайте.
Я делаю это, чтобы не писать дополнительных геттеров. Защищаться от программиста дело неблагодарное, а соблюдать правила ради правил утомительно. Если вы пишете публичную библиотеку, то можете реализовать метод `Data() OrderData` и возвращать копию состояния, гарантируя чтобы в ней не оказалось указателей на исходные данные. Но по мне проще принять несовершенство мира и сосредоточится на решении действительно важных проблем.
Если вам нужен человек, кодирующий задачки с литкода, — лайвкодинг. Если вам нужен человек, который будет готовится к вашему собесу (лояльный), — лайвкодинг. Если ван нужен человек с железными нервами — лайвкодинг. В некоторых компаниях эти навыки важны.
Но если вам нужен программист, который сможет писать запросики в базу, интеграцию по http, автоматизацию всякую, то предложите ему ревью. Он вам на нём и про базовые структуры данных, и про ооп-шаблоны, и про оптимизацию запросов в бд расскажет. А на лайвкодинге он облажается и уйдёт с мыслью, что вы компания тщеславных идиотов (не потому что это так, а потому что он так почувствует).
Какие-то советы у вас капитанские. Неужели нет ничего конкретного?
Например такого: В одной компании вместо тестового или лайвкодинга мы предлагали программистам провести ревью заранее подготовленного кусочка кода. На это испытание соглашались все кандидаты. Искать чужие ошибки гораздо приятнее, чем делать свои. Многие в процессе ревью раскрывали свои убеждения и навыки гораздо охотнее, чем во время обычной беседы. В коде были как очевидные ошибки, так и более тонкие, и даже слабому программисту было что сказать по делу. В итоге кандидатам было интересно, а собеседующим сразу видно специалиста, который в первую очередь заметил опасный баг, а не вцепился в код-стайл.
Если ваши кандидаты не хотят делать тестовое, попробуйте предложить им ревью. Кусочек кода должен быть небольшим и содержать разные проблемы. Спрашивайте кандидата как можно было бы избежать проблем, которые он находит (например добавить линтер, написать автотесты). Очень хорошим оказался вопрос: "Это все правки? Релизим?". Неопытные специалисты боялись принять решение и просили ещё время (если вы ищете сеньора, то такие вам не подходят).
В статье упомянут plantuml. Это не документация по разным видам диаграмм, а целый язык описания диаграмм простым текстом. Это маркдаун для uml. Очень крутая штука. Рендерить plantuml умеет planttext.com и плагин вашей IDE.
Диаграммы последовательности и классов настолько простые в plantuml, что их можно добавлять в описание задач или скидывать в чат даже без рендеринга.
Если вас травят в пул-реквестах за сокращения в именах переменных и функций, то можно схитрить. Вместо того чтобы создавать маленькие функции в ограниченном контексте, можно писать портянки с красноречивыми именами из префиксов и суффиксов. Делайте вид, что следуете заветам Стива Макконнелла. Например `discountedProducts` или даже `discountedProductsForUncofirmedUsers`.
Говорите по делу
Неэффективно: "Коллеги, по задаче №2: говорили, что будет человек. Подскажите, когда появится?"
Эффективно: "Иван Иванович, в этом месяце мне нужен программист для разработки программы лояльности (задача №2). Когда дадите?"
В чём разница?
- Ответственное лицо. В первом варианте каждый коллега подумает, что ответит кто-нибудь другой, более осведомлённый, и ответа вы не получите.
- Сроки. Ведь ответ "в ближайшее время" вас не устроит.
- Суть задачи. Что там было в задаче номер два кроме вас уже никто не помнит. Коллеги полезут в жиру и отвлекутся на свои задачи.
Говорите не с конца, а с главного. Счёт матча — не конец, счёт матча — главное. Не пытайтесь найти волшебный шаблон, думайте.
Я делаю это, чтобы не писать дополнительных геттеров. Защищаться от программиста дело неблагодарное, а соблюдать правила ради правил утомительно. Если вы пишете публичную библиотеку, то можете реализовать метод `Data() OrderData` и возвращать копию состояния, гарантируя чтобы в ней не оказалось указателей на исходные данные. Но по мне проще принять несовершенство мира и сосредоточится на решении действительно важных проблем.
Если вам нужен человек, кодирующий задачки с литкода, — лайвкодинг. Если вам нужен человек, который будет готовится к вашему собесу (лояльный), — лайвкодинг. Если ван нужен человек с железными нервами — лайвкодинг. В некоторых компаниях эти навыки важны.
Но если вам нужен программист, который сможет писать запросики в базу, интеграцию по http, автоматизацию всякую, то предложите ему ревью. Он вам на нём и про базовые структуры данных, и про ооп-шаблоны, и про оптимизацию запросов в бд расскажет. А на лайвкодинге он облажается и уйдёт с мыслью, что вы компания тщеславных идиотов (не потому что это так, а потому что он так почувствует).
Не всем нужен Рембрандт :-)
Какие-то советы у вас капитанские. Неужели нет ничего конкретного?
Например такого:
В одной компании вместо тестового или лайвкодинга мы предлагали программистам провести ревью заранее подготовленного кусочка кода. На это испытание соглашались все кандидаты. Искать чужие ошибки гораздо приятнее, чем делать свои. Многие в процессе ревью раскрывали свои убеждения и навыки гораздо охотнее, чем во время обычной беседы. В коде были как очевидные ошибки, так и более тонкие, и даже слабому программисту было что сказать по делу. В итоге кандидатам было интересно, а собеседующим сразу видно специалиста, который в первую очередь заметил опасный баг, а не вцепился в код-стайл.
Если ваши кандидаты не хотят делать тестовое, попробуйте предложить им ревью. Кусочек кода должен быть небольшим и содержать разные проблемы. Спрашивайте кандидата как можно было бы избежать проблем, которые он находит (например добавить линтер, написать автотесты). Очень хорошим оказался вопрос: "Это все правки? Релизим?". Неопытные специалисты боялись принять решение и просили ещё время (если вы ищете сеньора, то такие вам не подходят).
В статье упомянут plantuml. Это не документация по разным видам диаграмм, а целый язык описания диаграмм простым текстом. Это маркдаун для uml. Очень крутая штука. Рендерить plantuml умеет planttext.com и плагин вашей IDE.
Диаграммы последовательности и классов настолько простые в plantuml, что их можно добавлять в описание задач или скидывать в чат даже без рендеринга.