Вопрос с собеседования · HR-вопросы

Как разрешить технический спор, когда у каждого своё мнение?

MiddleИстории из опыта
Ещё спрашивают так:
  • Как проверить решение до внедрения?
Коротко

Перевести спор из мнений в проверку: сформулировать, какой факт решит вопрос («выдержит ли PostgreSQL 5 тысяч записей в секунду на нашем железе?»), и получить его маленьким прототипом, замером или экспериментом за часы или дни. Заранее договориться о критерии: если результат такой — выбираем А. Факты на своих данных и нагрузке весомее статей и чужого опыта.

  • Ограничить время проверки — прототип не должен стать продуктом
  • Проверять самое рискованное допущение, а не всё
  • Результат и вывод записать — пригодится через полгода

А ещё Если проверить дорого, а ошибка обратима — выбрать и двигаться, договорившись о пересмотре

Подробно

Пример. Спор: кэшировать ли каталог в Redis. Проверка: замер p95 запроса каталога под нагрузкой — 40 мс без кэша при цели 200 мс. Вывод: кэш не нужен сейчас, вернуться при росте нагрузки втрое.

Инструменты: нагрузочные тесты (k6, wrk), профилировщики, временная ветка с прототипом, A/B на доле трафика.

Что хотят услышать

  • Сформулировать факт, который решит спор.
  • Прототип или замер на своих условиях.
  • Критерий заранее.
  • Ограничение времени и фиксация результата.

Проверьте себя

Один верный вариант. Подумайте, потом откройте ответ.

Показать варианты и ответ
  • ✗Решает тот, у кого больше опыта, без проверки
  • ✓Договориться о критерии и проверить его прототипом или замером на своих данных
  • ✗Найти авторитетную статью или бенчмарк, подтверждающий свою позицию, и показать команде
  • ✗Отложить решение до тех пор, пока все не согласятся

Разбор темы

Связанные вопросы

Партнёр платформы

Разбор собеседования с sotto

После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.

Разбор собеседования