Комментарии 44
"На одном из интервью мне предложили накидать системный дизайн, перечислили конкретные ограничения текущих реалий, и попросили встроить решение в их стек технологий. Казалось бы, типичная рабочая ситуация для архитектора....Мне дали не общие вводные и белый лист с карандашом, а конкретный набор технологий и сервисов"
Ограничения по техстеку, по набору сервисов это тоже ограничения и архитектору надо уметь с этим работать. И, соответственно, показывать на собеседовании, что умеешь с этим работать.
Наличие ограничений по тех. стеку при систем дизайне не является проблемой,особенно если работодатель обьясняет почему такие ограничения существуют. Систем дизайн, как и весь процесс собеседования, это про коммуникацию, а не только хард скиллы, поэтому важно, чтобы эта часть собеседования не воспринималась как бесплатная консультация работодателя.
С точки зрения техстека самое простое объяснение "поддерживать зоопарк технологий нам дорого". ИМХО для соискателя в этом случае наиболее благоприятный способ себя показать это решить задачу в условиях заданных ограничений, а потом по итогу разговора касательно этого решения показать как можно элегантно и с меньшими затратами (важно!) сделать то же самое с использованием "такого-то" техстека.
Способность решать задачу в условиях заданных ограничений это как раз не про хард скилы.
Архитектору, окей. А с каких пор системный дизайн в качестве отдельной секции стал обязательным для обычного разраба уровня сеньор (ну или миддл+, предпочитаю быть скромным)? Прохожу сейчас очередную мясорубку собесов и оно сейчас практически на каждом собесе. Как и девопс, как и алгоритмы/кодинг "в прямом эфире"
вот мы прямо сейчас в поиске разраба такого уровня на java, и лично я никому не задаю вопросы на эту тему на собеседовании, да и мои коллеги, в целом, тоже
Если фирма типа Озона, где архитектор - птица редкая (Степаненко считает архитекторов дармоедами), то на сеньора будет систем-дизайн в обязательном порядке.
получил один из лучших примеров такого ответа
Хороший опросник, можно самому спросить если нет обратной связи и я бы ещё добавил вопросы по типу "Что Вы рекомендуете улучшить?" :)
Те, которые участвуют в группировке и результаты агрегации по другим полям
Если уж копнуть глубже, то это не всегда так. Насколько я помню, MySQL тупо позволял выводить все что угодно, правда при этом значение не-агрегатных полей не гарантировалось - оно могло принимать любое значение из группы. Ну и оконные функции я бы упомянул отдельно.
Я проверил запрос на SQL fiddle на нескольких СУБД, включая MySQL, Oracle и MS SQL, и все они выдали ошибку, только на MariaDB и SQLite запрос выполнился без ошибки. Важно отметить, что, в истории из статьи, исходный вопрос не содержал уточнений о конкретной технологии и ответ соответствовал правилам основных реляционных СУБД, а интервьювер вместо уточнения технологии или контекста, просто закончил собеседование. Вообще хорошо наверное, что такие особенности коллег на собеседовании уже проявляются, а не в первые дни как вышел на новую работу :)
Оказывается, все еще интереснее. То что вы говорите, действительно для древнего SQL-92. В SQL-99 введено дополнение - можно выводить в SELECT не только группировочные поля, но и поля, явно связанные с ними. Например, при группировке по user_id можно также вывести user_name, но только если user_name однозначно определяется через user_id:
SELECT user_id, user_name, count(*)
...
GROUP BY user_id
В MySQL совместимость с этим хозяйством регулируется опцией ONLY_FULL_GROUP_BY. Еще это вроде бы поддерживает PostgreSQL.
Так что поговорить тут есть о чем. Что, однако, никак не оправдывает поведения интервьюера.
полную и конструктивную обратную связь
Адекватность
У нас такие разные представления о хорошем и плохом.
Любой критерий в какой-то мере субъективен. Что касается "адекватности", то если бы, например, в ОС я получил бы 5 по знаниям и соответствию тех. стеку и позиции, но 3 за "адекватность", я бы задумался: хочу ли я переходить в компанию, где мой стиль мышления может кажется коллегам не совсем адекватным :)
Спасибо за статью. Предварительно спустился вниз, чтоб проверить, нет ли ссылки на телеграм 🤧
Меня спрашивали про так называемый "физический join". Я честно говоря не понял вопроса, что хотят услышать, спрашиваю "физический join? Не понял что имеется в виду", на что интервьюер только повторил "ну да, физический. Вы что, не знаете?".
Я понял, что хотят что-то услышать, но только не то, что как работают в этот момент оперативная память, физическая память (HDD/SSD) и про работу ЦП - куда идёт нагрузка больше, в какой последовательности читаются таблицы и в какой момент они начинают соединяться. Чисто технически это физический join - то что происходит с железом под капотом.
Сначала я подумал, что начну про это рассказывать и если что меня поправят о чём всё-таки хотели услышать на самом деле (nested loop, hash, merge), но потом решил, что не буду "блестать умом, давить интеллектом", а просто скажу "не знаю".
Интересно... То, что я хотел ответить и то, как был сформулирован вопрос на собеседовании является неким проявлением токсичности? Или мы просто друг друга не поняли и разошлись?
Неправильный ответ и "не знаю" - оцениваются одинаково, поэтому если нет жесткого ограничения по времени, лучше всё таки порассуждать.
Почему? Для меня это странно. Если человек не знает но столкнется с проблемой - он пойдет ее изучать. Если он уверен что знает, но не прав - он может потенциально много вреда нанести. Так что вариант когда знает неправильно - ИМХО хуже.
А причем тут всегда знает? Говоришь: "Я не знаю, но могу порассуждать", и дальше применяешь логику+тебе скорее всего подскажут немного. Ответишь правильно - получаешь свой плюсик по вопросу.
Если компания более менее крупная, очень вероятно что процесс формализован, и тебя опрашивают по определенному списку вопросов, на которые надо дать правильный ответ.
Я бы всё-таки уточнил вопрос. Часто бывает, что собеседник сказал одни слова, а имел в виду другие. Разумное количество уточняющих вопросов позволяет синхронизировать смыслы и повышает КПД коммуникации.
Вопрос при этом был простейший: «Какие поля можно вывести в SQL-запросе, при условии использования групповой функции?». Ответ друга: «Те, которые участвуют в группировке и результаты агрегации по другим полям». Внезапно собеседующий сотрудник сказал, что это не верно и вывести можно все поля. Вот так просто и безапелляционно он закончил интервью, не став ничего проверять в онлайн редакторе SQL-кода.
select *
from actor t1
inner join (select t2.actor_id
from actor t2
group by t2.actor_id) as al2
on al2.actor_id = t1.actor_idЗапрос конечно бессмысленный, но я использовал group by и при этом вывел все поля таблицы actor. Или я неправильно понял условие?
Проверял здесь:
https://sqltest.online/
Запрос конечно бессмысленный, но я использовал group by и при этом вывел все поля таблицы actor.
Просто представьте свою реакцию, если такой код увидете в продакшене :)
Я кстати встречал код, где одновременно были distinct и group by с перечеслением всех полей (без агрегатных функций в select), такие себе чувства после увиденного.
Возможно, собеседующий имел в виду именно такие специфические случаи, но не уточнил это.
Недавно проходил собес в одну известную компанию в РФ, всё шло более менее нормально, за тем исключением что был подключён к интернету через USB модем с мобильным интернетом. А всё потому, что буквально за полчаса до, у меня отключили домашний интернет. И вот на исходе почти часа беседы, у меня перестал работать и мобильный интернет. Очень печально конечно. В итоге пообещали назначить на другой день, но я то понимаю 🤷. Оказалось что котэ потихоньку грыз оптический патчкорд шедший к роутеру, и в самый ответственный момент патчкорд отказался долго жить, отказ мобильного интернета от МТС списал на снежную стихию. И такие истории бывают, к сожалению.
Это простотсудьба вас отвела.
В таких ситуациях следует помнить: "то неизвестно кому повезло". Зато у вас есть кот!
Слишком много совпадений чтоб быть случайностью.
Интернет не работает 24 часа в год
Отпал интернет в час собеса 1/365
Котэ закусывает кабелями 10 раз в год
10/365
Собес в среднем 5 раз в год
Перемножаем всё вместе....
Если кандидат что-то не знает, не понял вопрос или еще что -то, ответ нужно объяснять всегда. Просто правила хорошего тона. Иначе на собесе это выглядит: хахахаха, я лучше тебя знаю. Можно начать с хороших примеров и пытаться навести кандидата на ответ. Посмотреть, а пытается ли он думать и анализировать.
Все вопросы также должны быть в контексте ситуации, а не "что такое <А>?". Сам очень часто попадал в ситуацию, когда что-то спрашивают и ты не понимаешь: чо объяснять то? Как работает это? На насколько низком уровне? Как подробно? Ты переспрашиваешь или просишь переформулировать, подать в контексте. Дальше происходит "ты не знаешь что ли?".
Всегда стараюсь объяснить кандидату и вести за ручку, если плавает, даже если это Л1, которому я задал сложный вопрос.
У меня как-то один директор фирмы допытывался на собесе, как работает керберос (схема гуглитсч за 10 секунд). Я ему сразу ответил: я не помню схему и как оно работает - мне сейчас и в будущем не сильно то и вперлось, чтобы знать ее наизусть. Нет, идиотизм допытывания продолжался 40 минут: да как ты можешь не знать. - Да молча. Также как ты например можешь не знать, про конкретные проблемы патча A за дату B для продукта C. Закончилось тем, что меня оценили по 1 вопросу за собес. И собеседующий отвернувшись от камеры, сказал, что я ничего не знаю. И вообще вышел из митинг рума, когда мит еще не закончился. Директор фирмы. Впрочем, когда директора приходят на первый собес, я последнее время начинаю задавать вопросы: вам совсем делать нечего на работе?
У меня с С-level на собеседованиях прямо противоположный опыт всегда был, но это точно небыли первые собеседования в цепочке. Обычно заключительный этап. Зато мне очень чётко и лаконично обрисовывали положение дел в компании, моё место в этом положении дел и что от меня ждут, если я принимаю оффер. С другой стороны неадекватный C-level - беда компании. Лучше об этом сразу узнать, и не тратить дальше свое время. Всё-таки время наш самый ценный ресурс.
Пришлось подумать :) больше слышал "c-suite", нежели "c-level".
Вам больше повезло, чем мне. Но да, какой дирик в фирме, даст понять многое. Очень часто это может быть удобная прокладка для генерального группы. Например какая-нибудь баба, из которой директор - пшик. И она будет перекладывать свои работы на всех вокруг: на ИТ особенно активно.
«Какие поля можно вывести в SQL-запросе, при условии использования групповой функции?». Ответ друга: «Те, которые участвуют в группировке и результаты агрегации по другим полям». Внезапно собеседующий сотрудник сказал, что это не верно и вывести можно все поля. Вот так просто и безапелляционно он закончил интервью, не став ничего проверять в онлайн редакторе SQL-кода.
Правильный ответ = "можно, но не всегда". Дальше можно поговорить о том, в каких диалектах это можно а в каких нет, какие настройки отвечают за это в конкретных серверах, имеет ли это практический смысл, в чем разница между GROUP BY и DISTINCT ну и так далее.
Была пара собесов, когда конкретно спорил о инструментах. Естественно после таких собесов мне даже обратную связь не давали, ну что поделаешь..если будущий руководитель пользовался только лопатой, а про то что она бывает совковая и штыковая - он знать не хочет.
Это хорошо когда такие варианты работы отваливаются - меньше нервов потратишь. Хуже когда вроде все ок, а на деле - собеседующий не в состоянии сделать как положено и все ресурсы на костылях.
А что подразумевается под терминами "релевантность" и "соответствие" в обратной связи? Это ведь синонимы. Как тогда их трактовать?
Полагаю, у каждого работодателя есть своя собственная трактовка этого. И далеко не факт, что она адекватная.
Соглашусь, что очень похожие определения, конкретно в моем случае "релевантность" это было скорее про актуальный тех. стек, а "соответствие" это общее соответствие скиллов позиции, сам спрашивал, когда уже устроился :)
Сейчас еще раз перепрочитал статью, конечно надо было во фразу
я получил один из лучших примеров такого ответа
добавить "лучший пример из той ОС, которую я получал при собеседовании"
в моем случае "релевантность" это было скорее про актуальный тех. стек, а "соответствие" это общее соответствие скиллов позиции
Было подозрение на именно такое разделение, но показалось, что это слишком просто )). В общем, за исключением двоякого толкования, действительно редкий пример достойной ОС, особенно с "человеческим" комментарием после перечисления параметров.
Спасибо!
и довольный работодатель, не получив ответа, говорит: «Если вы таких основ не знаете, то придется снизить зарплатные ожидания».
Интересно, почему за 15 лет я ни разу не сталкивался с таким ответом? Обычно просто отказ. Пришел к выводу, что предпочитают не по-дешевле, а чтобы не было пробелов в том, что собеседующему кажется что нужно знать.
Самое токсичное где я был - это зеленый банк, собес в QA. Некие господа с зашкаливающим чсв и абсолютной безапелляцинностью.
Можно поделиться? Тут все пишут про токсичность на собесах, а я хочу похвастаться про случай - наоборот, я бы его назвал "самый крутой собес в моей жизни".
Собесился как то я в компанию на буквы Yap... (не яндекс), подошел этап технической части. Вообще, я часто писал уже, что ненавижу лайфкодинг, ну не складывается у меня с ним, руки дрожат, голова не соображает, лучше тестовое дайте.
Так вот в этом случае, впервые для себя я столкнулся с практикой "давай поревьюим код" - и это было прекрасно :). В рабочем коде было допущено 12 минорных/мажорных ошибок, чтобы проверить кандидата. Я нашел 14 ошибок и довольный перешел в следующий этап.
Вообще у вас странное понимание токсичных собеседований. Вам же не пишет hr из альфа-банка с вопросом «каковы ваши аппетиты?» и глава компании не поливает грязью за то, что одним из определяющих факторов назвал «кто первым предложит оффер» (некая noname компания)
Однажды после успешно пройденных трёх этапов собеседования в МТС у меня запросили пройти полиграф. Вот это по-настоящему токсично.
А то, что в статье, это просто отдельная человеческая глупость.
Тысяча первый пост про токсичные собеседования