В целом согласен, но акцент бы усилил на размере команды: для команды из 3 человек писать самому можно и нужно (менеджерская составляющая будет еще незначительной), а в команде больше 7 человек лучше сосредоточиться только на лидских активностях.
И от фазы продукта зависит: после выхода в прод менеджерская нагрузка возрастает.
Если я правильно помню Доктора Хауса, слушать музыку и играть музыку - разные неврологические процессы и задействуют разные области мозга :)
Даже такая инженерная задача, как написание кода, все равно предполагает выбор из нескольких относительно равноправных вариантов решения и является более творческой, чем ревью.
Спасибо за вопрос, @Caraul! Вы мне им прекрасную идею для размышлений подкинули - почему люди с развитыми софт-скилами задерживаются все-таки подольше (ну или мне так показалось).
Из того, что требуется непосредственно в работе: допытаться от аналитиков, от бизнеса, от архитектуры чего же именно те хотят? Пинговать, пушить, задавать правильные вопросы, фиксировать уточнения постановки в трекере и т.д.
Далее, уметь отстоять свои интересы. Если что-то не удобно, то прийти на ретро и объяснить команде свою позицию и быть убедительным, чтобы тебя поняли и исправили процессы внутрикомандные (например, подход к ревью или написанию тестов). Если мало денег - прийти и убедить их повысить, а не сразу обновлять резюме.
Еще - уметь говорить нет. Например, когда тебе пишут в нерабочее время и просят срочно-срочно.
Словом, столько всяких кейсов на ум приходит, что тут на еще одну статью наберется... to be continued :)
Спасибо, @JustDont, за оживленную дискуссию по этому поводу.
Уж не знаю видна ли вам вся ироничность этого холивара, но в том же абзаце, который вызвал такой насыщенный отклик, есть фраза:
Но не только маркер, это проверка насколько мы с кандидатом говорим на одном языке.
Если Вам не нравится терминология на проекте, значит не стоит туда идти. И это отлично, что все прояснилось на собесе - меньше разочарований. А значит слово достигло своей цели: помогло принять решение (в данном случае кандидату)
За 60 минут конечно ничего толком не понять, но большего мне не даст рынок труда! Будет понятно только если кандидат полный ноль. В остальных же случаях - это конечно только домыслы и предположения, основанные на своем опыте. Но разве это значит, что нужно сложить руки и положиться на удачу? На мой взгляд - нет. Есть способы, повышающие достоверность "кофейной гущи" и своим набором ингредиентов я тут поделился.
У кого-то принципиально иной опыт и набор ингредиентов будет другим. Все специфично.
Мне бы очень о многом хотелось поговорить с кандидатом, но у меня всего лишь час. А все последние проекты у меня сугубо прикладные. Поэтому я фокусируюсь на вопросах, которые позволят мне понять сможет ли он мне "с порога" начать запиливать мои реальные прикладные таски. Я и по java core конечно тоже спрашиваю, просто цепочку вопросов начинаю раскручивать не с этого.
Кстати, в статье были разные примеры. Создание иммутабельных объектов, например. А от спринговых бинов реквестового скоупа на ThreadLocal можно перейти. С синглтонов - на double check locking и на reordering в JMM. Главное вести беседу органично и вокруг того, что мне интересно от кандидата в работе.
Ну почему же "от балды"? Это слово обычно употребляется в словосочетании "дернуть ручку", а оно порождает довольно понятный ассоциативный ряд.
Endpoint - хороший вариант, но немного длинный и менее удобный для произношения. Впрочем это вкусовщина.
А вот роут мне для этого случая не нравится после apache camel - совершенно другие ассоциации.
Вариант хэндлера принять проще, но он уж больно общий: этим словом и message driven и event driven подходы можно окрестить. И даже exception handler - тоже хэндлер. Не передает оно специфики.
В этом плане замечание @YourChief понятно (про крутилку настроек). Ассоциация понятна. Но тут просто другой опыт.
Полностью согласен! Когда со всех сторон 100500 приглашений, утруждаться решением тестовых заданий не каждый захочет. Только если уж оооочень интересна вакансия. Ну или из чисто спортивного интереса, если задачка любопытная.
Все надо постараться понять и принять решение за час собеседования. Про то и статья.
@KGeist, не суть. Это некий намек, сигнал, который всего лишь нужно проверить. Он может подтвердиться или нет. В любом случае - собеседование это попытка понять опыт соискателя "с колокольни" своего опыта и тут нет безусловного эталона.
Роут - это про что-то типа Camel скорее. А термин "ручка" значительно более древний, чем пара лет. И по моему опыту он более распространен. Однако повторюсь, это всего лишь намек - ничего фатального из этого не следует.
Вот тут есть некоторое отличие в степени категоричности: для меня незнание сленга лишь "намекает", а Вы "делаете вывод". Если появились намеки, сигналы и сомнения, то можно задержаться на вопросе чуть дольше и прояснить.
Если о том, как я набираю аналитиков и/или архитекторов, то бывает это нечасто и я присутствую на собесе "вторым номером". А проводит его тот, кому я доверяю - в смысле с кем наши подходы и взгляды совпадают.
Видимо мне еще есть куда расти в софт-скилах - наверное не сумел подать идею достаточно прозрачно. Фокус как раз в том, что есть категория вопросов, на которые отвечают не то, что думают, а то, что считают правильным ответом. И тут нужно быть более изобретательным. По моему опыту проективные интервью - это очень полезная техника, которой нужно уметь владеть.
Что касается личного времени, то я очень дорожу своим и уважаю в каждом право ни личную жизнь, на хобби и т.п.
Я бы не сказал, что это противоположные взгляды - они вполне могут дополнять друг друга.
И посмотреть в реальном времени, как человек рассуждает и набирает код - тоже интересная практика. Благо даже специальные онлайн-сервисы для этого есть и даже Идея для этого не обязательна.
В целом согласен, но акцент бы усилил на размере команды: для команды из 3 человек писать самому можно и нужно (менеджерская составляющая будет еще незначительной), а в команде больше 7 человек лучше сосредоточиться только на лидских активностях.
И от фазы продукта зависит: после выхода в прод менеджерская нагрузка возрастает.
Если я правильно помню Доктора Хауса, слушать музыку и играть музыку - разные неврологические процессы и задействуют разные области мозга :)
Даже такая инженерная задача, как написание кода, все равно предполагает выбор из нескольких относительно равноправных вариантов решения и является более творческой, чем ревью.
Спасибо за вопрос, @Caraul! Вы мне им прекрасную идею для размышлений подкинули - почему люди с развитыми софт-скилами задерживаются все-таки подольше (ну или мне так показалось).
Из того, что требуется непосредственно в работе: допытаться от аналитиков, от бизнеса, от архитектуры чего же именно те хотят? Пинговать, пушить, задавать правильные вопросы, фиксировать уточнения постановки в трекере и т.д.
Далее, уметь отстоять свои интересы. Если что-то не удобно, то прийти на ретро и объяснить команде свою позицию и быть убедительным, чтобы тебя поняли и исправили процессы внутрикомандные (например, подход к ревью или написанию тестов). Если мало денег - прийти и убедить их повысить, а не сразу обновлять резюме.
Еще - уметь говорить нет. Например, когда тебе пишут в нерабочее время и просят срочно-срочно.
Словом, столько всяких кейсов на ум приходит, что тут на еще одну статью наберется... to be continued :)
Спасибо, @JustDont, за оживленную дискуссию по этому поводу.
Уж не знаю видна ли вам вся ироничность этого холивара, но в том же абзаце, который вызвал такой насыщенный отклик, есть фраза:
Если Вам не нравится терминология на проекте, значит не стоит туда идти. И это отлично, что все прояснилось на собесе - меньше разочарований. А значит слово достигло своей цели: помогло принять решение (в данном случае кандидату)
За 60 минут конечно ничего толком не понять, но большего мне не даст рынок труда! Будет понятно только если кандидат полный ноль. В остальных же случаях - это конечно только домыслы и предположения, основанные на своем опыте. Но разве это значит, что нужно сложить руки и положиться на удачу? На мой взгляд - нет. Есть способы, повышающие достоверность "кофейной гущи" и своим набором ингредиентов я тут поделился.
У кого-то принципиально иной опыт и набор ингредиентов будет другим. Все специфично.
Мне бы очень о многом хотелось поговорить с кандидатом, но у меня всего лишь час. А все последние проекты у меня сугубо прикладные. Поэтому я фокусируюсь на вопросах, которые позволят мне понять сможет ли он мне "с порога" начать запиливать мои реальные прикладные таски. Я и по java core конечно тоже спрашиваю, просто цепочку вопросов начинаю раскручивать не с этого.
Кстати, в статье были разные примеры. Создание иммутабельных объектов, например. А от спринговых бинов реквестового скоупа на ThreadLocal можно перейти. С синглтонов - на double check locking и на reordering в JMM. Главное вести беседу органично и вокруг того, что мне интересно от кандидата в работе.
Ну почему же "от балды"? Это слово обычно употребляется в словосочетании "дернуть ручку", а оно порождает довольно понятный ассоциативный ряд.
Endpoint - хороший вариант, но немного длинный и менее удобный для произношения. Впрочем это вкусовщина.
А вот роут мне для этого случая не нравится после apache camel - совершенно другие ассоциации.
Вариант хэндлера принять проще, но он уж больно общий: этим словом и message driven и event driven подходы можно окрестить. И даже exception handler - тоже хэндлер. Не передает оно специфики.
В этом плане замечание @YourChief понятно (про крутилку настроек). Ассоциация понятна. Но тут просто другой опыт.
Какой неожиданно бурный отклик вызвало ничем непримечательное слово "ручка" :)
Спасибо за обратную связь, коллеги, пусть и на неожиданном месте!
Полностью согласен! Когда со всех сторон 100500 приглашений, утруждаться решением тестовых заданий не каждый захочет. Только если уж оооочень интересна вакансия. Ну или из чисто спортивного интереса, если задачка любопытная.
Все надо постараться понять и принять решение за час собеседования. Про то и статья.
Спасибо за позитивный отзыв, @dimskiy!
Если это поможет сберечь хотя бы часок-другой на интервью - уже все не зря :)
@KGeist, не суть. Это некий намек, сигнал, который всего лишь нужно проверить. Он может подтвердиться или нет. В любом случае - собеседование это попытка понять опыт соискателя "с колокольни" своего опыта и тут нет безусловного эталона.
Роут - это про что-то типа Camel скорее. А термин "ручка" значительно более древний, чем пара лет. И по моему опыту он более распространен. Однако повторюсь, это всего лишь намек - ничего фатального из этого не следует.
Вот тут есть некоторое отличие в степени категоричности: для меня незнание сленга лишь "намекает", а Вы "делаете вывод". Если появились намеки, сигналы и сомнения, то можно задержаться на вопросе чуть дольше и прояснить.
@ChePeter, я, извиняюсь, вопроса не понял :)
Если о том, как я набираю аналитиков и/или архитекторов, то бывает это нечасто и я присутствую на собесе "вторым номером". А проводит его тот, кому я доверяю - в смысле с кем наши подходы и взгляды совпадают.
@dopusteam, удовлетворите любопытство пожалуйста, а как Вы называете эндпоинты? Я имею в виду в повседневности, когда с коллегами что-то обсуждаете.
Видимо мне еще есть куда расти в софт-скилах - наверное не сумел подать идею достаточно прозрачно. Фокус как раз в том, что есть категория вопросов, на которые отвечают не то, что думают, а то, что считают правильным ответом. И тут нужно быть более изобретательным. По моему опыту проективные интервью - это очень полезная техника, которой нужно уметь владеть.
Что касается личного времени, то я очень дорожу своим и уважаю в каждом право ни личную жизнь, на хобби и т.п.
Спасибо за отзыв, Дмитрий!
Я бы не сказал, что это противоположные взгляды - они вполне могут дополнять друг друга.
И посмотреть в реальном времени, как человек рассуждает и набирает код - тоже интересная практика. Благо даже специальные онлайн-сервисы для этого есть и даже Идея для этого не обязательна.