В профиле у меня этой информации нет. Значит надо гуглить ФИО, либо никнейм. У меня такого желания никогда при прочтении статей не возникало, а Вы вон даже до ВК успели дойти
Вторичный скрининг резюме я проводил самостоятельно. Грубо говоря, давал первичные инструкции HR по требуемым навыкам. Если отклик удовлетворял, резюме направлялось мне. Много отсеивал из-за отсутствия инфы в «обо мне», и подробного описания выполняемых задач на предыдущих проектах. На собеседования приглашали только с моего одобрения. Вероятно оттуда и эффективность, так как я уже на этапе чтения резюме мог сказать, кто мне как коллега однозначно не подойдет
Как интересно у Вас выходит. Всё мимо. Видимо по Вашему мнению middle php разработчик должен целыми днями велосипеды самописные для бинарного поиска строить и сложность алгоритмов высчитывать. Зато руками и в пределах своей зоны ответственности!
Возможно у нас разные понятия о грейдах, но по моему мнению, middle - это не просто боевая единица, а сотрудник, способный и менторством заниматься, и оптимизацией и проектированием архитектуры, и другим спектром более сложных задач. Ему в конце концов как-то надо же сеньором становиться.
Исходя из Вашего описания уже сейчас всех мидлов можно выбросить и передать все задачи копилоту. (Про джунов я вообще молчу)
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
Таких претензий никогда не понимал. Я получил какой-то опыт, поделился им и своим видением ситуации, предложил альтернативный сценарий проведения собеседования. Разве не для этого "мы тут все и собрались"? Так что без обид не выйдет.
В реальной жизни так не бывает, чтобы из таск трекера сразу готовая фича. Продуктовая команда приносит часто весьма сырое описание задачи. Моё предназначение, как разработчика - оценить задачу, её влияние на продукт в целом, предложить лучшее решение, иногда оно может не совпадать с видением продактов. После дискуссии начать цикл разработки, сначала проектирование, затем разработка, тестирование (юнит, интеграционное, нагрузочное), затем ввод в эксплуатацию. Потом наблюдение, оптимизация при необходимости.
А есть ещё баги и инциденты, которые ещё отловить надо. Есть ревью кода и менторство над младшими разработчиками.
Бывают ещё сложные архитектурные задачи. Как пример: мигрировать все сервисы с elasticsearch v6 на elastcisearch v8. Приходится переопределять архитектурные подходы, реализовывать паттерн стратегии, писать скрипты для безболезненной миграции данных, править спеки сервисов для деплоя.
То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
Это практика "собеседование как культ", когда оно перестаёт иметь хоть что либо общее с реальными решаемыми задачами.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
На джуна? Возможно. Было время, когда на вопросы по структурам и алгоритмам данных я отвечал. На мидла таких вопросов быть не должно.
Я, возможно, чего-то не понимаю, но даже я, ни разу не разработчик, знаю, что такое указатели и О-нотация, хотя для меня эти знания были актуальны ...дцать лет назад в студенческой практике и в качестве хобби, причем программирование у меня было отнюдь не основным интересом. Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Я уверен, мои бывшие одногруппники также назовут ответ на эти вопросы. Потому что теорию зубрили. Я теорию не зубрил, а проекты сложные делал и автоматы получал за них.
Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Ну не знал я значения термина ДНС до собеседования. Ну узнал я его значение сейчас, что изменилось?
Незнание не мешало мне в своё время basic auth делать на апаче, рейт-лимиты с редиректами на порты в nginx прописывать, или certbot-ом SSL подписывать. Точно так же, как и знания этого термина абсолютно ничего не дают на практике.
Я не знаю PHP, возможно, для бэкэнда все эти знания и не нужны, лепите сайтики по готовым фреймворкам и в ус не дуете :)
Нет. Мы не "сайтики лепим", а высоконагруженные микросервисы готовим, с сотнями тысяч RPM и сотнями терабайт данных. И нет, знания линейного и бинарного поиска здесь не нужны.
Очень удивило незнание термина "О-нотация". Это не "вариант терминологии", это общепринятая терминология.
Общепринятая терминология - это "сложность алгоритмов". Термин "О-нотация" я слышал впервые.
А чего про нее спрашивать, если даже низкоуровневые оптимизационные вопросы мимо?
Потому что низкоуровневой оптимизацией на практике никто не занимается. Под все основные структуры и алгоритмы есть обёртки и обёртки над обёртками. А тем, кто на продакшене хочет заниматься вилосипедостроением, надо по рукам давать.
Реальная оптимизация выглядит так:
П1. Правдами и неправдами, через логгирование, профилирование и дебаггинг запросов находим тормозящий кусок кода
П2. Анализируем кусок кода. Чаще всего проблема в инфраструктуре - некорректно пользуемся БД (шлём запросы в цикле, отсутствует индекс, либо недостаточно узкая выборка). Решаем либо быстро, либо чуть дольше (партицирование, шардирование, масштабирование ресурсов).
П3. Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать, клепаем тест-кейсы на изначальный вариант, смотрим, чтобы проходили на конечном, оцениваем время выполнения. Профит!
Не было упоминания стратегического планирования развития продукта
> Собеседование не на архитектора вроде бы.
Возможно, мои полномочия миддла чуть пошире стандартных, но для меня нормально, имея на руках продуктовое описание фичи, оценить её влияние на систему, ресурсозатраты на разработку и эксплуатацию и затем, провести полный цикл разработки сервиса, и, потенциальное внедрение взаимодействия с другими сервисами системы.
Не было вопросов про системы контроля версий
> И не на джуна.
Спорный вопрос. Здесь можно придумать задачи более усложнённые, по типу конфликтов, юз-кейсов ребейза, черри-пиков и сквошей. Но тут ладно, может и соглашусь, что джун тоже может всё это знать.
А комментаторы выше видимо все как на подбор, HR-ы и IT рекрутеры, раз решили меня загуглить?
При скрининге кандидата - это норма. В кейсе выше - нет.
В профиле у меня этой информации нет. Значит надо гуглить ФИО, либо никнейм. У меня такого желания никогда при прочтении статей не возникало, а Вы вон даже до ВК успели дойти
В 2022 был на проекте без хайлоада. В 2024 перешёл на хайлоад.
Сталкерить людей нехорошо :)
Если Вам так интересно, то вот мой вопрос про apache в докерах со stackoverflow, от 2022 года. Никто ничего не подтирал :)
https://stackoverflow.com/questions/73777312/why-im-getting-error-while-trying-to-redirect-requests-from-nginx-to-phpapach
Вторичный скрининг резюме я проводил самостоятельно. Грубо говоря, давал первичные инструкции HR по требуемым навыкам. Если отклик удовлетворял, резюме направлялось мне. Много отсеивал из-за отсутствия инфы в «обо мне», и подробного описания выполняемых задач на предыдущих проектах. На собеседования приглашали только с моего одобрения. Вероятно оттуда и эффективность, так как я уже на этапе чтения резюме мог сказать, кто мне как коллега однозначно не подойдет
Я не пытался туда устроиться. Меня сами нашли и предложили пройти собеседование.
На PHP. На основе воркеров Workerman и асинхронного AmPHP
Как интересно у Вас выходит. Всё мимо. Видимо по Вашему мнению middle php разработчик должен целыми днями велосипеды самописные для бинарного поиска строить и сложность алгоритмов высчитывать. Зато руками и в пределах своей зоны ответственности!
Возможно у нас разные понятия о грейдах, но по моему мнению, middle - это не просто боевая единица, а сотрудник, способный и менторством заниматься, и оптимизацией и проектированием архитектуры, и другим спектром более сложных задач. Ему в конце концов как-то надо же сеньором становиться.
Исходя из Вашего описания уже сейчас всех мидлов можно выбросить и передать все задачи копилоту. (Про джунов я вообще молчу)
Таких претензий никогда не понимал. Я получил какой-то опыт, поделился им и своим видением ситуации, предложил альтернативный сценарий проведения собеседования. Разве не для этого "мы тут все и собрались"? Так что без обид не выйдет.
Странные выводы Вы сделали.
В реальной жизни так не бывает, чтобы из таск трекера сразу готовая фича. Продуктовая команда приносит часто весьма сырое описание задачи. Моё предназначение, как разработчика - оценить задачу, её влияние на продукт в целом, предложить лучшее решение, иногда оно может не совпадать с видением продактов. После дискуссии начать цикл разработки, сначала проектирование, затем разработка, тестирование (юнит, интеграционное, нагрузочное), затем ввод в эксплуатацию. Потом наблюдение, оптимизация при необходимости.
А есть ещё баги и инциденты, которые ещё отловить надо. Есть ревью кода и менторство над младшими разработчиками.
Бывают ещё сложные архитектурные задачи. Как пример: мигрировать все сервисы с elasticsearch v6 на elastcisearch v8. Приходится переопределять архитектурные подходы, реализовывать паттерн стратегии, писать скрипты для безболезненной миграции данных, править спеки сервисов для деплоя.
Это практика "собеседование как культ", когда оно перестаёт иметь хоть что либо общее с реальными решаемыми задачами.
На джуна? Возможно. Было время, когда на вопросы по структурам и алгоритмам данных я отвечал. На мидла таких вопросов быть не должно.
Я уверен, мои бывшие одногруппники также назовут ответ на эти вопросы. Потому что теорию зубрили. Я теорию не зубрил, а проекты сложные делал и автоматы получал за них.
Ну не знал я значения термина ДНС до собеседования. Ну узнал я его значение сейчас, что изменилось?
Незнание не мешало мне в своё время basic auth делать на апаче, рейт-лимиты с редиректами на порты в nginx прописывать, или certbot-ом SSL подписывать. Точно так же, как и знания этого термина абсолютно ничего не дают на практике.
Нет. Мы не "сайтики лепим", а высоконагруженные микросервисы готовим, с сотнями тысяч RPM и сотнями терабайт данных. И нет, знания линейного и бинарного поиска здесь не нужны.
Общепринятая терминология - это "сложность алгоритмов". Термин "О-нотация" я слышал впервые.
Потому что низкоуровневой оптимизацией на практике никто не занимается. Под все основные структуры и алгоритмы есть обёртки и обёртки над обёртками. А тем, кто на продакшене хочет заниматься вилосипедостроением, надо по рукам давать.
Реальная оптимизация выглядит так:
П1. Правдами и неправдами, через логгирование, профилирование и дебаггинг запросов находим тормозящий кусок кода
П2. Анализируем кусок кода. Чаще всего проблема в инфраструктуре - некорректно пользуемся БД (шлём запросы в цикле, отсутствует индекс, либо недостаточно узкая выборка). Решаем либо быстро, либо чуть дольше (партицирование, шардирование, масштабирование ресурсов).
П3. Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать, клепаем тест-кейсы на изначальный вариант, смотрим, чтобы проходили на конечном, оцениваем время выполнения. Профит!
Возможно, мои полномочия миддла чуть пошире стандартных, но для меня нормально, имея на руках продуктовое описание фичи, оценить её влияние на систему, ресурсозатраты на разработку и эксплуатацию и затем, провести полный цикл разработки сервиса, и, потенциальное внедрение взаимодействия с другими сервисами системы.
Спорный вопрос. Здесь можно придумать задачи более усложнённые, по типу конфликтов, юз-кейсов ребейза, черри-пиков и сквошей. Но тут ладно, может и соглашусь, что джун тоже может всё это знать.