Да, причем то, что мощно "бомбит" у людей с обеих сторон, как работников, так и работодатей, для меня служит ярким показателем того, что в индустрии найма что-то не так (он же HR-tech). И это свойственно не только России. Вот мемчик с международного поля по теме исчезновения рекрутеров.
У меня как раз в понедельник вышло интервью с рекрутером, где он честно по полочкам рассказывает, почему могут не давать обратную связь и как это влияет на hr-бренд, спойлер (никак*) (*по мнению моего собеседника; мнение гостя может не совпадать с мнением редакции?)
Тогда хочется спросить дальше: почему выбрали такой подход? В чем была основная идея? Что смешение должно было дать?
Как мне представляется, ожидания и предложения - это разные сущности. Хотя и то, и другое измеряется в деньгах, усреднять их между собой не совсем корректно методологически. Их скорее можно сопоставлять. И в сравнении можно сделать какие-то выводы. Например, что средние ожидания превосходят средние предложения на сколько-то. И дальше искать причину расхождения. А то очень похоже на среднюю температуру по госпиталю) Или я не увидел каких-то очевидных преимуществ подхода усреднения? Поделитесь?
Да, мне кажется, проблема в том, что мы на данный момент не обладаем каким-то объемом данных, чтобы перейти от личного опыта к каким-то статистически значимым обобщениям. Собственно, эта статья - попытка для начала посмотреть на найм "с той стороны". И собрать больше точек зрения, чтобы сделать картину более объемной. А Вы разрабов нанимаете?
Спасибо за развернутый ответ. Я сейчас не как автор статьи или с позиции гостя, просто как рядовой читатель хочу уточнить пару вещей.
Просто откидывать задачи с низким приоритетом - ну прямо такое.
Если представить ситуацию, где я просто "забиваю" на задачу с низким приоритетом, потому что у неё приоритет низкий без объективных причин - я бы сам себя за такое по голове не погладил
Выставленный приоритет разве не является главной объективной причиной того, в какой последовательности мы делаем те или иные задачи? Основания выставления приоритетов сейчас не берем в расчет.
Сейчас любой инфоповод меняет отношение к компании-нанимателю
У Вас есть примеры того, как отзыв одного человека, не прошедшего отбор, уничтожил имидж компании и привел к ее закрытию? Если вспомнить даже открытые и известные скандалы действующих сотрудников компаний последнего времени, то кажется что после волны негатива, компании так и работают как раньше (Amazon, XSolla). А мы говорим о гораздо более безобидной вещи.
Да, в целом похоже на некий сформировавшийся баланс: нет ответа, идем дальше. Понятно, что отсутствие ответа может и задевать, если ты уже придумал как получил классный оффер и уже на этой должности работаешь. Но если чисто рационально подходить, то и кандидат, и рекрутер при найме работают на конвейере. Только у рекрутера он бежит гораздо более интенсивно. Тут просто важно понимать, как у кого конвейер устроен.
По своему опыту работы разрабом и менеджером я бы не сказал, что это всегда куча рутины. Наверное, зависит от задач бизнеса и стадии развития проекта/продукта. Если делать что-то с нуля, то на начальных этапах задачи больше разноплановые. Это потом чем больше сделано, тем больше можно переиспользовать. И все равно, даже в задаче, где что-то переиспользуется, есть часть новизны. Это касается как разработки, так и менеджмента. Конечно, инструменты оттачиваются и подбираются со временем. Я могу представить монотонной работу разработчика только если в проекте не происходит ничего принципиально нового.
Онбординг, по моему опыту, вообще больная тема в индустрии. В крупных компаниях могут упарываться по онбордингу клиентов, но при этом в той же команде, которая онбордит клиентов, не онбордить своих сотрудников. Совсем плохо, когда сразу бросают в бой. Лучше, если дают внутренние курсы и потом в бой. Но все равно остается какой-то разрыв между курсом "вообще для всех специалистов профиля ИКС" и тем, что нужно реально делать в конкретной команде. Тут должен помогать наставник. Но тема с наставником работает, если наставник уделяет обучению времени сколько нужно, а не по остаточному принципу. Причем онбордить надо не только джунов. Сталкивался с ситуациями в стиле "ты сеньор, сам разберешься". Тут даже не только человеческое измерение, но и бизнесовое. Кажется, логично: чем лучше поможешь новичку стартануть, тем больше выхлоп получишь. Но чаще работает логика в стиле "Сова эффективный менеджер")
ПС: респект за такой подход. корп среда должна быть человечней
Кстати, сегодня подключил Юмани и при попытке потестить донат и закинуть себе денях меня просто перебрасывает на стартовую страницу yoomoney. Гайз, у вас донат сейчас работает?
Здесь нужно уточнить. Контейнер отличается от фабрики прежде всего, тем, что сохраняет ссылки на создаваемые им объекты и управляет их жизненным циклом. Фабрика же занимается только созданием объектов. пруф1, пруф2
В spring IoC контейнер создается как объект ApplicationContext.
The interface org.springframework.context.ApplicationContext represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the aforementioned beans.
При этом ApplicationContext наследует также от BeanFactory
public interface BeanFactory
The root interface for accessing a Spring bean container. This is the basic client view of a bean container; further interfaces such as ListableBeanFactory and ConfigurableBeanFactory are available for specific purposes.
Т.е. IoC контейнер в Spring является также и фабрикой, но имеет более широкий функционал, чем создание объектов. В официальной документации для создания контейнера рекомендуется использовать ApplicationContext. пруф3
Ок, это Ваша интерпретация указанных авторов. Возможно, кто-то считает, что нет четких границ, но такие взгляды сами по себе довольно размыты и непрактичны. И такой подход может говорить о том, что на самом деле нет понимания сути вопроса. Я это пишу не для холивара, а скорее в образовательных целях с мыслями о тех, кто будет Ваш пост читать.
Я исхожу из убеждения, что понятные вещи можно объяснить просто. Если сразу не удается найти убедительные объяснения, нужно искать еще. А списывать размытое понимание на авторитеты и транслировать такой подход я считаю вредным для сообщества.
Не обязательно повторять за кем-то из авторитетов, все могут ошибаться. Практичнее соотносить высказываемые взгляды и вырабатывать собственное видение. И как раз предложение целостного видения в области с противоречивыми и нечеткими терминами уже обладает ценностью. Сергей именно это и сделал.
Я не утверждаю, что он изрек истину в последней инстанции. Возможно, у Вас за время, прошедшее с написания поста, целостное понимание сложилось? Поделитесь?
Между тем, границы принципов внедрения зависимости достаточно размыты. Невозможно провести действительно четкую границу между этим и другими принципами написания качественного объектно-ориентированного кода. Например, принцип Dependency Inversion из SOLID, который часто путают с Dependency Injection, как бы подразумевает внедрение зависимостей, но им не ограничивается.
Различия DI vs. DIP vs. IoC можно четко провести. Например, их разъясняет Сергей Тепляков в своем посте DI vs. DIP vs. IoC.
Да, причем то, что мощно "бомбит" у людей с обеих сторон, как работников, так и работодатей, для меня служит ярким показателем того, что в индустрии найма что-то не так (он же HR-tech). И это свойственно не только России. Вот мемчик с международного поля по теме исчезновения рекрутеров.
звучит как будто российских. Особенно под заголовком со словом "импортозамещение"
У меня как раз в понедельник вышло интервью с рекрутером, где он честно по полочкам рассказывает, почему могут не давать обратную связь и как это влияет на hr-бренд, спойлер (никак*) (*по мнению моего собеседника; мнение гостя может не совпадать с мнением редакции?)
Виктория, спасибо, что подсветили)
Тогда хочется спросить дальше: почему выбрали такой подход? В чем была основная идея? Что смешение должно было дать?
Как мне представляется, ожидания и предложения - это разные сущности. Хотя и то, и другое измеряется в деньгах, усреднять их между собой не совсем корректно методологически. Их скорее можно сопоставлять. И в сравнении можно сделать какие-то выводы. Например, что средние ожидания превосходят средние предложения на сколько-то. И дальше искать причину расхождения. А то очень похоже на среднюю температуру по госпиталю) Или я не увидел каких-то очевидных преимуществ подхода усреднения? Поделитесь?
а в чем потеря? письмо - коммуникация асинхронная. пока рекрутер отвечает, кандидат уже работает по другим позициям)
Спасибо) Действительно, первая часть универсальная , а уже во второй и третьей начнется продуктовая специфика.
Да, мне кажется, проблема в том, что мы на данный момент не обладаем каким-то объемом данных, чтобы перейти от личного опыта к каким-то статистически значимым обобщениям. Собственно, эта статья - попытка для начала посмотреть на найм "с той стороны". И собрать больше точек зрения, чтобы сделать картину более объемной. А Вы разрабов нанимаете?
Спасибо за развернутый ответ. Я сейчас не как автор статьи или с позиции гостя, просто как рядовой читатель хочу уточнить пару вещей.
Выставленный приоритет разве не является главной объективной причиной того, в какой последовательности мы делаем те или иные задачи? Основания выставления приоритетов сейчас не берем в расчет.
У Вас есть примеры того, как отзыв одного человека, не прошедшего отбор, уничтожил имидж компании и привел к ее закрытию? Если вспомнить даже открытые и известные скандалы действующих сотрудников компаний последнего времени, то кажется что после волны негатива, компании так и работают как раньше (Amazon, XSolla). А мы говорим о гораздо более безобидной вещи.
Да, в целом похоже на некий сформировавшийся баланс: нет ответа, идем дальше. Понятно, что отсутствие ответа может и задевать, если ты уже придумал как получил классный оффер и уже на этой должности работаешь. Но если чисто рационально подходить, то и кандидат, и рекрутер при найме работают на конвейере. Только у рекрутера он бежит гораздо более интенсивно. Тут просто важно понимать, как у кого конвейер устроен.
Вот кстати как отнесетесь, если получите автоматически сформированную отбивку? То есть рекрутер дал ответ, но шаблоном с Вашим именем.
По своему опыту работы разрабом и менеджером я бы не сказал, что это всегда куча рутины. Наверное, зависит от задач бизнеса и стадии развития проекта/продукта. Если делать что-то с нуля, то на начальных этапах задачи больше разноплановые. Это потом чем больше сделано, тем больше можно переиспользовать. И все равно, даже в задаче, где что-то переиспользуется, есть часть новизны. Это касается как разработки, так и менеджмента. Конечно, инструменты оттачиваются и подбираются со временем. Я могу представить монотонной работу разработчика только если в проекте не происходит ничего принципиально нового.
Виктория, все же в таблице приведены реально предлагаемые зарплаты или ожидания специалистов? Если замешали и первое, и второе, то в какой пропорции?)
Онбординг, по моему опыту, вообще больная тема в индустрии. В крупных компаниях могут упарываться по онбордингу клиентов, но при этом в той же команде, которая онбордит клиентов, не онбордить своих сотрудников. Совсем плохо, когда сразу бросают в бой. Лучше, если дают внутренние курсы и потом в бой. Но все равно остается какой-то разрыв между курсом "вообще для всех специалистов профиля ИКС" и тем, что нужно реально делать в конкретной команде. Тут должен помогать наставник. Но тема с наставником работает, если наставник уделяет обучению времени сколько нужно, а не по остаточному принципу. Причем онбордить надо не только джунов. Сталкивался с ситуациями в стиле "ты сеньор, сам разберешься". Тут даже не только человеческое измерение, но и бизнесовое. Кажется, логично: чем лучше поможешь новичку стартануть, тем больше выхлоп получишь. Но чаще работает логика в стиле "Сова эффективный менеджер")
ПС: респект за такой подход. корп среда должна быть человечней
Кстати, сегодня подключил Юмани и при попытке потестить донат и закинуть себе денях меня просто перебрасывает на стартовую страницу yoomoney. Гайз, у вас донат сейчас работает?
В spring IoC контейнер создается как объект ApplicationContext. При этом ApplicationContext наследует также от BeanFactory Т.е. IoC контейнер в Spring является также и фабрикой, но имеет более широкий функционал, чем создание объектов. В официальной документации для создания контейнера рекомендуется использовать ApplicationContext. пруф3
Я исхожу из убеждения, что понятные вещи можно объяснить просто. Если сразу не удается найти убедительные объяснения, нужно искать еще. А списывать размытое понимание на авторитеты и транслировать такой подход я считаю вредным для сообщества.
Не обязательно повторять за кем-то из авторитетов, все могут ошибаться. Практичнее соотносить высказываемые взгляды и вырабатывать собственное видение. И как раз предложение целостного видения в области с противоречивыми и нечеткими терминами уже обладает ценностью. Сергей именно это и сделал.
Я не утверждаю, что он изрек истину в последней инстанции. Возможно, у Вас за время, прошедшее с написания поста, целостное понимание сложилось? Поделитесь?
Различия DI vs. DIP vs. IoC можно четко провести. Например, их разъясняет Сергей Тепляков в своем посте DI vs. DIP vs. IoC.