расскажу мой случай... причина проста - в опенспейсе рядом сидят люди с различными теплоощущениями. вариант решения, лежащего на поверхности - рассадить мерзлячих и горячих по разные стороны не нашел поддержку у руководства т.к. "мы тут по отделам сидим". в итоге горячие парни ноют "как душно" и открывают окна, мерзлячие ноют "как холодно" и закрывают. так весь день и проходит в открытии и закрытии. вариант решения "давайте настроим температурный режим системы кондиционирования" сводится к первому, только вместо открытия окон - тыкание в пульт кондиционера.
все, кроме 9 и 11 пункта можно смело отзеркалить на "лучших" представителей нанимающей стороны - достаточно почитать вакансии и сообщениях от них. человеческая природа - допускать ошибки, указывать другим и не видеть у аналогичные у себя. будучи в роли кандидата, практически не встречал что-либо сопоставимое с моим субъективным видением "вакансия мечты", обычно boilerplate из лжи и штампов. так может хватит уже скакать на ветрянные мельницы под названием "бревно в чужом глазу"? лукавят все, а те, кто утверждает обратное, возможно лукавят сильнее. нет объективного хорошо и объективного плохо, объективного правильно и объективного неправильно. есть допущения и компромиссы, на которые идут стороны при оформлении трудовых отношений. в каждом случае свои, в каждом случае субъективнее некуда.
все эти рекомендации по решению конфликтов великолепны ровно до тех пор, пока не встретятся две стороны, каждая из которых не собирается уступать. хрестоматийный случай в каждом openspace - "мне дует" и "мне жарко". коучи по конфликтологии начинают сразу генерировать великое множество идей (ребята, ну как вы не догадались - вот же как надо!), но беда в том, что в ситуации "уперлись два барана с милыми улыбками на мордах и подчеркнуто-вежливым поведением с полным зеркалированием друг друга" все идеи не работают. а ненависть в душе множится.
со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из 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-ое количество авторов до вас. Приношу извинения, если подобный комментарий бестактен.
расскажу мой случай... причина проста - в опенспейсе рядом сидят люди с различными теплоощущениями. вариант решения, лежащего на поверхности - рассадить мерзлячих и горячих по разные стороны не нашел поддержку у руководства т.к. "мы тут по отделам сидим". в итоге горячие парни ноют "как душно" и открывают окна, мерзлячие ноют "как холодно" и закрывают. так весь день и проходит в открытии и закрытии. вариант решения "давайте настроим температурный режим системы кондиционирования" сводится к первому, только вместо открытия окон - тыкание в пульт кондиционера.
база для командной работы (и не только в IT) - это умение формулировать "мои мысли - мои скакуны" в устную и письменную речь.
мой любимый паттерн компаний - мы не будем дискриминировать по фото, но будем дискриминировать по факту наличия или отсутствия фото (#этодругое)
все, кроме 9 и 11 пункта можно смело отзеркалить на "лучших" представителей нанимающей стороны - достаточно почитать вакансии и сообщениях от них. человеческая природа - допускать ошибки, указывать другим и не видеть у аналогичные у себя. будучи в роли кандидата, практически не встречал что-либо сопоставимое с моим субъективным видением "вакансия мечты", обычно boilerplate из лжи и штампов. так может хватит уже скакать на ветрянные мельницы под названием "бревно в чужом глазу"? лукавят все, а те, кто утверждает обратное, возможно лукавят сильнее. нет объективного хорошо и объективного плохо, объективного правильно и объективного неправильно. есть допущения и компромиссы, на которые идут стороны при оформлении трудовых отношений. в каждом случае свои, в каждом случае субъективнее некуда.
все эти рекомендации по решению конфликтов великолепны ровно до тех пор, пока не встретятся две стороны, каждая из которых не собирается уступать. хрестоматийный случай в каждом openspace - "мне дует" и "мне жарко". коучи по конфликтологии начинают сразу генерировать великое множество идей (ребята, ну как вы не догадались - вот же как надо!), но беда в том, что в ситуации "уперлись два барана с милыми улыбками на мордах и подчеркнуто-вежливым поведением с полным зеркалированием друг друга" все идеи не работают. а ненависть в душе множится.
хорошие вопросы, я как тех.интервьюер отвечаю на подобные вопросы и встречный интерес проявляю - как работал кандидат.
со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из 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-ое количество авторов до вас. Приношу извинения, если подобный комментарий бестактен.
хороший интервьюер ищет почему надо сказать кандидату ДА, плохой - почему надо сказать кандидату НЕТ. (термины плохой-хороший - мой субъективизм)