«Все, что может пойти не так, пойдет не так» - закон Мерфи
Я начал работать разработчиком программного обеспечения шесть лет назад. Я работал над различными технологиями для разработки мобильных приложений и серверных сервисов. Я хорошо разбираюсь в микросервисах и событийной архитектуре. Моя работа включает в себя решение проблем путем написания кода, с небольшим количеством встреч и согласований каждый день.
Несколько месяцев назад я подал заявку на должность старшего инженера-программиста. Я обновил свое резюме моими последними навыками и проектами и разослал их множеству компаний.
Мне позвонили на интервью из одной из компаний. Это был типичный процесс, включающий раунд кодирования, раунд проектирования системы, раунды культурного соответствия и встречу с главой / вице-президентом по проектированию. Все прошло хорошо, за исключением собеседования по проектированию системы, и это то, чем я хочу с вами поделиться.
Кодирование и культурные интервью
Я кратко коснусь кодирования и культурных раундов, но здесь нет ничего особенного, поэтому не стесняйтесь переходить к следующей части.
Собеседование по кодированию было простым, и я смог решить проблему за отведенное время, но не смог уловить некоторые крайние случаи. Мне удалось указать крайние случаи и возможное решение, но у меня не было достаточно времени для его написания. Это было приемлемо, и я прошел первый раунд.
Затем был культурный раунд, который был довольно веселым и чисто нетехническим. Это включало разговор о способе работы и моем мнении о тестировании, сотрудничестве, проведении встреч и т. Д. Это было больше похоже на беседу.
Был еще один, похожий раунд, в котором более подробно рассказывалась о моей мотивации присоединиться к компании, а также о моем предыдущем опыте. Это тоже было легко, и я справился.
Интервью по системному дизайну
Здесь все стало немного интереснее, так как я провалил этот. Я постараюсь подробнее изучить это интервью, объяснить, что пошло не так, и дать вам несколько советов.
Во время интервью меня попросили разработать систему для службы сокращения URL-адресов. Функциональные требования были следующими:
- Учитывая URL-адрес, служба должна сгенерировать короткий URL-адрес с длинным ключом из семи символов после имени домена. Это называется короткой ссылкой, например
https://shorturl.com/9zck6rc. - Когда пользователи пытаются получить доступ к короткой ссылке, служба должна перенаправить их на исходную ссылку.
А нефункциональные требования были следующие:
- Система должна быть высокодоступной; в противном случае перенаправление URL-адресов перестанет работать.
- Укороченные ссылки не должны быть одинаковыми для двух разных URL-адресов.
- Ожидаемое количество пользователей в день составляло около 1000.
Я начал с указания конечных точек, которые нам понадобятся для создания коротких URL-адресов и получения сохраненных длинных URL-адресов. Это была простая служба с базой данных, в которой хранились id, long_url, short_url и created_at. Состоялось несколько обсуждений.
Обсуждение 1. SQL против NoSQL
3 администратора баз данных вошли в панель NoSQL, через некоторое время они вышли, потому что не смогли найти стол!
Я начал с выбора подходящей базы данных для решения. Я предложил использовать базу данных NoSQL, забыв, что нам не нужно масштабироваться, так как количество ожидаемых пользователей в день было довольно низким. Я представил несколько веских аргументов в пользу NoSQL, но текущее решение можно легко реализовать с использованием базы данных SQL, и я не мог объяснить, почему NoSQL будет абсолютно необходимым выбором. Я все время говорил о том, зачем кому-то использовать NoSQL. Я привел примеры платформ бронирования, использующих NoSQL, и продолжал приводить такие примеры.
Ошибка 1. Я слишком много объяснил. Это правда, что вам нужно объяснить свой ответ интервьюеру, но не теряйте время на чрезмерное объяснение. Я потратил несколько минут, чтобы объяснить то, что можно было объяснить несколькими предложениями. Очень важно следить за собой, а не продолжать и продолжать.
Совет. Попросите интервьюера быстро высказать свое мнение, чтобы сэкономить время. Это должно быть похоже на разговор.
Обсуждение 2. Как вычислить короткий URL
Следующей задачей, наиболее важной частью системы, была разработка логики для вычисления короткого URL-адреса. Не буду утомлять вас подробностями, но для этого требуется вычислить уникальный хэш (SHA256) и применить к нему кодировку Base62. В этом есть свои недостатки, и вы можете столкнуться с дублированием.
Я не мог предложить решение для создания вывода длиной всего семь символов и обработки дублирования при хешировании. Я был очень близок, но не мог придумать хорошего решения.
Ошибка 2. Я сделал предположение. Я думал, что многие детали не будут задаваться на собеседовании по проектированию системы. Но, к моему удивлению, они были. Мало того, с точки зрения интервьюера, это была самая важная часть, о которой я должен был знать. Я мог бы уделить этому больше времени, но я потратил часть своего времени на первое обсуждение.
Совет. Постарайтесь расставить приоритеты результатов, подтвердив их интервьюеру, чтобы привести решение в правильном направлении и сосредоточиться на важных моментах.
Обсуждение 3. Репликация базы данных
С помощью вычислительной логики я начал работать над созданием службы и архитектуры, определяющей, как будет поступать запрос и как мы будем сохранять данные. Я говорил о масштабируемости и упомянул, что мы можем использовать репликацию базы данных.
Следующий вопрос касался репликации базы данных и того, как репликация работает. Я говорил о синхронной и асинхронной репликации, но сам никогда не делал ничего подобного, поэтому в моих ответах не было деталей и они были плоскими.
Ошибка 3. Я не мог сказать «я не знаю»: если вы чего-то не знаете, скажите это. Много раз во время собеседований по проектированию систем мне задавали вопросы, на которые я не знал ответа, и пытался найти ответ, но знал, что не смогу его найти.
В таких случаях можно с уверенностью понять, действительно ли это важно для решения, и соответственно направить собеседование в правильном направлении. В этом случае в репликации базы данных вообще не было необходимости, поскольку ожидаемое количество пользователей было очень низким.
Совет. Не бойтесь сказать «Я не знаю», потому что это даст вам время для важных дел.
Обсуждение 4. Кеширование
«В информатике есть только две сложные вещи: инвалидация кеша и присвоение имен». - Фил Карлтон
Услуга требовала низкой задержки. Это совершенно очевидно, потому что в противном случае пользователю пришлось бы долго ждать, чтобы просто загрузить веб-сайт. Очевидным решением этой проблемы было кеширование наиболее посещаемых URL-адресов.
Следующий вопрос касался определения наиболее посещаемых URL-адресов. Я упоминал, что мы можем кэшировать URL-адреса после первого промаха, а затем удалять их, когда они вообще не используются. Наименее недавно использованный (LRU) может быть разумной политикой для нашей системы.
Еще один вопрос заключался в том, чтобы иметь репликацию кеша на случай, если у нас есть нагрузки из разных регионов. Я предложил использовать репликацию базы данных, а затем с ее помощью сделать недействительным кеш, но я не мог придумать подробностей.
Ошибка 4. Мне не хватало уверенности. Я неоднократно проходил через концепцию распределенного кэширования и использовал ее в своих проектах раньше, но мне не хватало уверенности при ответе на вопрос. Мое решение было правильным, но я чувствовал, что иду в неправильном направлении. Единственное, о чем я не говорил, - это компромисс такого подхода.
Совет. Уверенность - это, безусловно, ключ к успеху. Если вы что-то знаете, просто будьте уверены в этом.
Заключение
Я надеюсь, что вы что-нибудь узнаете из неприятного опыта, который я испытал во время того 90-минутного интервью. Я повеселился во время интервью, так как оно открыло множество пробелов в моих знаниях. Эти знания помогли мне сосредоточиться на правильных вещах во время собеседования, и это помогло мне провести несколько интервью после этого.
Другие интересные статьи, которые людям понравилось читать:
Некоторые ресурсы для вас:
Спасибо за прочтение!
