Недавно я писал о том, чего лучше избежать при прохождении собеседования в Netflix на должность системного инженера. Здесь следует отметить два довольно любопытных факта: во-первых, к моему удивлению, пост оказался довольно востребованным; а, во-вторых, что удивило меня ещё сильнее, после этого несколько людей связывались со мной, чтобы проконсультироваться, на что ещё требуется обратить внимание при прохождении технического интервью. Как правило, формулировка проблема была примерно следующей:

«Я так и не могу успешно пройти техническое собеседование, даже после НЕСКОЛЬКИХ месяцев подготовки.»

Некоторые из тех, кто обратился ко мне за советом, уже успели суммарно решить где-то 200-300 задач с собеседований, поэтому банальные советы из разряда «больше практикуйтесь» им ничем не помогут.

Текущий пост сфокусирован на том, как НЕ следует вести себя во время прохождения собеседования. Если же вы ищите информацию о том, как подготовиться к техническому собеседованию, то вам следует почитать статьи «Coderust 2.0: Подготавливаемся к тех. интервью быстрее с помощью интерактивных визуализаций» и «Подготовка к собеседованию по системному дизайну».

Как со стороны собеседуемого, так и со стороны собеседующего я отметил для себя парочку, по большей части, нетехнических аспектов интервью, грамотное использование которых увеличивает ваши шансы успешно пройти его. Большинство из последующих утверждений основано на моих личных суждениях и ранее совершённых ошибках (да, у меня тоже был такой период в поиске работы под названием «Мы вам перезвоним»).

Основываясь на собственном опыте, я выделил 5 самых распространённых ошибок, которые совершают кандидаты при прохождении интервью.

1. Вы тратите слишком много времени на описание своих прошлых и текущих проектов

Итак, начинается собеседование, и в какой-то момент вам задают вопрос: «Над чем вы работаете в вашей текущей компании?», на что вы тратите следующие 10 минут, описывая ваш проект во всех интимных подробностях.

Как вам кажется, это ваш шанс, чтобы рассказать о том, какую выдающуюся работу вы выполнили за эти 2 года работы над проектом. Вы начинаете описывать настолько мелкие детали, что вас либо перестают понимать, либо вы рассчитываете таким образом протянуть время с целью получить задачу попроще (не выйдет).

В итоге, вместо того, чтобы впечатлить собеседника, вы просто тратите лишние 10 минут, тем самым уменьшая себе время на решение задачи. Интервьюер также и ваш потенциальный коллега, и ему может быть неудобно прерывать вас посередине речи.

Вас спрашивают о текущем проекте для «разогрева». Подразумевается, что вы вкратце опишете суть проекта, чтобы потом собеседник мог плавно перейти к более конкретным вопросам в данной предметной области.

Запомните два момента:

  • Как бы вы ни хитрили, задачу на собеседовании вам всё равно придётся решать, но теперь у вас на 10 минут меньше времени на её решение.
  • Почти не считается. Вас не наймут, если вы не успели решить задание, но вам «осталось совсем чуть-чуть». Такого попросту не бывает.

Куда бы вы ни шли на интервью, всегда будьте готовы сказать пару слов на следующие вопросы:

  1. Над каким проектом вы работаете в данный момент?
  2. Какой аспект вашего текущего проекта вызвал у вас наибольшие затруднения?
  3. Расскажите о самом сложном баге, с которым вам приходилось иметь дело, за последние полгода.

Итог: Рассчитывайте своё время. Вы не приняты по умолчанию, и у вас есть только 45 минут, чтобы доказать обратное. Если для успешного устройства на работу вы обязаны решить задачу у доски, то вы должны оставить себе как можно больше времени для решения этой задачи.

2. Вы неправильно поняли формулировку задачи

Пример из жизни. Несколько лет назад, проходя собеседование, я выступал с технической презентацией. И так получилось, что каждый раз во время выступления мне давали задачу «Поменять порядок элементов в связном списке на обратный.»

Не знаю, почему, но поначалу я вбил себе в голову, что не знаю, как решить поставленную задачу.

Когда уже четвёртый раз подряд собеседующий заикнулся об обратном порядке элементов в связном списке, я сразу же вышел к доске и за пару минут написал решение. Собеседник улыбнулся, и сказал, что он просил напечатать элементы связного списка в обратном порядке, а не менять сам список. Упс.

Я попытался обратить всё в шутку и сказал, что сейчас напечатаю полученный список, и затем ещё раз поменяю порядок на обратный. Я объяснил ему, почему я так бурно отреагировал на эту задачу, и мы оба рассмеялись. Если я не ошибаюсь, в итоге я всё-таки прошёл на следующий этап отбора.

И хотя для большинства из вас подобного рода ошибки не будут фатальными (так как, надеюсь, вы будете слушать внимательнее, чем я), я до сих пор встречаю кандидатов, которые сразу начинают решать, не до конца разобравшись с условиями. Лучше потратьте лишние 10-15 минут, чтобы проанализировать все аспекты задачи, чтобы потом вам не пришлось переписывать ваше решение по новой.

3. Вы сразу же начинаете писать решение задачи, хотя ещё сами не до конца поняли, как оно выглядит

