1) На молчание в чате на неработающую кнопку должен отвечать pm проекта, потому что на нем сроки и приотиризация задач. Максимум, в случае если эта кнопка приносит миллионы долларов в секунду, должны дергаться причастные к неработе, да и то через свою иерархию, а не напрямую.
2) Боссу варианты предлагают уже не разработчики, а лиды, продуктологи, архитектурный комитет или кто там еще. Когда разработчик начинает это делать самолично, он чаще всего огребет проблем, т.к. его резко перекинут реализовывать выдвинутые им варианты без нормальной детализации, т.к. "ну ты сам лучше знаешь, ты же инициативный". Разработчику будет гораздо полезнее выдвигать предложения в его команде при груминге или детализации задач, нежели при общении с боссом.
В остальных пунктах диалоги идут непосредственно не с разработчиками, а с какими-то лидами,ВП, котами.
В статье ни одного полезного примера общения с разработчиками, но начинается она с упрека в их сторону. Удивительная профдеформация написавшего эту статью БОССА.
Речь ведь не об идеальном мире. Понятное дело, что идеальных компаний очень мало и у каждого свое представление идеального мира. Речь о балансе между основными обязанностями (писать код и поддерживать функционал) и второстепеннонавязанными (погружение в доменную область, аналитика, менеджмент).
Обычно когда от разработчика начинают требовать очень много второстепенного, начинаются различные внутренние (а тем ли я в этой жизни занимаюсь?) и внешние (конфликты с навязывателями обязанностей и постоянное уточнение того, чем ты в итоге должен заниматься) разногласия, что очень усложняет жизнь.
В текущих реалиях это уже не так. Можно проявлять инициативу и быть славным скакуном, на котором будут ездить годами без плюшек и перспектив (встречался с такими - печальное зрелище), а можно не выходить за рамки своих обязанностей и через время сменить работу на более комфортную и высокооплачиваемую просто придя на собеседование в другое место.
Для разработчиков повышение сейчас иногда приобретает негативный характер. Повышают до лида, при этом повысив зарплату до среднеразработческой по рынку, но при этом начинают требовать так, будто обеспечили старость человеку беззаботную.
Почему-то такую технику осуперменивания разработчиков я встречал в компаниях, где разработчики занимались кодированием меньшую часть своего рабочего времени (2-3 часа), а остальную часть как раз и занимало это осуперменивание. Сюда входят погружение в домен, погружение в корп. культуру, море встреч разной степени полезности (которого никак не избежать, если от разработчиков требуют суперменства). Это все очень сильно выматывало эмоционально, а результат все равно получался посредственным.
Для меня наоборот является негативным моментом, если компания слишком пропитана своей продуктовостью и хочет ей пропитывать всех вплоть до уборщицы. Как правило, в таких компаниях все занимаются всем, но не тем, что у них прописано в трудовом договоре и на что они договаривались при найме. И текучка там огромная из-за постоянных осупермениваний, которые в целом приводят адским переработкам и последующему выгоранию.
Далеко не так.
Возможно, ты получаешь нематериальные блага в виде комфортной работы и становления процессов. Но на этапе этого становления у тебя будет вытрепано достаточно нервов, и потребуется разрешить очень много конфликтных ситуаций, связанных с тем, что другие участники коллектива не настроены на улучшение процессов. Далеко не все улучшаторы выдерживают такой нагрузки и в итоге выгорают.
Возможно, ты получаешь материальные блага. Но видя инициативу от сотрудника, начальство лишь нагружает его доп. обязанностями из-за своей проф. деформации в виде того, что само начальство не имеет четкого списка обязанностей. А когда заходит речь о повышении выясняется, что сменить работу для этого гораздо выгоднее. Да и обязанностей там будет поменьше при бОльшей оплате.
Я считаю, что мысли изложенные в статье подходят для людей, которые наделены управленческими лычками, но ни в коем случае для рядовых подчиненных. Как бы рядовой сотрудник ни старался делать свою работу качественно и стать заменимым, его порывы выливаются в очень конфликтные и порой невыносимые рабочие условия. И лишь небольшой процент действительно оценивается должным образом с соответсвующими материальными и нематериальными компенсациями.
Тут вопрос в том, насколько гибкими собеседования будут для компании. Например, мы задаем задачки про алгоритмы и структуры данных. Это самый низкий уровень, который не имеет отношение к специфике разработки, сфере деятельности компании, предыдущему опыту работы. Соответственно, проводить подобные собеседования может большее количество людей. Это более масштабируемая схема найма, хотя и не коррелирует с реальными навыками людей программировать серьезные проекты.
Я предполагаю, что большим корпорациям часто не столь важен специфичный опыт. Им удобна стандартизация. Вопрос про проектирование модуля очень сильно может быть привязан к специфике языка, его инструментов (у корпораций свое море внутренних библиотек), и в целом отношения к проектированию и кодированию в компании (например, в одной допустимы небольшие нарушения инкапсуляции для общения между модулями, а в другой за этим строго следят и не допускают их). Потому и задают вопросы, которые имеют отношение к программированию в целом, но не имеют отношения к реальным проектам.
И да, многие сеньоры могут не подходить большой компании именно по причине своего специфичного опыта и некоторой закостенелости в плане сформировавшегося вкуса к написанию кода, потому что им будет сложнее переучиться на иные подходы к разработке, которые сформировались в этой компании.
Чем крупнее компания, тем больше вероятность нарваться на задачки и вопросы, ответы на которые никак не расскажут о тебе как о специалисте.
С одной стороны понятно: поток резюме от разных проходимцев и людей, которые хотят войтивайти у таких компаний огромен. И для упрощения процедуры фильтрации этого потока делается эта стандартизация с однотипными вопросами и задачками, которые бессмысленны по своей сути. С другой стороны, у людей с достаточным опытом в сфере это чаще вызывает негатив, потому что они знают процессы и то, что задачки им не пригодятся в дальнейшем, а нужны лишь для прохождения собеседования.
У компаний поменьше размером такое встречается реже, но бывает. Там больше вопросов из теории и практики современных подходов к разработке. Они в целом гибче относятся к найму. И там очень много горячих предложений для сеньоров с менее изматывающим процессом найма.
Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.
Да никак не записана. В большинстве случаев это просто навязывание дополнительных должностных обязанностей. Но многие программисты соглашаются на это, потому что это своего рода дополнительная ачивка на предыдущем месте работы (мол, допустили), строчка в резюме и довольно полезный опыт. Человек начинает по другому относиться к собеседованиям, если побывал с двух сторон баррикад.
Я больше сталкивался с формулировкой «на любом языке».
В любом случае, я никогда себя не чувствую комфортно при написании кода на листочке — руки под клавиатуру заточены. Даже если это элементарные sql-запросы. Вспоминаются курсы паскаля в старших классах сразу. Вот там нас за каждую пропущенную точку с запятой в тетрадке гнобили и занижали оценки :)
Самые хорошие впечатления у меня от собеседований в форме диалога. Где людям был интересен мой опыт, и где по моему опыту задавались соответствующие вопросы из разряда «А как было это реализовано? А с какими проблемами при реализации столкнулись? А как бы сейчас сделали?». И соответствующие теоретические вопросы по стеку технологий, чтобы понять, насколько глубоко я погружен в ту или иную область. Сразу понимаешь уровень специалиста, который задает тебе вопросы и рулит собеседованием. И порой из-за одних вопросов и объяснений от таких людей уже возникает желание с ними работать.
Что касаемо кода на листочках — это полный швах. Сначала я был разочарован в себе и сильно подавлен подобными задачами. Но заметил одну закономерность: туплю при решении, но по приходу домой код с решением задачи пишется как по маслу. Может, сказывается то, что я думаю о решении после фейла, и задача для меня становится не свежей. А может и то, что обстановка не та, сосредотачиваешься на форматировании кода, кривом почерке и каляках-маляках из-за того что ручку в основном используешь при схематичном отображении чего-либо или когда надо расписаться. Решил вообще не париться и никогда не решать задачи на листочках, если только это не совсем какая-то элементарщина из одной функции. Всегда перед назначением собеседования спрашиваю про его формат, и отвечаю отказом если мне говорят о паре задач на листочках.
Тестовые задания же вообще очень ненадежная вещь. Встречался с тем, что делал тестовое задание дня три, потом мне назначили собеседование, и никто на нем не знал, что тестовое задание мной было выполнено. Т.е. hr тупо проверила наличие файла с результатом, а дальше никуда тестовое мое не пошло. Встречался с тем, что не спал четыре ночи и как угорелый проектировал архитектуру, вылизывал код, покрывал его тестами, а бизнес-задачу понял немного не так, и все мои труды завернули за минут 10. Самые приемлимые тестовые задания я получал только после успешных собеседований с теоретическими и практическими вопросами. Они были небольшие, на час-два времени, но при хорошем впечатлении о фирме после собеседования всегда была мотивация их сделать.
А мне нравится такой подход. Взять готовые популярные библиотеки и адаптировать под свой каркас с необходимыми интеграциями. Сделать свое ядро на основе хорошо работающих и протестированных решений от других разработчиков, предоставив интерфейсы модулям для инициализации приложения.
Делали так на одном проекте (rest api). Очень понравился результат. Код стал намного чище и гибче.
В России можно смело заменить «вопросы к HR» на «вопросы к руководящему технарю».
Ни один из вышеперечисленных вопросов я не задавал непосредственно HR. HR — это в основном согласование времени собеседования, небольшая вводная по организационным вопросам, проверка на общую адекватность и передача кандидата технарям на растерзание :)
Зато почти половину вопросов на собеседовании задавал людям, с которыми в последствии работал в команде или мне пришлось бы с ними работать. Только они знали ответы, и только их реакцию можно было анализировать. Да и вообще в 80% российских компаний технари являются самым ключевым звеном на собеседованиях (я имею в виду технические должности), и всю информацию нужно тянуть из них.
Но список вопросов очень толковый, учел что-то для себя. Спасибо.
Именно так. Даже более того: монолитная архитектура сэкономит очень много времени, т.к. зачастую внутри все протестировано, и за вами остается только тестирование слоя домена, не углубляясь в дебри ядра. Экономия времени на интеграцию, но можно наткнуться на проблемы роста. Зависит от темпа развития проекта.
Монолит предоставляет или диктует архитектуру постройки приложения. У всех его компонентов и расширений есть интерфейсы для этого. Когда начинаешь отходить от того, что предоставляет фреймворк, рано или поздно приходишь к своему набору библиотек, и сам фреймворк становится не сильно нужен. Разве что отдельные компоненты от него.
Другое дело, что некоторые проекты можно писать в рамках фреймворка и его расширений. И функционала будет достаточно. В таких случаях монолит хороший выбор.
Потому что интерфейсы приложения очень часто выходят за пределы интерфейсов PSR. Например, работа с правами доступа, аутентификация, расширение уникальных типов для абстракций доктрины, регистрация уникальных VO для модулей и т.д. Те же правила роутинга пишутся по разному от библиотеки к библиотеке.
В основном три причины:
— Избыточность, протекание абсолютно ненужного функционала на доменный слой. Может навредить, потому что предоставляет все возможности его причинить.
— Недостаток какого-либо функционала, который необходим. Например, добавить в роутере версионирование api.
— Более строгий интерфейс, который предостережет от множества ошибок в будущем.
Слой приложения
— Создаем интерфейс компонента для приложения.
— Создаем реализацию интерфейса в слое приложения. Это может быть как самописный компонент, так и взятый с гитхаба, обернутый под текущий интерфейс приложения.
Доменный слой
— Создаем базовый bootstrap для модулей, в который инжектим необходимые для доменного слоя интерфейсы (Например, интерфесы для добавления правил роутинга, прав доступа, событийный диспатчер)
— Указываем правила роутинга, прав доступа, обработку событий для каждого отдельного модуля, у которого есть что предоставить этим компонентам.
Вот каждый компонент нужно интегрировать, и использование базового интерфейса библиотеки с гитхаба, как правило, не подходит под задачи проекта. Хоть небольшая оберточка (или большая в отдельных случаях), но будет везде.
Описанные ситуации ведь не касаются разработчика.
1) На молчание в чате на неработающую кнопку должен отвечать pm проекта, потому что на нем сроки и приотиризация задач. Максимум, в случае если эта кнопка приносит миллионы долларов в секунду, должны дергаться причастные к неработе, да и то через свою иерархию, а не напрямую.
2) Боссу варианты предлагают уже не разработчики, а лиды, продуктологи, архитектурный комитет или кто там еще. Когда разработчик начинает это делать самолично, он чаще всего огребет проблем, т.к. его резко перекинут реализовывать выдвинутые им варианты без нормальной детализации, т.к. "ну ты сам лучше знаешь, ты же инициативный". Разработчику будет гораздо полезнее выдвигать предложения в его команде при груминге или детализации задач, нежели при общении с боссом.
В остальных пунктах диалоги идут непосредственно не с разработчиками, а с какими-то лидами,ВП, котами.
В статье ни одного полезного примера общения с разработчиками, но начинается она с упрека в их сторону. Удивительная профдеформация написавшего эту статью БОССА.
Речь ведь не об идеальном мире. Понятное дело, что идеальных компаний очень мало и у каждого свое представление идеального мира. Речь о балансе между основными обязанностями (писать код и поддерживать функционал) и второстепеннонавязанными (погружение в доменную область, аналитика, менеджмент).
Обычно когда от разработчика начинают требовать очень много второстепенного, начинаются различные внутренние (а тем ли я в этой жизни занимаюсь?) и внешние (конфликты с навязывателями обязанностей и постоянное уточнение того, чем ты в итоге должен заниматься) разногласия, что очень усложняет жизнь.
В текущих реалиях это уже не так. Можно проявлять инициативу и быть славным скакуном, на котором будут ездить годами без плюшек и перспектив (встречался с такими - печальное зрелище), а можно не выходить за рамки своих обязанностей и через время сменить работу на более комфортную и высокооплачиваемую просто придя на собеседование в другое место.
Для разработчиков повышение сейчас иногда приобретает негативный характер. Повышают до лида, при этом повысив зарплату до среднеразработческой по рынку, но при этом начинают требовать так, будто обеспечили старость человеку беззаботную.
Почему-то такую технику осуперменивания разработчиков я встречал в компаниях, где разработчики занимались кодированием меньшую часть своего рабочего времени (2-3 часа), а остальную часть как раз и занимало это осуперменивание. Сюда входят погружение в домен, погружение в корп. культуру, море встреч разной степени полезности (которого никак не избежать, если от разработчиков требуют суперменства). Это все очень сильно выматывало эмоционально, а результат все равно получался посредственным.
Для меня наоборот является негативным моментом, если компания слишком пропитана своей продуктовостью и хочет ей пропитывать всех вплоть до уборщицы. Как правило, в таких компаниях все занимаются всем, но не тем, что у них прописано в трудовом договоре и на что они договаривались при найме. И текучка там огромная из-за постоянных осупермениваний, которые в целом приводят адским переработкам и последующему выгоранию.
Возможно, ты получаешь нематериальные блага в виде комфортной работы и становления процессов. Но на этапе этого становления у тебя будет вытрепано достаточно нервов, и потребуется разрешить очень много конфликтных ситуаций, связанных с тем, что другие участники коллектива не настроены на улучшение процессов. Далеко не все улучшаторы выдерживают такой нагрузки и в итоге выгорают.
Возможно, ты получаешь материальные блага. Но видя инициативу от сотрудника, начальство лишь нагружает его доп. обязанностями из-за своей проф. деформации в виде того, что само начальство не имеет четкого списка обязанностей. А когда заходит речь о повышении выясняется, что сменить работу для этого гораздо выгоднее. Да и обязанностей там будет поменьше при бОльшей оплате.
Я считаю, что мысли изложенные в статье подходят для людей, которые наделены управленческими лычками, но ни в коем случае для рядовых подчиненных. Как бы рядовой сотрудник ни старался делать свою работу качественно и стать заменимым, его порывы выливаются в очень конфликтные и порой невыносимые рабочие условия. И лишь небольшой процент действительно оценивается должным образом с соответсвующими материальными и нематериальными компенсациями.
Я предполагаю, что большим корпорациям часто не столь важен специфичный опыт. Им удобна стандартизация. Вопрос про проектирование модуля очень сильно может быть привязан к специфике языка, его инструментов (у корпораций свое море внутренних библиотек), и в целом отношения к проектированию и кодированию в компании (например, в одной допустимы небольшие нарушения инкапсуляции для общения между модулями, а в другой за этим строго следят и не допускают их). Потому и задают вопросы, которые имеют отношение к программированию в целом, но не имеют отношения к реальным проектам.
И да, многие сеньоры могут не подходить большой компании именно по причине своего специфичного опыта и некоторой закостенелости в плане сформировавшегося вкуса к написанию кода, потому что им будет сложнее переучиться на иные подходы к разработке, которые сформировались в этой компании.
С одной стороны понятно: поток резюме от разных проходимцев и людей, которые хотят войтивайти у таких компаний огромен. И для упрощения процедуры фильтрации этого потока делается эта стандартизация с однотипными вопросами и задачками, которые бессмысленны по своей сути. С другой стороны, у людей с достаточным опытом в сфере это чаще вызывает негатив, потому что они знают процессы и то, что задачки им не пригодятся в дальнейшем, а нужны лишь для прохождения собеседования.
У компаний поменьше размером такое встречается реже, но бывает. Там больше вопросов из теории и практики современных подходов к разработке. Они в целом гибче относятся к найму. И там очень много горячих предложений для сеньоров с менее изматывающим процессом найма.
Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.
В любом случае, я никогда себя не чувствую комфортно при написании кода на листочке — руки под клавиатуру заточены. Даже если это элементарные sql-запросы. Вспоминаются курсы паскаля в старших классах сразу. Вот там нас за каждую пропущенную точку с запятой в тетрадке гнобили и занижали оценки :)
Что касаемо кода на листочках — это полный швах. Сначала я был разочарован в себе и сильно подавлен подобными задачами. Но заметил одну закономерность: туплю при решении, но по приходу домой код с решением задачи пишется как по маслу. Может, сказывается то, что я думаю о решении после фейла, и задача для меня становится не свежей. А может и то, что обстановка не та, сосредотачиваешься на форматировании кода, кривом почерке и каляках-маляках из-за того что ручку в основном используешь при схематичном отображении чего-либо или когда надо расписаться. Решил вообще не париться и никогда не решать задачи на листочках, если только это не совсем какая-то элементарщина из одной функции. Всегда перед назначением собеседования спрашиваю про его формат, и отвечаю отказом если мне говорят о паре задач на листочках.
Тестовые задания же вообще очень ненадежная вещь. Встречался с тем, что делал тестовое задание дня три, потом мне назначили собеседование, и никто на нем не знал, что тестовое задание мной было выполнено. Т.е. hr тупо проверила наличие файла с результатом, а дальше никуда тестовое мое не пошло. Встречался с тем, что не спал четыре ночи и как угорелый проектировал архитектуру, вылизывал код, покрывал его тестами, а бизнес-задачу понял немного не так, и все мои труды завернули за минут 10. Самые приемлимые тестовые задания я получал только после успешных собеседований с теоретическими и практическими вопросами. Они были небольшие, на час-два времени, но при хорошем впечатлении о фирме после собеседования всегда была мотивация их сделать.
Делали так на одном проекте (rest api). Очень понравился результат. Код стал намного чище и гибче.
Ни один из вышеперечисленных вопросов я не задавал непосредственно HR. HR — это в основном согласование времени собеседования, небольшая вводная по организационным вопросам, проверка на общую адекватность и передача кандидата технарям на растерзание :)
Зато почти половину вопросов на собеседовании задавал людям, с которыми в последствии работал в команде или мне пришлось бы с ними работать. Только они знали ответы, и только их реакцию можно было анализировать. Да и вообще в 80% российских компаний технари являются самым ключевым звеном на собеседованиях (я имею в виду технические должности), и всю информацию нужно тянуть из них.
Но список вопросов очень толковый, учел что-то для себя. Спасибо.
Другое дело, что некоторые проекты можно писать в рамках фреймворка и его расширений. И функционала будет достаточно. В таких случаях монолит хороший выбор.
Домен содержит реализацию бизнес-логики и настройку приложения через интерфейсы, иногда внедряя свои зависимости для конкретных модулей.
Иными словами, мы можем легко заменить домен, оставив прим этом приложение. Но не можем заменить приложение для домена.
— Избыточность, протекание абсолютно ненужного функционала на доменный слой. Может навредить, потому что предоставляет все возможности его причинить.
— Недостаток какого-либо функционала, который необходим. Например, добавить в роутере версионирование api.
— Более строгий интерфейс, который предостережет от множества ошибок в будущем.
— Создаем интерфейс компонента для приложения.
— Создаем реализацию интерфейса в слое приложения. Это может быть как самописный компонент, так и взятый с гитхаба, обернутый под текущий интерфейс приложения.
Доменный слой
— Создаем базовый bootstrap для модулей, в который инжектим необходимые для доменного слоя интерфейсы (Например, интерфесы для добавления правил роутинга, прав доступа, событийный диспатчер)
— Указываем правила роутинга, прав доступа, обработку событий для каждого отдельного модуля, у которого есть что предоставить этим компонентам.
Вот каждый компонент нужно интегрировать, и использование базового интерфейса библиотеки с гитхаба, как правило, не подходит под задачи проекта. Хоть небольшая оберточка (или большая в отдельных случаях), но будет везде.