со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из jira" или "у меня nda". в таких случаях уже переходим на разбор моих кейсов - это обычно ревью заготовленного кода или архитектуры - из текущего проекта с долей упрощения, разумеется. да, я готовлюсь к собеседованию, и кейсы мне дает реальная практика с проектов. надо просто оправданий лени не искать. и зачастую очень любопытные и непринуждённые беседы выходят.
руководство (как говорится в расхожей фразе) хочет волшебников, а получает сказочников. недавно было два случая в копилку, что называется.
первый. наняли мегасупермилорда, который должен решать проблемы одним взглядом, но по факту абсолютно не командный игрок (субъективное мнение мое, разумеется) и вместо решения проблем пошло создание новых, оправдания почему нельзя пилить фичи и классическое предложение "все переписать с нуля". разошлись на испытательном сроке.
второй. наняли опытного разработчика, он сразу влился в процессы, подстроился под процессы и стиль разработки (опять же не могу судить без субъективизма хорошие у нас процессы или плохие, они такие как есть) стал пилить фичи с первой недели.
резюмируя. кто хороший и плохой, кто прав и виноват в этих двух случаях можно решать до бесконечности. основная мысль, что просто бывает по-разному при прочих равных.
история с наймом джунов сугубо индивидуальна - в одних командах есть и задачи, и менторы, на других - иначе. мерить единым мерилом за или против не стал бы. на моем опыте были и джуны-звезды, и сеньоры-лоботрясы. и задачи удавалось подбирать для постепенного погружения в проект, и не удавалось. очень все по-разному и субъективно.
Не могли бы вы поделиться соображениями по следующему вопросу? Я не специалист в нагрузочном тестирование, поэтому заранее прошу простить мне мой обывательский взгляд на проблематику. Работаю в компании, где разработчик и швец, и жнец, и на дуде игрец... Учусь, перенимаю опыт. Предположим у вас есть некое REST API, оно состоит из N методов. За вызовом каждого метода с вашей стороны стоит различное множество микросервисных взаимодействий (в т.ч. с источниками данных, интеграциями с внешними системами и т.п.) - соответственно средняя скорость и сложность выполнения у методов разная. Каким образом вы моделируете нагрузку, чтобы построить гипотезы на тему "какое количество пользователей выдержит текущая реализация вашего REST API"? Вижу такие варианты: 1. Использовать статистику частоты вызовов методов с production и скалировать пропорционально, сравнивать относительный прирост-падение производительности. 2. Принять частоту вызовов методов равномерной, далее по п.1 3. Выбрать самый медленный метод и принять его за бутылочное горлышко (не принимая в расчет частоту его вызовов), нагружать его и найти возможность улучшения до "средних по больнице" величин. 4. Сформировать пользовательские сценарии - очередность вызова методов. Как быть с многоообразием таковых сценариев? Или этот пункт по факту сводится к пункту 1?
Взаимодействие компания-сотрудник - это взаимодействие сотрудников, которым собственник компании доверил управлять персоналом, которому доверили управлять персоналом ниже по иерархии, которому доверили управлять персоналом ниже по иерархии... (повторить необходимое количество раз)... которому доверили управлять конкретным сотрудником. И в этой цепочке возможны значительные и неожиданные трансформации (с разным вектором) целей, методов и т.п.
в итоге все сводится к видимости борьбы с выгоранием или борьбой средней по больнице. приведу пример: меня в текущий момент не устраивает компетентность отдельных коллег, которые пожирают мое время на непрофильную деятельность. решать мою боль руководство не собирается - все хорошо, никто не жалуется, иди печеньки поешь на кухне. допускаю, что я не прав и все вокруг прекрасные специалисты и люди, но выгорание всегда субъективно. голосую ногами, но уверен, что в конце еще услышу - мы его на помойке нашли, отмыли, отчистили, а он нам фигвамы рисует.
5 пункт в перечне ключевых метрик немного спорный, т.к. некоторые (не все) 4xx коды могут быть следствием некорректного использования API. полагаю, что кусать локти обо всем отличном от 2хх не стоит.
а автору приходилось сталкиваться с микросервисной архитектурой, в которой микросервисы написаны на разных языках программирования? и работают подобные системы каким-то странным образом.
проблема расхождения у кандидатов двух умений: умения проходить собеседования и умения работать в том, что сообществом нанимающих вырабатывается некая средняя по больнице методика найма, которая в свою очередь не соответствует конкретной вакансии. эта средняя по больнице методика транслируется из каждого утюга ее адептами, привлекая все новых сторонников.
двум сторонам найма надо быть, а не казаться - тогда совпадения ожиданий и реальности более вероятны.
вот вам идея для следующей статьи начального уровня - какое будет поведения у HashSet'a объектов класса classA, если в классе classА:
1. Не переопределять ни equals(), ни hashCode(). 2. Переопределить только equals(). 3. Переопределить только hashCode(). 4. Переопределить и equals(), и hashCode().
Как раз сейчас несколько таких сервисов пытаюсь одомашнить. Работают через пень колоду, написаны на легаси стеке, фичи и баги по ним летят в таск-трекере со сроком "вчера". Авторы ушли на повышение и рассказывают сказки как они здорово все разработали. Думаю, нового я вам ничего не поведал. Так... Болью поделился.
Вангую, что если бы основной смысл статьи излагался в форме "Как я оставался в тренде ИТ и не сгорел", то, возможно, принятие было бы иным. А так... Все описанное вами в виде советов искушенная публика прочувствовала на своей шкуре. Неискушенной публике эти же советы рассказывало N-ое количество авторов до вас. Приношу извинения, если подобный комментарий бестактен.
согласен. хуже нет, когда в тягость тех.интервьюеру проводить собеседование. и проблема, как вы справедливо заметили, обоюдная: и менеджмент заставляет, и работник впрягается в чуждое дело.
в статистику "как оно бывает" по стимулированию. добавлю свой опыт. являюсь тех.интервьюером, дополнительных выплат не получаю, но время проведения собеседования и формирование обратной связи списывается наряду со временем по разработке, и берется в расчет при планировании спринта. т.е. интервьюирование такая же задача. и само собой на performance review учитывается эта активность. но, опять же, никто не заставляет: хочешь - проводи интервью, не хочешь - не проводи, но и не ной какая рутина на проекте или почему Васю повысили, а тебя нет. каждому - свое.
назвал бы вышеперечисленных вами моряками - выглядело бы с моей колокольни логично. опять же можно углубиться, что есть еще работники доков и портов.
также, как если бы вместо слова "программисты" Чернышенко использовал хотя бы слово "айтишники" или "работники IT-отрасли". по логике этого государственного мужа можно сказать, что в стране около миллиона чиновников "вице-премьеров". а какая разница?
именно программистов? а тестировщиков не считал? или системных аналитиков? администраторов различных специализаций?дизайнеров UI?... всех не смогу перечислить, прошу не обижаться, коллеги. или это все едино для вице-премьера курирующего (т.е. должен иметь хотя бы общее понимание) IT- отрасль? и на основании таким никаким образом собранных и преподносимых данных формируются управленческие решения на уровне страны? верной дорогой идём, товарищи! (про конец сарказма писать?)
если оба упёрлись, то никак. у нас, например, для этого есть разработчики (на разных уровнях иерархии) с ролью "техлид", за которыми крайнее для своего уровня решение.
да, именно так. одни понимают или пытаются понять, что под капотом (какая магия), а другим это не интересно. иногда просто не хватает кругозора в компьютерных науках и читать лекции - нет ресурса у ментора. поэтому всякому начинающему свое место. если не подошел одной компании, возможно есть другая где знаний и подхода к делу будет достаточно для трудовой деятельности.
со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из jira" или "у меня nda". в таких случаях уже переходим на разбор моих кейсов - это обычно ревью заготовленного кода или архитектуры - из текущего проекта с долей упрощения, разумеется. да, я готовлюсь к собеседованию, и кейсы мне дает реальная практика с проектов. надо просто оправданий лени не искать. и зачастую очень любопытные и непринуждённые беседы выходят.
благодарю!
руководство (как говорится в расхожей фразе) хочет волшебников, а получает сказочников. недавно было два случая в копилку, что называется.
первый. наняли мегасупермилорда, который должен решать проблемы одним взглядом, но по факту абсолютно не командный игрок (субъективное мнение мое, разумеется) и вместо решения проблем пошло создание новых, оправдания почему нельзя пилить фичи и классическое предложение "все переписать с нуля". разошлись на испытательном сроке.
второй. наняли опытного разработчика, он сразу влился в процессы, подстроился под процессы и стиль разработки (опять же не могу судить без субъективизма хорошие у нас процессы или плохие, они такие как есть) стал пилить фичи с первой недели.
резюмируя. кто хороший и плохой, кто прав и виноват в этих двух случаях можно решать до бесконечности. основная мысль, что просто бывает по-разному при прочих равных.
история с наймом джунов сугубо индивидуальна - в одних командах есть и задачи, и менторы, на других - иначе. мерить единым мерилом за или против не стал бы. на моем опыте были и джуны-звезды, и сеньоры-лоботрясы. и задачи удавалось подбирать для постепенного погружения в проект, и не удавалось. очень все по-разному и субъективно.
Не могли бы вы поделиться соображениями по следующему вопросу? Я не специалист в нагрузочном тестирование, поэтому заранее прошу простить мне мой обывательский взгляд на проблематику. Работаю в компании, где разработчик и швец, и жнец, и на дуде игрец... Учусь, перенимаю опыт.
Предположим у вас есть некое REST API, оно состоит из N методов. За вызовом каждого метода с вашей стороны стоит различное множество микросервисных взаимодействий (в т.ч. с источниками данных, интеграциями с внешними системами и т.п.) - соответственно средняя скорость и сложность выполнения у методов разная.
Каким образом вы моделируете нагрузку, чтобы построить гипотезы на тему "какое количество пользователей выдержит текущая реализация вашего REST API"?
Вижу такие варианты:
1. Использовать статистику частоты вызовов методов с production и скалировать пропорционально, сравнивать относительный прирост-падение производительности.
2. Принять частоту вызовов методов равномерной, далее по п.1
3. Выбрать самый медленный метод и принять его за бутылочное горлышко (не принимая в расчет частоту его вызовов), нагружать его и найти возможность улучшения до "средних по больнице" величин.
4. Сформировать пользовательские сценарии - очередность вызова методов. Как быть с многоообразием таковых сценариев? Или этот пункт по факту сводится к пункту 1?
Взаимодействие компания-сотрудник - это взаимодействие сотрудников, которым собственник компании доверил управлять персоналом, которому доверили управлять персоналом ниже по иерархии, которому доверили управлять персоналом ниже по иерархии... (повторить необходимое количество раз)... которому доверили управлять конкретным сотрудником. И в этой цепочке возможны значительные и неожиданные трансформации (с разным вектором) целей, методов и т.п.
в итоге все сводится к видимости борьбы с выгоранием или борьбой средней по больнице. приведу пример: меня в текущий момент не устраивает компетентность отдельных коллег, которые пожирают мое время на непрофильную деятельность. решать мою боль руководство не собирается - все хорошо, никто не жалуется, иди печеньки поешь на кухне. допускаю, что я не прав и все вокруг прекрасные специалисты и люди, но выгорание всегда субъективно. голосую ногами, но уверен, что в конце еще услышу - мы его на помойке нашли, отмыли, отчистили, а он нам фигвамы рисует.
5 пункт в перечне ключевых метрик немного спорный, т.к. некоторые (не все) 4xx коды могут быть следствием некорректного использования API. полагаю, что кусать локти обо всем отличном от 2хх не стоит.
а автору приходилось сталкиваться с микросервисной архитектурой, в которой микросервисы написаны на разных языках программирования? и работают подобные системы каким-то странным образом.
проблема расхождения у кандидатов двух умений: умения проходить собеседования и умения работать в том, что сообществом нанимающих вырабатывается некая средняя по больнице методика найма, которая в свою очередь не соответствует конкретной вакансии. эта средняя по больнице методика транслируется из каждого утюга ее адептами, привлекая все новых сторонников.
двум сторонам найма надо быть, а не казаться - тогда совпадения ожиданий и реальности более вероятны.
вот вам идея для следующей статьи начального уровня - какое будет поведения у HashSet'a объектов класса classA, если в классе classА:
1. Не переопределять ни equals(), ни hashCode().
2. Переопределить только equals().
3. Переопределить только hashCode().
4. Переопределить и equals(), и hashCode().
Как раз сейчас несколько таких сервисов пытаюсь одомашнить. Работают через пень колоду, написаны на легаси стеке, фичи и баги по ним летят в таск-трекере со сроком "вчера". Авторы ушли на повышение и рассказывают сказки как они здорово все разработали. Думаю, нового я вам ничего не поведал. Так... Болью поделился.
Вангую, что если бы основной смысл статьи излагался в форме "Как я оставался в тренде ИТ и не сгорел", то, возможно, принятие было бы иным. А так... Все описанное вами в виде советов искушенная публика прочувствовала на своей шкуре. Неискушенной публике эти же советы рассказывало N-ое количество авторов до вас. Приношу извинения, если подобный комментарий бестактен.
хороший интервьюер ищет почему надо сказать кандидату ДА, плохой - почему надо сказать кандидату НЕТ. (термины плохой-хороший - мой субъективизм)
согласен. хуже нет, когда в тягость тех.интервьюеру проводить собеседование. и проблема, как вы справедливо заметили, обоюдная: и менеджмент заставляет, и работник впрягается в чуждое дело.
в статистику "как оно бывает" по стимулированию. добавлю свой опыт. являюсь тех.интервьюером, дополнительных выплат не получаю, но время проведения собеседования и формирование обратной связи списывается наряду со временем по разработке, и берется в расчет при планировании спринта. т.е. интервьюирование такая же задача. и само собой на performance review учитывается эта активность. но, опять же, никто не заставляет: хочешь - проводи интервью, не хочешь - не проводи, но и не ной какая рутина на проекте или почему Васю повысили, а тебя нет. каждому - свое.
на моей практике в случаях, когда перестаёт работать, то у людей, описанных вами начинаются аппеляции "там какая-то магия" и "нужен бубен".
назвал бы вышеперечисленных вами моряками - выглядело бы с моей колокольни логично. опять же можно углубиться, что есть еще работники доков и портов.
также, как если бы вместо слова "программисты" Чернышенко использовал хотя бы слово "айтишники" или "работники IT-отрасли". по логике этого государственного мужа можно сказать, что в стране около миллиона
чиновников"вице-премьеров". а какая разница?именно программистов? а тестировщиков не считал? или системных аналитиков? администраторов различных специализаций?дизайнеров UI?... всех не смогу перечислить, прошу не обижаться, коллеги. или это все едино для вице-премьера курирующего (т.е. должен иметь хотя бы общее понимание) IT- отрасль? и на основании таким
никакимобразом собранных и преподносимых данных формируются управленческие решения на уровне страны? верной дорогой идём, товарищи! (про конец сарказма писать?)если оба упёрлись, то никак. у нас, например, для этого есть разработчики (на разных уровнях иерархии) с ролью "техлид", за которыми крайнее для своего уровня решение.
да, именно так. одни понимают или пытаются понять, что под капотом (какая магия), а другим это не интересно. иногда просто не хватает кругозора в компьютерных науках и читать лекции - нет ресурса у ментора. поэтому всякому начинающему свое место. если не подошел одной компании, возможно есть другая где знаний и подхода к делу будет достаточно для трудовой деятельности.