Смешная история про общение с рекрутером
Мне написала рекрутер и предложила пройти собеседование в одну компанию. Главным преимуществом вакансии была 4-дневная рабочая неделя. То есть у всех выходные с пятницы по воскресенье.
Я долго думал, в чем же может быть подвох? 4-дневная рабочая неделя не частная практика. В итоге, скинул CV и мне обещали ответить до конца недели.
В ПЯТНИЦУ мне рекрутер пишет примерно следующее сообщение:
Как думаете, это совпадение, что именно сейчас им пришлось в пятницу поработать? Или у них на регулярной основе переработки в 4-х дневную рабочую неделю? 🙂
Мне написала рекрутер и предложила пройти собеседование в одну компанию. Главным преимуществом вакансии была 4-дневная рабочая неделя. То есть у всех выходные с пятницы по воскресенье.
Я долго думал, в чем же может быть подвох? 4-дневная рабочая неделя не частная практика. В итоге, скинул CV и мне обещали ответить до конца недели.
В ПЯТНИЦУ мне рекрутер пишет примерно следующее сообщение:
Максим, добрый день!
Пишу вам, чтобы извиниться и взять паузу до понедельника. У лида на этой неделе крайне высокая занятость. Он надеялся, что найдет время сегодня (тот редкий случай, когда пришлось поработать в пятницу), но я вижу, что вряд ли он ответит уже.
Я надеюсь на понимание 🙏 И также надеюсь, что в пн уже смогу точно вернуться с ответом.
Как думаете, это совпадение, что именно сейчас им пришлось в пятницу поработать? Или у них на регулярной основе переработки в 4-х дневную рабочую неделю? 🙂
😁29🤣5👍1
Какие алгоритмические задачи с собеседований я применял на коммерческих проектах?
Вас тоже бесит, когда на собеседованиях дают live-coding задачи, которые не используются в коммерческой разработке?
Я помню, как интервьюер дал мне задачу написать кастомный Stack с нуля, уверяя, что у них такая реализация используется в production коде. Когда я принял оффер, устроился в компанию и получил доступ к коду, то увидел... Что никакой кастомной реализации стека там нет.
Но на самом деле, многие задачи на алгоритмы применяются в коммерческой разработке. Расскажу вам про кейсы с моих мест работы.
1️⃣ mergeIntervals
Разбор решения задачи есть на моем YouTube.
Практический кейс был такой. Необходимо нарисовать график на основе данных с бэка. Бэк присылает массив объектов с параметрами dateStart, dateEnd и др. По оси Y идет цена в RUB, по оси X - интервалы дат.
Дело в том, что некоторые интервалы с датами пересекались. Не было смысла отображать отдельный столбец в графике, когда можно было схлопнуть несколько интервалов в один.
2️⃣ findClosestNumber (поиск ближайшего числа в массиве)
Разбор решения задачи есть в моем приватном ТГ канале.
Проект связан с оформлением кредитов онлайн. В интерфейсе приложения есть слайдер с инпутом для ввода суммы кредита. Кредит можно взять на конкретные суммы (например, 10_000, 30_000, 50_000, 100_000, 200_000 и тд). То есть если пользователь вводит в инпут число 47500, то его нужно заменить на ближайшее значение (в данном примере 50_000).
3️⃣ Observer / EventEmitter
Разбор реализации EventEmitter есть в моем приватном ТГ канале.
Проект все тот же, оформление кредитов онлайн. На клиенте есть форма из 20+ полей, где пользователю нужно заполнить персональные данные для регистрации кредита. У некоторых полей есть рядом блок с процентами (например, 5%, 8%, 20%). И вверху страницы расположена шкала от 0 до 100%. Если правильно заполняешь конкретное поле, то прибавляется процент к общей шкале.
Такой UI/UX мотивирует пользователя заполнять форму из большого количества полей.
Первое решение, которое приходит в голову, использовать useContext из React. Но его главный недостаток - лишние ререндеры. Зачем нам ререндерить всю форму при обновлении процентов шкалы, если можно воспользоваться паттернами EventEmitter или Observer?
В данном примере я применил Observer. Я повесил слушатель observer.subscribe в компоненте со шкалой процентов. А в каждом инпуте при валидном вводе значения делал observer.emit. Таким образом, ререндерилась только компонента со шкалой процентов.
----------
Конечно, примеров использования алгоритмических задач в моей практике было намного больше. Накидайте реакций, если вам понравился пост, сделаю еще одну часть.
А вы какие алгоритмические задачи с собеседований используете в коммерческой разработке? 🤔
Вас тоже бесит, когда на собеседованиях дают live-coding задачи, которые не используются в коммерческой разработке?
Я помню, как интервьюер дал мне задачу написать кастомный Stack с нуля, уверяя, что у них такая реализация используется в production коде. Когда я принял оффер, устроился в компанию и получил доступ к коду, то увидел... Что никакой кастомной реализации стека там нет.
Но на самом деле, многие задачи на алгоритмы применяются в коммерческой разработке. Расскажу вам про кейсы с моих мест работы.
1️⃣ mergeIntervals
Разбор решения задачи есть на моем YouTube.
Практический кейс был такой. Необходимо нарисовать график на основе данных с бэка. Бэк присылает массив объектов с параметрами dateStart, dateEnd и др. По оси Y идет цена в RUB, по оси X - интервалы дат.
Дело в том, что некоторые интервалы с датами пересекались. Не было смысла отображать отдельный столбец в графике, когда можно было схлопнуть несколько интервалов в один.
2️⃣ findClosestNumber (поиск ближайшего числа в массиве)
Разбор решения задачи есть в моем приватном ТГ канале.
Проект связан с оформлением кредитов онлайн. В интерфейсе приложения есть слайдер с инпутом для ввода суммы кредита. Кредит можно взять на конкретные суммы (например, 10_000, 30_000, 50_000, 100_000, 200_000 и тд). То есть если пользователь вводит в инпут число 47500, то его нужно заменить на ближайшее значение (в данном примере 50_000).
3️⃣ Observer / EventEmitter
Разбор реализации EventEmitter есть в моем приватном ТГ канале.
Проект все тот же, оформление кредитов онлайн. На клиенте есть форма из 20+ полей, где пользователю нужно заполнить персональные данные для регистрации кредита. У некоторых полей есть рядом блок с процентами (например, 5%, 8%, 20%). И вверху страницы расположена шкала от 0 до 100%. Если правильно заполняешь конкретное поле, то прибавляется процент к общей шкале.
Такой UI/UX мотивирует пользователя заполнять форму из большого количества полей.
Первое решение, которое приходит в голову, использовать useContext из React. Но его главный недостаток - лишние ререндеры. Зачем нам ререндерить всю форму при обновлении процентов шкалы, если можно воспользоваться паттернами EventEmitter или Observer?
В данном примере я применил Observer. Я повесил слушатель observer.subscribe в компоненте со шкалой процентов. А в каждом инпуте при валидном вводе значения делал observer.emit. Таким образом, ререндерилась только компонента со шкалой процентов.
----------
Конечно, примеров использования алгоритмических задач в моей практике было намного больше. Накидайте реакций, если вам понравился пост, сделаю еще одну часть.
А вы какие алгоритмические задачи с собеседований используете в коммерческой разработке? 🤔
🔥14❤5
Как найти все ред-флаги компании в процессе собеседования? 🚩🚩🚩
Многие разработчики в конце собеседования задают единственный вопрос вроде "ну даже не знаю, что спросить, про процессы в команде расскажи?". И после этого следует "да в принципе все понятно, вопросов больше нет".
Меня всегда удивляет, насколько разработчики инфантильно подходят к вопросам про компанию. Ведь тебе в этой компании работать! А вдруг что-то не понравится после трудоустройства? Лучше выявить все ред-флаги заранее.
В этом посте мы разберем топ вопросов, которые стоит задать интервьюеру в конце собеседования.
1️⃣ Какие сроки фидбека?
Интервьюер чаще всего сам принимает финальное решение и знает, сколько времени ему нужно на оценку. Многие этим вопросом пренебрегают, а потом жалуются "почему мне так долго не отвечают?".
2️⃣ Какого размера команда и кто в нее входит? (front-end, back-end, QA, дизайнеры и т.д.)
Чем больше юнитов, тем лучше в команде распределены роли. Допустим, нет тестировщика — будут баги на проде. Или нет дизайнера — будет много задач без макетов и куча правок от PM-а.
3️⃣ Какие процессы в команде? Расскажи, как задача проходит путь от тикета до прода.
Данный вопрос позволит понять, как будет проходить типичный спринт. Как по мне, идеальный процесс примерно такой.
На момент постановки задачи уже есть макеты и четкое описание бизнес-логики. После выполнения, задача проходит обязательный код-ревью. Далее тестировщики проверяют задачу как вручную, так и при помощи автотестов. В финальной стадии ответственный за релиз коллега подготавливает задачу к выкатке на прод.
4️⃣ Какие есть созвоны в течение спринта? В какое время проходят эти созвоны?
Большинство почему-то боятся задавать этот вопрос. Хотя он чрезвычайно важный. Представьте, что у команды дейлики начинаются в 8 утра, а вы привыкли вставать в 9-10. Будет уже поздно узнать это в процессе онбординга.
Важно, чтобы не было бесполезных звонков. Большинство вопросов по задачам решаются максимум за 1 час созвонов в день.
5️⃣ Как часто происходят релизы и кто за них отвечает? Есть ли дежурства?
Лично мне нравится, когда я как front-end разработчик не участвую в процессе релиза. То есть мне не нужно самому лезть в Jenkins, подготавливать релизную ветку, фиксать конфликты, раскатывать на прод несколько окружений. Круто, когда этим занимается отдельный человек или юнит. Например, процессом релиза могут заниматься QA.
6️⃣ Пишут ли front-end разработчики тесты?
Часто замечаю, как в командах пишут тесты ради тестов. И выхлоп от этого минимальный. Всегда круто, когда под автоматическое тестирование выделены специальные люди (QA, например).
7️⃣ Как у вас с переработками? Случается ли, что после 18:00 в будний день или в выходной приходит коллега и пишет "у нас пожар, срочно подключайся, нужно фиксать багу"?
Думаю, комментарии здесь излишни. Переработки — это ненормально. Работа вне графика по требованию PM-а или тимлида — тревожный знак.
---------
А какие вопросы вы задаёте на собеседованиях? Делитесь в комментариях 👇
Многие разработчики в конце собеседования задают единственный вопрос вроде "ну даже не знаю, что спросить, про процессы в команде расскажи?". И после этого следует "да в принципе все понятно, вопросов больше нет".
Меня всегда удивляет, насколько разработчики инфантильно подходят к вопросам про компанию. Ведь тебе в этой компании работать! А вдруг что-то не понравится после трудоустройства? Лучше выявить все ред-флаги заранее.
В этом посте мы разберем топ вопросов, которые стоит задать интервьюеру в конце собеседования.
1️⃣ Какие сроки фидбека?
Интервьюер чаще всего сам принимает финальное решение и знает, сколько времени ему нужно на оценку. Многие этим вопросом пренебрегают, а потом жалуются "почему мне так долго не отвечают?".
2️⃣ Какого размера команда и кто в нее входит? (front-end, back-end, QA, дизайнеры и т.д.)
Чем больше юнитов, тем лучше в команде распределены роли. Допустим, нет тестировщика — будут баги на проде. Или нет дизайнера — будет много задач без макетов и куча правок от PM-а.
3️⃣ Какие процессы в команде? Расскажи, как задача проходит путь от тикета до прода.
Данный вопрос позволит понять, как будет проходить типичный спринт. Как по мне, идеальный процесс примерно такой.
На момент постановки задачи уже есть макеты и четкое описание бизнес-логики. После выполнения, задача проходит обязательный код-ревью. Далее тестировщики проверяют задачу как вручную, так и при помощи автотестов. В финальной стадии ответственный за релиз коллега подготавливает задачу к выкатке на прод.
4️⃣ Какие есть созвоны в течение спринта? В какое время проходят эти созвоны?
Большинство почему-то боятся задавать этот вопрос. Хотя он чрезвычайно важный. Представьте, что у команды дейлики начинаются в 8 утра, а вы привыкли вставать в 9-10. Будет уже поздно узнать это в процессе онбординга.
Важно, чтобы не было бесполезных звонков. Большинство вопросов по задачам решаются максимум за 1 час созвонов в день.
5️⃣ Как часто происходят релизы и кто за них отвечает? Есть ли дежурства?
Лично мне нравится, когда я как front-end разработчик не участвую в процессе релиза. То есть мне не нужно самому лезть в Jenkins, подготавливать релизную ветку, фиксать конфликты, раскатывать на прод несколько окружений. Круто, когда этим занимается отдельный человек или юнит. Например, процессом релиза могут заниматься QA.
6️⃣ Пишут ли front-end разработчики тесты?
Часто замечаю, как в командах пишут тесты ради тестов. И выхлоп от этого минимальный. Всегда круто, когда под автоматическое тестирование выделены специальные люди (QA, например).
7️⃣ Как у вас с переработками? Случается ли, что после 18:00 в будний день или в выходной приходит коллега и пишет "у нас пожар, срочно подключайся, нужно фиксать багу"?
Думаю, комментарии здесь излишни. Переработки — это ненормально. Работа вне графика по требованию PM-а или тимлида — тревожный знак.
---------
А какие вопросы вы задаёте на собеседованиях? Делитесь в комментариях 👇
👍7❤5💯3⚡1