Познавательный факт: почти все задачи на собеседовании, где от вас требуется написать решение на доске, занимают не больше 20 строчек кода.

А теперь попробуйте выйти к доске и написать 20 строчек кода. Это займёт у вас минуты 2-3, не больше. Следовательно, даже если вы и потратите 30 минут на решение задачи, у вас ещё останется пара минут для написания готового решения.

Но при решении задачи на собеседовании вы начинаете сильно волноваться. Вы лихорадочно начинаете писать решение как можно быстрее. Не стоит. Усвойте для себя, что «накалякать» ответ вы всегда успеете.

Лучше основную часть времени тщательно разберите всю задачу, и потом приступайте к её написанию. Попробуйте протестировать ваш алгоритм. Это также даст возможность собеседующему поправить вас в случае, если вы начинаете делать что-то не так.

4. Сначала вы находите наиболее очевидное решение, а затем начинаете оптимизировать алгоритм

Суровая правда. На собеседованиях от вас ожидают вполне конкретных знаний, поэтому при решении задач подразумевается, что вы уже неплохо знакомы с этой темой и знаете оптимизированный алгоритм. Все вышеперечисленные пункты указывали на то, что не в ваших же интересах тратить время. Поэтому как следует подумайте над решением и над тем, как его можно было бы оптимизировать. Если требуется решение с линейной временной сложностью и требуемым объёмом памяти О(1), то любое решение ниже по производительности приведёт к тому, что вас не возьмут.

5. Вы не проверяете своё решение

Как только вы нашли ответ, попробуйте протестировать его на паре примеров. Это поможет вам самому найти недостатки и недочёты в решении, чтобы собеседующий не указывал вам на них сам. Каждый раз, когда вас вынуждены поправлять, ваши шансы уменьшаются. Также это позволит вам найти и рассмотреть особые случаи в решении вашей задачи. К тому же тот факт, что вы не проверяете своё решение, является для нанимателя тревожным звоночком, поэтому проверьте свой алгоритм, даже если вы на 100% уверены, что всё идеально.

Бонус: Спрашивать, как вы прошли интервью

Возможно, это и не будет иметь негативного влияния на решение о том, нанимать вас или нет, но так вы поставите интервьюера в неловкую ситуацию.
Спасибо за внимание и удачи вам на собеседованиях.

Данная статья представляет собой перевод поста Фахима Уль Хоку, одного из учредителей платформы Educative. Для тех, кто заинтересован, предоставляем ссылку на оригинал.

Вы пропустили

AEGIS Algorithms Android Angular Apache Airflow Apache Druid Apache Flink Apache Spark API API Canvas AppSec Architecture Artificial Intelligence Astro Authentication Authorization AutoGPT AWS AWS Aurora AWS Boto3 AWS EC2 AWS Lambda Azure Babylon.js Backend bash Beautiful Soup Bento UI Big Data Binary Tree Browser API Bun Career Cassandra Charts ChatGPT Chrome Extension Clean Code CLI ClickHouse Coding Codux Combine Compose Computer Context Fusion Copilot Cosmo Route CProgramming cron Cryptography CSS CTF Cypress DALL-E Data Analysis Data science Database dbt dbt Cloud deno Design Design Patterns Detekt Development Distributed Systems Django Docker Docker Hub Drizzle DRY DuckDB Express FastAPI Flask Flutter For Beginners Front End Development Game Development GCN GCP Geospatial Git GitHub Actions GitHub Pages Gitlab GMS GoFr Golang Google Google Sheets Google Wire GPT-3 GPT3 Gradio Gradle Grafana Graphic Design GraphQL gRPC Guidance HMS Hotwire HTML Huawei HuggingFace IndexedDB InfoSec Interview iOS Jackknife Java JavaScript Jetpack Compose JSON Kafka Kotlin Kubernetes LangChain Laravel Linux LlaMA LLM localStorage Logging Machine Learning Magento Math Mermaid Micro Frontends Mobile Mobile App Development mondayDB MongoDB Mongoose MySQL Naming NestJS NET NetMock Networks NextJS NLP Node.js Nodejs NoSQL NPM OOP OpenAI OTP Pandas PDF PHP Playwright Plotly Polars PostgreSQL Prefect Productivity Programming Prometheus Puppeteer Pushover Python Pytorch Quarkus Rabbitmq RAG Ramda Raspberry Pi React React Native Reactor Redis REST API Revolut Riverpod RProgramming Ruby Ruby on Rails Rust Scalene SCDB ScyllaDB Selenium Servers Sklearn SLO SnowFlake Snowkase Software Architecture Software Development Solara Solid Spring Boot SQL SQLite Streamlit SudoLang Supabase Swift SwiftUI Tailwind CSS Taipy Terraform Testing Transformers TURN TypeScript Ubuntu UI Design Unix UX UX Design Vim Vite VSCode Vue Web Architecture Web Components Web Development Web Frameworks Web Scraping Web-разработка Webassembly Websocket Whisper Widgets WordPress YAML YouTube Zed Наука о данных Разное Тренды

Как исследовать и визуализировать данные МО для обнаружения объектов на изображениях