Расскажу немного о себе
Я являюсь действующим PHP middle разработчиком в одной средней компании. Занимаемся разработкой highload микросервисов в B2B сфере. Клиентами являются крупные интернет-магазины, в 5 странах (РФ в их числе), которые на слуху у каждого. Суммарно обрабатываем около 50к запросов в секунду, храним миллиарды записей и отвечаем за качество и жизнеспособность около тысячи интернет-магазинов. В команде я являюсь единственным PHP разработчиком. При том, что все ключевые сервисы написаны на PHP, с итальянскими нотками (наш любимый аля‑спагетти код).
Имею опыт в техническом собеседовании, в том числе и других middle php разработчиков. За свою карьеру провёл пару десятков таких собеседований, по результатам которых было нанято около 5 разработчиков и 2 аутсорс компании. (это происходило на предыдущей работе)
Почему ВК?
Текущая работа меня по большей части устраивает. Но на HH и хабр карьере держу резюме в статусе «рассмотрю предложения». В основном, чтобы мониторить актуальное положение на рынке.
HR из вконтакте меня нашли самостоятельно и сами со мной связались. На выбор было предложено 3 вакансии с рассмотрением middle php программиста. Однако, выбор на текущем этапе делать было не обязательно, так как технические интервью проводятся общими для всех.
Также, мне сразу же сообщили, что первичный этап «собеседование с HR» мы можем пропустить, так как они связались со мной сами. Далее, предполагается техническое интервью, с обзором теоретических знаний и лайвкодингом. (Сколько в последствии может быть таких этапов, не уточнялось)
Организация
К организации процесса найма у меня вопросов практически нет. Здесь всё правда было хорошо. В течение суток была согласована дата и время проведения технического интервью, были отправлены соответствующие ссылки. Интервьюеры подключились во время. Со стороны HR было напутствие по формату собеседования и укрупнённым темам, к которым можно подготовиться.
Несмотря на обещанный фидбек в течение 2-3 дней, пришлось напоминать HR об этом самостоятельно через неделю. Но с моей точки зрения - это вполне себе простительно.
Моя подготовка
Особо много времени уделено подготовке не было. Освежил в памяти самые известные паттерны разработки, быстро пробежался по основным угрозам безопасности. На практике, отражение атак достигается обычным здравым смыслом.
Как это вижу я
SQL инъекции - просто не нужно класть сырой ввод пользователя в SQL запрос. Валидацию никто не отменял. Добавить туда prepared statements и инъекции не страшны
DDoS атаки - проводить нагрузочное тестирование продукта. Рассчитывать 5x-10x увеличение запросов от текущих средний показателей RPM. НЕ ДЕЛАТЬ ЗАПРОСЫ К БД В ЦИКЛЕ!
XSS атаки - снова валидация пользовательского ввода, html escape
Ну и совсем очевидное - хеширование паролей, надёжное хранение секретных ключей, разграничение прав и доступа к БД.
Больше всего подготовки уделил изучению особенностей KPHP - PHP диалекта, на котором ведётся основная разработка в ВК. Изучал принципы его работы, компиляцию в C++, и связанные с этим особенности.
Техническое интервью
Здесь меня сбили с толку буквально с самого начала. Интервью началось с вопроса о том, на основе какого ЯП мне удобнее всего будет проводить интервью (мы же вроде на PHP разработчика подавались, нет?).
Подтвердив, что я действительно хочу проводить интервью на основе PHP, я слышу первый вопрос: что такое указатели? Немая сцена, занавес.
Здесь я судорожно пытаюсь вспомнить свои эксперименты с C++ в университете, и то как указатели связаны с памятью. Указываю интервьюеру, что указателей в PHP не завезли, рассказываю про ссылки и принципы работы с ними. Этот ответ интервьюера судя по всему не удовлетворил.
Следующим этапом стала игра "угадай значение термина". Вопрос: что такое "О-нотация". Я отвечаю, что не знаю, прошу подсказать о чём вообще идёт речь. В итоге оказывается, что это про сложность алгоритмов, на что я полно и развёрнуто отвечаю, вспоминая даже сколько байт весит каждый тип переменной и про сложность лучших и худших случаев пузырька.
Сильно выбесил такой формат. Я мог десятки раз работать или реализовывать тот, или иной подход, но я просто не знаю тот вариант терминологии, который задаёт интервьюер. Собеседование начинает скатываться в викторину, причём подсказки даются не всегда.
Следующую часть я назову "вопросы стажёру". Можете закидать меня тапками, но нет, я не помню, чем бинарный поиск отличается от линейного, не помню по какому принципу там эти деревья строятся, я не помню как работает хеш-таблица, и что такое очередь с приоритетом. Нет, мне ни разу не пригодились эти знания за суммарные 4 года решения задач для бизнеса и 2 года работы мидлом.
На этапе вопросов с БД, всё было очевидно и хорошо. В этой теме у меня нет никаких препятствий, могу рассказать и про типы индексов с их use-case, и про уровни изоляции транзакций с разницей между ними, и про оптимизацию производительности, с партицированием, шардированием, репликацией, и про прикладное использование подхода CQRS. Рассказал также про аналитические СУБД, особенности работы с Clickhouse, работу с движком поиска Elasticsearch, кеши редиса. Все эти темы были выстраданы практическим опытом и прикладными решениями, помогающими бизнесу работать и быть эффективным.
В заключение теоретической части были вопросы про работы сетей и безопасность. Снова срезался на терминологии. Я - тот кто настраивал на сервере ssl шифрование через certbot-а, устанавливал локальную сеть на основе DHCP сервера с распределением IP, писал bash скрипты и линуксовых демонов, не знал что ответить на вопрос: что такое DNS?
Завершилось техническое интервью 10 минутной сессией лайвкодинга, в виде скопированной алгоритмической задачи из leetcode, и оптимизацией решения. К этому у меня особо претензий пожалуй нет, если смотреть на лайвкодинг со стороны проверки софтскиллов, на взаимодействие с интервьюером и показом принципов мышления и решения задач.
Чего на интервью не было?
Совершенно не было вопросов про их диалект KPHP. Здесь были вопросы интервьюеру с моей стороны, про то, как он взаимодействует с последними версиями PHP и режимом use-strict, а также пару вопросов про подкапотное преобразование в C++.
Что больше всего удивило - полное отсутствие вопросов про паттерны разработки, про архитектурные подходы и методологии проектирования. Не было вопросов про оптимизацию и решения около-бизнесовых кейсов. Не было вопросов про системы контроля версий. Не было упоминания методологий процесса разработки и стратегического планирования развития продукта. Даже unix системы не упомянули.
Как собеседовал я?
Как уже упоминал в начале текущей статьи, мне также доводилось проводить собеседования на позицию middle php разработчиков.
Мне искренне непонятен смысл «прогона» по теории и формат викторины. Моё собеседование выглядело как разбор около‑бизнесового кейса. Давалась проблема, разработчику предлагалось предоставить пути для её решения. В процессе интервью между нами шёл диалог, в результате которого можно было как уходить «вбок», углубляясь в прикладные знания того, или иного обсуждаемого аспекта, так и узнавать напрямую потенциальные решения, а главное пути, по которым разработчик планирует их достигать. В процессе такого диалога, мне хватало получаса, чтобы узнать:
Какие у человека софт‑скиллы? Может ли он обсуждать решение задачи, способен ли на кооперацию, готов ли отстаивать собственное мнение?
Сработаемся ли мы с человеком по характеру, как он себя ведёт в ситуациях, когда ему необходимо найти решение?
Понимает ли человек что‑то в обсуждаемом вопросе? Или его готовили к «викторинам» на курсе «войти в айти».
Был ли у разработчика реальный опыт работы, и понимает ли он как решать прикладные задачи, которые (сюрприз!) ему предстоит решать у нас, в случае успешного трудоустройства.
За полчаса, не тратя ни своё время, ни время кандидата, я с уверенностью мог дать ответ: Да, или Нет. И по моему скромному мнению — это должно быть единственной целью хорошего интервью. Единственного технического интервью.
Что в итоге?
В итоге, через неделю, по запросу фидбека, мне пришёл ответ, что со мной было приятно общаться, но ищут кандидата с более углублёнными знаниями (знаниями чего?).
Резюмируя: на собеседовании на позицию middle php разработчика, в VK ищут не middle, не PHP, и даже не уверен, что разработчика.
Вопрос к VK — а вам точно оно надо?
Комментарии (61)
jhoag
03.02.2025 13:33что такое DNS?
Бывает. С позиции адвоката дьявола: такие вопросы помогают выяснить, может ли человек объяснить сложные вещи простыми словами и, как следствие, насколько хорошо понимает о чём говорит. Выучить определения несложно, другое дело — в двух словах, как ребёнку, рассказать, что такое DNS или O-нотация.
В остальном сочувствую. Ваш подход к проведению собеседований, очевидно, рациональнее.
Wesha
03.02.2025 13:33может ли человек объяснить сложные вещи простыми словами
Это Вы сейчас про интервьюера?
В том смысле, что он мог бы перезадать вопрос: «расскажите про систему доменных имён».
fo_otman
03.02.2025 13:33Я тоже только на собесе узнал, что паттерн CQRS использую уже 2 года. Зачем любой фигне давать отдельное название? Давайте использование ложки при поедании супа назовем "спун-юзингом" и будем в резюме писать "опыт применения паттерна спун-юзинг 25 лет".
alexandr93
03.02.2025 13:33Проблема в том, что когда обсуждается какое-то решение, то проще сказать: "Предлагаю использовать CQRS". Знание общей терминологии позволяет быстрее излагать свои мысли и не приходить к недопониманиям.
VladimirFarshatov
03.02.2025 13:33Не-а. Это способ выпендриться перед коллегами и только. Коллегам, будет понятно краткое смысловое описание на русском или английском, смотря с чем у них проще..
ForestDront
03.02.2025 13:33Проблема в том, что эта общая терминология общая только внутри вашего информационного пузыря. В других пузырях могут быть другие термины. Вот как-то приехал я в другой город и спрашивают меня какой версией силенга собирал проект. А я стою и туплю. Не собирал я проект силенгом, только клангом....
Boomerang
03.02.2025 13:33Затем что по CQRS (и любой другой фигне) пишут книги, статьи и комментарии. В которых скорее всего описаны подходы и решены проблемы, которые в вашей домашней реализации не предусмотрены. Это как "Я уже 10 лет пишу button1.onclick, и оказывается использую ООП. Ну и дебильное название". ООП гораздо шире чем вызов метода у объекта.
joffer
03.02.2025 13:33вы бы со "спун-юзингом" потише себя вели, а то "утром в газете - вечером в куплете")))
Boomerang
03.02.2025 13:33Поздравляю с выходом в большой мир! Отлично понимаю твои переживания — сам проходил через это лет 10 назад, но тогда всё было совсем иначе.
Просто поясню: компания VK ≠ социальная сеть VK и уж точно не то, что про неё писали на Хабре десять лет назад. По сути, VK — это mail.ru, а внутри него миллион команд, многие из которых вообще не связаны с оригинальным VK.
Что касается KPHP — учить его не было необходимости. Внутренние языки компаний редко спрашивают на собеседованиях, потому что внешние кандидаты априори их не знают и не обязаны знать.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
Davidaa_WoW Автор
03.02.2025 13:33То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
Это практика "собеседование как культ", когда оно перестаёт иметь хоть что либо общее с реальными решаемыми задачами.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
На джуна? Возможно. Было время, когда на вопросы по структурам и алгоритмам данных я отвечал. На мидла таких вопросов быть не должно.
ky0
03.02.2025 13:33Вопросы на собеседованиях могут не нравиться, но пенять можно только на глубину погружения в предмет, и уж точно не на то, что вопросы "не для мидла, а для джуна".
Предполагается, что множество знаний джуна полностью помещается внутрь множества знаний мидла. Если это не так - имеет смысл более реалистично оценивать свой грейд.
joffer
03.02.2025 13:33но вот они были - и вы на них не ответили) получается, вы и не мидл, вы и не джун, вы - просто разработчик, который работал, получил какой-то опыт и экспертизу, своё видение и предпочитаете заточенность на решение задач какому-то общему кругозору (который, как правило, хотят видеть большие компании, ведь, как правило, туда всегда ищут больше, чем надо - вдруг куда-то вырастет. Исполнителей по факту наличия задач в таск-трекере обычно ищут фриланс-конторы, которым абсолютно всё равно на вообще любые ваши знания и опыт, пока вы можете реализовывать задачи)
Davidaa_WoW Автор
03.02.2025 13:33Странные выводы Вы сделали.
В реальной жизни так не бывает, чтобы из таск трекера сразу готовая фича. Продуктовая команда приносит часто весьма сырое описание задачи. Моё предназначение, как разработчика - оценить задачу, её влияние на продукт в целом, предложить лучшее решение, иногда оно может не совпадать с видением продактов. После дискуссии начать цикл разработки, сначала проектирование, затем разработка, тестирование (юнит, интеграционное, нагрузочное), затем ввод в эксплуатацию. Потом наблюдение, оптимизация при необходимости.
А есть ещё баги и инциденты, которые ещё отловить надо. Есть ревью кода и менторство над младшими разработчиками.
Бывают ещё сложные архитектурные задачи. Как пример: мигрировать все сервисы с elasticsearch v6 на elastcisearch v8. Приходится переопределять архитектурные подходы, реализовывать паттерн стратегии, писать скрипты для безболезненной миграции данных, править спеки сервисов для деплоя.
Starl1ght
03.02.2025 13:33Ну, допустим, в гугле на принципала у тебя тоже будут спрашивать алгоритмы и структуры
aelaa
03.02.2025 13:33TL;DR: "Почему меня не спросили то, что я знаю".
Даже уважение какое-то к VK появилось.
Очень удивило незнание термина "О-нотация". Это не "вариант терминологии", это общепринятая терминология. Впрочем, вряд ли к автору бы придрались про термин, если он действительно рассказал про сложность.
я не помню, чем бинарный поиск отличается от линейного
...
Не было вопросов про оптимизацию
А чего про нее спрашивать, если даже низкоуровневые оптимизационные вопросы мимо?
Не было упоминания стратегического планирования развития продукта
Собеседование не на архитектора вроде бы.
Не было вопросов про системы контроля версий
И не на джуна.
У автора очень специфическое понимание навыков мидла. Это, конечно, проблема индустрии, что мы общие нормативы родить не можем, но вот результат - джуны без теоретической базы после 4х лет работы радостно рвутся на мидл. А мелким компаниям не жалко звания на погоны раздавать, если человек им пользу приносит.
Davidaa_WoW Автор
03.02.2025 13:33Очень удивило незнание термина "О-нотация". Это не "вариант терминологии", это общепринятая терминология.
Общепринятая терминология - это "сложность алгоритмов". Термин "О-нотация" я слышал впервые.
А чего про нее спрашивать, если даже низкоуровневые оптимизационные вопросы мимо?
Потому что низкоуровневой оптимизацией на практике никто не занимается. Под все основные структуры и алгоритмы есть обёртки и обёртки над обёртками. А тем, кто на продакшене хочет заниматься вилосипедостроением, надо по рукам давать.
Реальная оптимизация выглядит так:
П1. Правдами и неправдами, через логгирование, профилирование и дебаггинг запросов находим тормозящий кусок кода
П2. Анализируем кусок кода. Чаще всего проблема в инфраструктуре - некорректно пользуемся БД (шлём запросы в цикле, отсутствует индекс, либо недостаточно узкая выборка). Решаем либо быстро, либо чуть дольше (партицирование, шардирование, масштабирование ресурсов).
П3. Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать, клепаем тест-кейсы на изначальный вариант, смотрим, чтобы проходили на конечном, оцениваем время выполнения. Профит!
Не было упоминания стратегического планирования развития продукта
> Собеседование не на архитектора вроде бы.
Возможно, мои полномочия миддла чуть пошире стандартных, но для меня нормально, имея на руках продуктовое описание фичи, оценить её влияние на систему, ресурсозатраты на разработку и эксплуатацию и затем, провести полный цикл разработки сервиса, и, потенциальное внедрение взаимодействия с другими сервисами системы.
Не было вопросов про системы контроля версий
> И не на джуна.
Спорный вопрос. Здесь можно придумать задачи более усложнённые, по типу конфликтов, юз-кейсов ребейза, черри-пиков и сквошей. Но тут ладно, может и соглашусь, что джун тоже может всё это знать.
maaGames
03.02.2025 13:33Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать
До чего дошёл прогресс, вкалывают роботы, а не человек... Но это объясняет причину отсутствия начальных знаний. Если решаешь только типовые задачи, то копипаста со SO и chatGPT позволяют решать большинство вопросов, надо только немного синтаксис языка знать, английский для составления запросов и в целом достаточно. Как же приятно быть программистом, оказывается. Даже завидно немного :)
ReadOnlySadUser
03.02.2025 13:33кидаем этот кусок в GPT,
...и идём собирать вещички) В крупных компаниях за такие телодвижения ИБ-шники очень быстро прибегут)
aelaa
03.02.2025 13:33Сложность алгоритмов можно выразить в wtf/min. А можно в О-нотации. Про Ω и Θ видимо можно даже не спрашивать.
Потому что низкоуровневой оптимизацией на практике никто не занимается
Во-первых полагаю, что именно в ВК ей занимаются очень даже. Во-вторых "мне никогда не попадалось" - вообще не метрика. Именно поэтому вредно на старте карьеры 4 года сидеть на одном месте. Обертки над обертками заканчиваются leftpad'ом, а код из GPT, если уж такая идея в голову пришла (хотя тут должен быть другой вопрос), может закончится замедлением другой части приложения, просто потому что GPT не в контексте всей системы. TTM и ориентирование на бизнес - хорошо, но желательно чтобы код при этом все-таки работал
для меня нормально, имея на руках продуктовое описание фичи, оценить её влияние на систему, ресурсозатраты на разработку и эксплуатацию и затем, провести полный цикл разработки сервиса, и, потенциальное внедрение взаимодействия с другими сервисами системы
На соседние элементы - да, уровень мидла. На систему в целом - архитектора.
Я стараюсь не быть токсиком, просто желаю выбраться из инкубатора, и понять, что мир сложнее, чем он кажется из средней компании с highload-микросервисами на php.
ildarz
03.02.2025 13:33Я, возможно, чего-то не понимаю, но даже я, ни разу не разработчик, знаю, что такое указатели и О-нотация, хотя для меня эти знания были актуальны ...дцать лет назад в студенческой практике и в качестве хобби, причем программирование у меня было отнюдь не основным интересом. Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Мне сложно судить, зачем такие вопросы задают на собеседованиях конкретно в ВК, но с моей колокольни неумение ответить на такие вопросы - красный флаг, могущий говорить о серьезных пробелах в фундаментальных знаниях у человека. И, какой бы у него ни был практический опыт, при прочих равных я однозначно предпочел бы кандидата, у которого таких пробелов нет. Потому что отсутствие базовых знаний - плохой знак, и в своей профессиональной области я не раз в этом убеждался.
VladimirFarshatov
03.02.2025 13:33Указатели в Пыхе это отдельная песня. Как таковых их там нет на самом деле, но .. применять можно и вполне успешно. Вот такая вот загогулина.. :)
Davidaa_WoW Автор
03.02.2025 13:33Я, возможно, чего-то не понимаю, но даже я, ни разу не разработчик, знаю, что такое указатели и О-нотация, хотя для меня эти знания были актуальны ...дцать лет назад в студенческой практике и в качестве хобби, причем программирование у меня было отнюдь не основным интересом. Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Я уверен, мои бывшие одногруппники также назовут ответ на эти вопросы. Потому что теорию зубрили. Я теорию не зубрил, а проекты сложные делал и автоматы получал за них.
Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Ну не знал я значения термина ДНС до собеседования. Ну узнал я его значение сейчас, что изменилось?
Незнание не мешало мне в своё время basic auth делать на апаче, рейт-лимиты с редиректами на порты в nginx прописывать, или certbot-ом SSL подписывать. Точно так же, как и знания этого термина абсолютно ничего не дают на практике.
dom1n1k
03.02.2025 13:33"Не помнить" О-нотацию, отличие линейного и бинарного поиска или принцип работы хеш-таблицы можно только в одном случае - если ты этого никогда и не понимал. Если один раз разобрался и понял базовую идею, забыть это уже невозможно, настолько нам всё просто и естественно.
Это НЕ викторина на знание редких терминов, это проверка понимания самых-самых базовых концепций кампутер-сайнс. Интервьюер простейшими вопросами успешно отсеял кандидата с неподходящим им майндсетом. Кому-то это неважно, а им важно. Нормальный собес.
ky0
03.02.2025 13:33Битва двух якодзун - с одной стороны не всегда релевантные вопросы, с другой человек, считающий себя мидлом, не знающий про О-нотацию и DNS.
VladimirFarshatov
03.02.2025 13:33Выше уже писал: О-нотация не программерское, а математическое понятие. Чел без математики может и не знать термина, но вполне внятно описывать сложности тех или иных алгоритмов своими словами.
Кстати, О-нотация весьма приближенная оценка. Так алгоритм О(N^2) может оказаться шустрее чем алгоритм O(N) при малых N и большой подготовительной работы у второго, которая тем не менее const. Но, с кочки зрения О-большого, второй алгоритм .. выгоднее. Вот такая вот загогулина..
ky0
03.02.2025 13:33Я не настоящий сварщик, и большую часть времени, как девопс-инженер, ничего сложнее лайтового перекладывания данных в Питоне не пишу - но почему-то в курсе про О.
И да, если бы мне кто-то на собесе ответил ровно как вы - что это обобщённая оценка зависимости времени выполнения от размера данных, я бы засчитал это как исчерпывающий ответ. Так же, как засчитываю ответ про OSI - что это древняя, выдуманная учёными и имеющая весьма опосредованное отношение к реальности штука. Так же, как засчитываю ответ про CAP-теорему в виде анекдота "быстро, качественно и недорого - выберите любые два".
Это вопросы кругозора и отсутствия пробелов в фундаментальном понимании. Важно знать принцип, а не вызубрить определение.
Nalivai
03.02.2025 13:33Очень многословный способ сказать "я тоже понятия не имею что такое О нотация, и отказываюсь учиться"
maaGames
03.02.2025 13:33Миддл, незнающий разницы между бинарным и линейным поиском? Это в Y2K25 такие миддлы теперь?
Ни в коем случае не хочу вас как-то унизить или обидеть, просто это базовые знания любого программиста, который программирует дольше одного дня. Каким чудодейственным образом вы подробно ответили про О-сложность, если не знаете разницу между бинарным и линейным поиском? Ничего не утверждаю, но недовольство интервьювера вполне могло быть обоснованным.
Я не знаю PHP, возможно, для бэкэнда все эти знания и не нужны, лепите сайтики по готовым фреймворкам и в ус не дуете :)
kalombo
03.02.2025 13:33Миддл, незнающий разницы между бинарным и линейным поиском? Это в Y2K25 такие миддлы теперь?
Закон хабра: если человек напишет статью или комментарий в которой укажет, что какую-то вещь не знает, то обязательно найдется человек, который эту вещь знает и думает, что это прям обязательное для всех программистов знание. Обязательно в стиле "фу, не сеньор". Для контекста добавлю, что когда читал статью, то не смог вспомнить, алгоритм бинарного поиска. Помню по названию, что изучал для алгоритмов и собесов, но поскольку в работе не требовался, то и забыл вообще про что он.
Ответить на это хочется как в анекдоте про мартышку: "дура не дура, а свои 100 рублей имею". Причем не в том смысле, что паразит, а в том смысле, что приношу пользу бизнесу, несмотря на незнание.
maaGames
03.02.2025 13:33Так никто и не просил вспоминать алгритм бинарного поиска. А по памяти его ни один нормальный человек не напишет, если предварительно специально код не заучивал (это утверждение основано на том, что баги в алгоритме его изобретатель много лет отыскивал, прежде чем он безсбойно заработал). Его спросили про разницу между этими поисками и вопрос следовал после вопроса про О-сложность. Как бы очевидно, какой ответ хотели услышать.
Davidaa_WoW Автор
03.02.2025 13:33Я не знаю PHP, возможно, для бэкэнда все эти знания и не нужны, лепите сайтики по готовым фреймворкам и в ус не дуете :)
Нет. Мы не "сайтики лепим", а высоконагруженные микросервисы готовим, с сотнями тысяч RPM и сотнями терабайт данных. И нет, знания линейного и бинарного поиска здесь не нужны.
maaGames
03.02.2025 13:33Потому что данные хранятся в БД. И вы знаете, что к записям надо обращаться по индексированному ключу. А если индексной таблицы нет, то её приходится создавать. Без этих знаний вы никак не смогли бы работать с БД (поэтмоу вы и имеете представление про О-сложность). Это всё те же знания линейного и бинарного поиска, но абстрагированные за интерфейсом СУБД.
XelaVopelk
03.02.2025 13:33" Без этих знаний вы никак не смогли бы работать с БД" Почему? Имея опыт собеседований базистов могу сказать, что далеко не всякий пришедший собеседоваться на сеньора может внятно объяснить как ложится на О-нотацию те или иные опрерации работы с БД.
maaGames
03.02.2025 13:33То есть сеньор(!!!) пишет работу с БД, не понимая базовых принципов работы СУБД? А вы точно собеседовали сеньоров, а не джунов?
Уточню, что я говорю не о конкретных реализация конкретных БД - эти данные почти никто в три часа ночи сказать не сможет. Я говорю о примитивной информации, типа "поиск по индексированной БД это O(logN), а поиск по не индексированной O(N^2)". Тут можно поспорить про реализацию, что где-то не бинарный поиск, а хэш-таблица и O(N), вместо (logN), но в качестве первого приближения и без конкретики это адекватный ответ. А вот если сеньор скажет "я не понимаю, о какой О-сложности вы говорите, я с высоконагруженными БД работаю через чатГПТ", то как бы HR плохой, да.
maaGames
03.02.2025 13:33А если серьёзно, то проходить "первичную фильтрацию" у HR, который даже не знает, на какую должность вы претендуете и который не способен адекватные вопросы задать - это трагедия всей IT-индустрии. Вот вы опытный разработчик хайлоад сервисов и устраиваетесь на аналогичную позицию, а вам задают вопросы не только из другой области, но ещё и на другом языке программирования... Я считаю большим везением, если удаётся собеседоваться сразу со специалистом или с будущим руководителем, в обход первичной фильтрации. Хотя бы не спросили, кем вы видите себя через 5 лет и не попросили нарисовать дом :)
surarus
03.02.2025 13:33Поздравляю! Вы в начале пути! Найм в биг.тех, это тоже своего рода "навык".
Вы столкнулись с процессом найма в крупной технологической компании. В таких организациях процесс собеседований, как правило, "систематизирован", что обусловлено большим количеством проводимых интервью.
Поймите, что для компании крайне сложно оценить ваши уникальные навыки, таланты и ваш "брильянт способностей".
Поэтому процесс собеседований строится на основе заранее подготовленного списка вопросов, на которые кандидат должен ответить. Интервьюер, в свою очередь, делает пометки о качестве и полноте ваших ответов.
Более того, технологический прогресс шагнул ещё дальше. Существуют прецеденты (в других компаниях) использования ИИ в процессе собеседования, когда ИИ анализирует ваши ответы, суммаризирует их и выявляет критические паттерны и несоответствия в навыках. И стоит Вам применить слово паразит "честно говоря, я не уверен", он с лихвой пометит вас "красным флажком вруна".
А вообще, верно говорили выше. Высококлассный специалист в биг техе, должен не только быть хорошим техническим специалистом, но он должен знать как правильно "кукарекать" в кофейне за "ванильным латте", так что учите "определения и аббревиатуры", чтобы быть в этой банде )))
P.s. ИМХО вся суть всех этих "собеседований" в "Миллион за старания, а не за результат."
evgeniy_kudinov
03.02.2025 13:33Странно для Web-developer, конечно, что вы не смогли объяснить, чем бинарный поиск отличается от линейного и что такое DNS. Ну зато теперь, надеюсь, знаете) Пора уже вам от практики переходить к теории для систематизации опыта.
XelaVopelk
03.02.2025 13:33"ищут кандидата с более углублёнными знаниями (знаниями чего?)"
Я так думаю, что они теперь в hr-ской базе проставили, что соискатель и по софтскилам "не торт", если он на демонстрацию очевидных косяков по базовым знаниям, начал с пеной у рта что-то громко доказывать.
Jijiki
03.02.2025 13:33а вот интересно есть 2 сущности массив односвязный[1024] и двоичное дерево[1024] вот надо найти 1024 еллемент в линейном массиве мы тривиально будем идти вроде до 1024, а вот с бинарным 32 чтоли?
ну получается в одном случае 1024 прыжка а в двоичном без перестраивания поидее 640 или я ошибся или 512 прыжков вот тут выйгрыш наверно
Скрытый текст
0 1 2 3 4 5 6 7 8 ------
Farongy
03.02.2025 13:33В классическом бинарном дереве поиск будет зависеть от элементов. Если это будут числа 1...1024, то поиск тоже будет линейным.
Для сбалансированного дерева будет log2 (1024) = 10
Jijiki
03.02.2025 13:33простите это прыжков до 1024?
в дерево введены последовательно числа от 0 до 1024 - 1024 последний елемент и так же последовательно от 0 до 1024 введены значения в односвязный список
joffer
03.02.2025 13:33|| Совершенно не было вопросов про их диалект KPHP
А с чего бы они были? Вас могли собеседовать на самые разные проекты с самым разным пхп - от обычного легаси php5.6 (но надеюсь, там уже нету такого кода), так и на php7.1, на 8.2. KPHP, насколько понимаю - какой-то внутренний диалект, который вообще не факт, что до сих пор используется. А если и используется, то в каких-то нишевых разработках и пилят такой код сениоры либо мидлы, которых получили опыт/экспертизу. Было бы странно у вас спрашивать что-либо по каким-то внутренним наработкам, диалектам языков или особенностям настроек чего-либо.
Здесь были вопросы интервьюеру с моей стороны, про то, как он взаимодействует с последними версиями PHP и режимом use-strict, а также пару вопросов про подкапотное преобразование в C++
такое довольно странно спрашивать у интервьюера, если это не разработчик с проекта или тим-лид - и даже если это так, взаимодействие с use-strict - оно или есть, или нету, что до подкапотного преобразвания в C++ - такое не особо есть смысл спрашивать, так как если php код какой-то движок и переваривает в C++, то на это дело есть отдельный транспайлер/конвертор, делать обзорную лекцию по которому - достаточно странно, с этим просто столкнёшься или нет, а столкнувшись или изучив внутренню документацию, станет понятно, какой код переварит успешно, а какие места лучше писать по-другому. Все эти знания опять же спрашивать странно, так как они общего характера для большинства транспайлируемых/конвертируемых языков вроде того же HaXe. А какую-то конкретику/специфику вряд ли можно так выделить, чтобы на интервью рассказать.
Это похоже на то, чтобы на собеседовании спрашивать, "а как у вас на проекте Ts в Js переваривает, есть ли свой диалект и какие особенности". Ну переваривает и переваривает, за это отвечает какой-то софт или библиотека или самописная вещь, но если вас не собеседуют прям туда - зачем вообще копать в такие узконаправленные вещи, неплохо бы сосредоточиться на общем уровне, а в специфику вас и так введут или покажут.
полное отсутствие вопросов про паттерны разработки
а чего про них спрашивать-то? как правило, типовые задачи сами по себе складываются в эти самые шаблоны, не стоИт задачи, чтобы писать код который бы именно вот по шаблонам по канонам был выполнен, задача диктует исполнение и иногда это - фабрика, иногда - декоратор, иногда адаптер, а бывает и такое, что это класс-одиночка-божественный объект-шестирукий Шива, нафаршированный методами как следует.
Получается, базовые вещи по такому вроде бы и спрашивать нечего, а специфику незачем, типа там "как бы вы реализовали шаблон "Мост" на php"? Что и кому дадут такие вопросы и ответы, зачем это?Просто показать, что "я учил"?
архитектурные подходы и методологии проектирования
выше справедливо замечали, что это не мидлового уровня задачи, сейчас бы доверить мидлу тасовать архитектуру или тащить DDD на микросервисы или там свой фреймворк запилить или "давайте перейдём на Лару - все переходят на Лару". Этим другие люди заниматься должны, другого опыта, квалификации и экспертизы
Не было вопросов про оптимизацию и решения около-бизнесовых кейсов
оптимизацией опять же другим бы людям заниматься, то, что вы с этим сталкивались и разобрались - здорово, было ли это правильно? Нужно ли будет это на текущем проекте? Неясно. Это и выглядит не совсем правильно, если на проекте мидлы роют в оптимизацию - это показатель проблем и чудовищного техдолга проекта, ошибок проектирования. И опять же не мидлу заниматься таким, обычно на такое тратят время специально обученный разумный человечек, который наоборот не делает никаких мидловых задач, а занимается вот как раз узкими местами и методами их преодоления.
Решение около-бизнесовых кейсов - да с чего вообще спрашивать про такое? Опять же на больших проектах и в серьёзных компаниях этим отдельные отделы и люди занимаются, то, что вы как мидл с чем-то таким сталкивались - здорово. А про что ещё у вас спросить, с чем вы сталкивались, хотя не должны были? Может, с клиентами спецификации составляли? Может, финансовое планирование место имело? Может, обучали отдел техподдержки? Ну так этого всего на новом проекте не будет, как правило, если нанимают нового человека - значит, или много или будет много и прямых задач по разработке на пхп
Не было вопросов про системы контроля версий
Что спрашивать? Везде git. Ну merge, как и везде. Какие-то свои процедуры создания и вливания веток. Cherry-pick, кстати - это здорово, но не совсем здраво и опять же указывает на определённые проблемы в ведении веток проекта. Это вроде совсем базовые вещи, которые должен знать любой, кто вообще работал с git. Про контроль версий обычно интернов спрашивают или совcем новичков, чей пет-проект просто сохранялся в IDE по факту как файлы.
Не было упоминания методологий процесса разработки и стратегического планирования развития продукта
вот уж что не мидла ума дело - так эти две вещи. Сейчас бы привлекать разработчиков на стратетическое планирование продукта или там SDLC обсуждать. Что ещё, может, финансы распределим, бизнес-план построим?) Людей там спланируем в ИТ-отдел нанять? И чем вы, как новопришедший разработчик, собрались помочь при разработке стратегии продукта, не зная ни продукта, ни домена, не имея экспертизы хотя бы в несколько лет по этому самому продукту, либо сходных знаний.
Методологии процесса разработки - даже комментировать странно. Не нашего уровня вообще задачи, да и задачи ли - как правило, в компании на проектах эти самые процессы уже устоявшиеся, а на новых проектах применяются накатанные же схемы взаимодействий, чтобы все процессы и потоки были сходные с теми, что уже есть. Это не с полного 0 в RnD отдел на новый язык-технологию наниматься и что-то там пробовать, чтобы нужно было какие-то вырабатывать методологии. Опять же туда нанимают сильно других людей - начинать такие проекты и разрабатывать такие методологии.
Даже unix системы не упомянули.
Опять же - что там упоминать и зачем? Как правило, в вашем резюме уже написано, с какими системами вы работали - windows, linux, соответственно, какие-то навыки есть, которые вам позволяют на текущем месте выполнять задачи - то что толку про это спрашивать? Основы знания терминала или что спросить? Как работает ядро линукса?
Как пропатчить кдеИ вообще - возможно, у них проект под windows и там linux/unix нету необходимости применять.
= = = =
резюмируя, не очень понятно, зачем автор написал статью - это достаточно амбициозно, имея такие опыт и экспертизу, давать такой компании как VK советы и рекомендации, как собеседовать "мидлов". По автору такое ощущение, что он попробовал проект-два, 2 года выполнял какие-то задачи, допустим, что успешно, попутно занимался кучей побочных задач, чем обычно грешат проекты с текучкой кадров, или недоукомплектованные, или с техдолгом, или стартапы ("решения около-бизнесовых кейсов", господи).
То что знал - не спросили. Зато спросили, что не знал. Уже успели получить какое-то своё видение - "какой должен быть мидл", которое в ВК почему-то не разделили. Налицо нехватка опыта работы в крупных компаниях на хорошо спланированных и делегированных проектах - где бекенд занимается бекендом, фронт-енд - фронт-ендом, есть архитекторы, CTO, аналитики, отдел поддержки.п.с: VK, напишите мне в личку, пожалуйста, если всё ещё ищете мидла на язык слона - обещаю сосредоточиться на php и не лезть в стратегическое планирование продукта)))
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
Davidaa_WoW Автор
03.02.2025 13:33Как интересно у Вас выходит. Всё мимо. Видимо по Вашему мнению middle php разработчик должен целыми днями велосипеды самописные для бинарного поиска строить и сложность алгоритмов высчитывать. Зато руками и в пределах своей зоны ответственности!
Возможно у нас разные понятия о грейдах, но по моему мнению, middle - это не просто боевая единица, а сотрудник, способный и менторством заниматься, и оптимизацией и проектированием архитектуры, и другим спектром более сложных задач. Ему в конце концов как-то надо же сеньором становиться.
Исходя из Вашего описания уже сейчас всех мидлов можно выбросить и передать все задачи копилоту. (Про джунов я вообще молчу)
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
Таких претензий никогда не понимал. Я получил какой-то опыт, поделился им и своим видением ситуации, предложил альтернативный сценарий проведения собеседования. Разве не для этого "мы тут все и собрались"? Так что без обид не выйдет.
gian_tiaga
03.02.2025 13:33давать такой компании как VK советы и рекомендации, как собеседовать "мидлов"
А там что не люди работают? Или совершенные программисты? По работе продукта этого не заметно.
И судя по вашему сообщению, миддлу в принципе вообще ничего знать не надо. Ну кроме отличия бинарного и линейного поиска.
DrSol
03.02.2025 13:33А чего по личкам то ходить? У них все публично: https://team.vk.company/vacancy/?tags=2231
gian_tiaga
03.02.2025 13:33Тоже когда собесился, вопросы были оторваные от реальности. Типо чем тсп от юдп отличается.
Т.е человек должен перед собесом заучить никому не нужные определения, чтобы никогда их не использовать.
Ну и по стабильности работы вк - видно, к чему такие србесы их привели.
Про себя - я лид и провел кучу собесов. И чаще всего по опыту, люди которые помнят всю эту мишуру, потом хуже работают.
FanatPHP
03.02.2025 13:33Просто на будущее
SQL инъекции - просто не нужно класть сырой ввод пользователя в SQL запрос.
Ошибка номер раз: во-первых, понятие "пользовательский ввод" не имеет чёткого определения, что не позволяет построить на его основе гарантированную защиту. Во-вторых, даже если ввод "не пользовательский", ошибки синтаксиса от спецсимволов SQL никто не отменял. Поэтому данное правило звучит гораздо проще: "никогда не класть данные прямо в запрос".
Валидацию никто не отменял.
Ошибка номер два: валидация относится к бизнес-логике. А к безопасности - наоборот, никакого отношения не имеет, за исключением очень редких специальных случаев.
Добавить туда prepared statements и инъекции не страшны
Непонятно, что имеется в виду под "добавить", если это и есть тот самый способ, при котором "данные не попадают прямо в запрос". При этом важно помнить, что сам по себе подготовленный запрос - не панацея, и лучше использовать формулировку "заменять актуальные данные в запросе на знаки подстановки".
Ошибка номер три: помимо данных, есть ещё идентификаторы и ключевые слова. Для них замена подстановками не сработает и их надо фильтровать через белые списки.
XSS атаки - снова валидация пользовательского ввода, html escape
Ошибка номер четыре, которую мы уже разбирали на примере инъекций. Во-первых, валидация пользовательского ввода сама по себе, а обеспечение безопасности - само по себе, они почти не пересекаются. Во-вторых, для защиты от XSS экранируют не "пользовательский ввод", а "любой вывод в зависимости от его контекста": если выводим в HTML, то применяем HTML экранирование, если выводим в JS, то применяем JS-экранирование - и так далее. И пользователь тут ну совершенно вообще не при чём.
Насчёт интервью согласен с вашими оценками, но тут надо понимать, куда идёшь. В FAANG, которого косплеит ВК, идеальным кандидатом является конформист-зубрила, прокачанный винтик. И система найма заточена на отсеивание всего остального.
Oceanshiver
03.02.2025 13:33Не было вопросов про системы контроля версий
А про них-то чего спрашивать? Это даже не джуновские вопросы, это даже у стажеров как-то странно спрашивать. Мб еще нужно проверять скиллы "уверенного пользователя ПК"?
k-morozov
03.02.2025 13:33Как можно не знать базовые вещи в виде хеш-таблиц/деревьев и знать про индексы в БД ?
Kerman
О-нотация, это даже не базовые знания. Это базовый язык, на котором я могу объяснить, что этот кусок будет дико тормозить на больших данных, потому что N-квадрат, а надо лог N. Если что, я не в VK работаю.
Вот этим и отличается. У бинарного поиска O=log(N), у линейного O=N
Странно с такими пробелами претендовать на миддла.
Впрочем, не стоит расстраиваться. По собеседованиям полезно ходить, чтобы узнать про свои пробелы и эти пробелы закрывать. К десятому собеседованию уже будет представление, чего ожидают от вас.
AdrianoVisoccini
Про BigO вынужден согласиться, за последние годы это стало мастхев даже на джуна.
А вот про сравнение алгоритмов поиска или сортировки... Не уверен, что помнить наизусть все реализации и их сложность это адекватная метрика. Я бы сказал, в таком случае стоит дать человеку два алгоритма и сказать - оцени сложность и сравни какой лучше. Все же, собственная реализация таких алгоритмов поиска или сортировки это не ежедневная задача для... да не для кого в общем то, неужели вы хоть раз в проект тянули не готовое решение этих вопросов из публичных репозиториев или средств языка, а сами реализовывали?
Про DNS сам не могу понять свое отношение. С одной стороны, у разработика необходимость с этим сталкиваться может годами не возникать, с дургой стороны, как сказал классик "Это база, Это знать надо". У меня понятие DNS навечно запечено горячим клеймом прямо на мозге со времен настройки ADSL интернетов во времена беззаботной юности и младших классов школы
Kyoki
Никто его не просил сравнивать, никто не спрашивал про реализации и сложности, никто не просил реализовывать... но, странно, не знать отличие линейного поиска от бинарного. И да, чтобы знать,что тянуть из публичных репозитариев, неплохо знать ключевое различие этого, а по хорошему еще и краевых случаев.
VladimirFarshatov
Чел мог просто растеряться и забыть, или пользоваться в посведневке иными терминами. Так, году в 2009-м меня не взяли по причине того, что не смог ответить на вопрос: "Что такое EAV?" .. оказывается это банальное продольное хранение данных, которым пользовался с 2001года "вдоль и поперек", а мой коллега так аж 1997года. Ктож знал, что какой-то Тенцер в 2004-м наклепал статью про этот подход и обозвал его Entity-Attribute-Value? :)
Kyoki
Не натягивайте сову. Его не спросили, что такое SFINAE или шаблонный ADL, ECS, KISS, ...
Farongy
Это действительно странно выглядит, что человек настрадался с различными типами индексов в БД, редисом, но не знает как работает хэш таблица.
Retifff
Мне, как системному адиминистратору, вообще непонятно, как может у программистов "годами не возникать необходимость сталкиваться с DNS". А мы потом сталкиваемся с захардкоженными IP-адресами в ПО, вот счастье-то какое.
VladimirFarshatov
Вообще-то это не "программерское", а больше чисто математическое и даже "матановское" понятие О-малое, О-большое.. Отсутствие знаний говорит только лишь про отсутствие базовой математики у претендента, которая нужна далеко не всем и не всегда, даже сеньорам.
sergey-gornostaev
У меня нет "базовой математики", но я читал книги, а в любой книге про алгоритмы и во многих по языкам программирования есть про О-нотацию.
VladimirFarshatov
Так в книгах про алгоритмы, алгоритмическая сложность есть основа. Не удивительно, что там это есть. Но .. Вы точно уверены, что автор в курсе наличия книг по алгоритмам? (Кнута на вас нет!) если он не различает бинарный поиск от пузырька?
Интересно, в какой книге по алгоритмам нет бинарного поиска?
sergey-gornostaev
Видимо, я слишком стар и не поспеваю за новыми веяниями, но меня очень удивляет, что человек может стать программистом, не прочитав ни одной книжки, а тем более добраться до мидла в хайлоад проекте.