Не существует рецепта того, как вы должны отвечать на вопросы интервью по программированию в области науки о данных. Нет единого подхода, который всегда будет работать. Однако есть некоторые руководящие принципы, которые в большинстве случаев помогут вам лучше ответить на вопросы по программированию.

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

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

Контрольный список из четырех частей

 
Четыре части этого контрольного списка:

1. Анализ вопросов
2. Подход к решению
3. Написание кода
4. Проверка вашего кода

Теперь, когда у вас есть схема контрольного списка, мы рассмотрим каждый раздел и объясним содержащиеся в нем пункты контрольного списка.

1. Анализ вопросов

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

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

Моменты, которые помогут вам попрактиковаться в обдумывании проблемы:

1. Поймите вопрос
2. Анализируйте таблицы и данные, с которыми вы работаете
3. Подумайте о результате кода

я. Поймите вопрос

Чтобы убедиться, что вы поняли вопрос, вам нужно очень внимательно прочитать вопрос. Читайте медленно. И прочитайте 2-3 раза, чтобы ничего не пропустить. Это относится ко всем вопросы на собеседовании по науке о данных, независимо от того, насколько они легки или трудны. Дело в том, что вы не будете знать, сложный это вопрос или легкий. Некоторые вопросы могут показаться обманчиво простыми, но в них есть уловка, которая как раз и предназначена для того, чтобы отсеять тех кандидатов, которые недостаточно тщательны и склонны к поверхностности.

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

II. Анализируйте таблицы и данные, с которыми вы работаете

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

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

Помимо типа данных, также важно понимать, как данные организованы, упорядочены и гранулированы. Это означает, что в таблице есть повторяющиеся значения? Представлены ли данные, скажем, на уровне клиента, на уровне транзакции и т. д.?

III. Подумайте о результате кода

Прежде чем приступить к программированию, вы должны знать, как должен выглядеть результат. Это, конечно, также зависит от вопроса, на который вы хотите ответить.

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

 
Анализ вопроса – пример

Чтобы показать вам, как следует применять этот первый раздел контрольного списка, мы воспользуемся вопросом кодирования Dropbox. Вопрос звучит так:

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

Ссылка на вопрос: https://platform.stratascratch.com/coding/10308-salaries-differences

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

Теперь, когда вы поняли вопрос, вы можете проанализировать таблицы и данные в них. Вы будете работать с таблицами db_employee и db_dept. Таблица db_employee содержит данные о сотрудниках компании. Он имеет пять столбцов:

Видите ли, столбцы имен имеют тип данных varchar, а зарплата — целое число. Может быть важно знать, что в значениях заработной платы нет десятичных знаков. Если вы воспользуетесь доступной здесь опцией предварительного просмотра, вы увидите, что эти данные уникальны: каждому сотруднику назначено только одно значение заработной платы. Кроме того, важно знать; это также могут быть исторические данные, где у вас будут все предыдущие зарплаты за эти годы для каждого сотрудника. Есть столбец Department_id, который является внешним ключом, связывающим эту таблицу с таблицей db_dept:

Всего два столбца в этой таблице. Это только список отделов, без дубликатов, шесть отделов показаны в таблице.

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

Не было указаний, как назвать этот выходной столбец. Так что не будет ошибкой, как бы вы его ни назвали или не назовете вовсе. Главное, чтобы вы получили этот результат и ничего больше.

При этом у вас есть основа для написания качественного кода. Теперь самое время поговорить о стратегии: как вы будете писать код?
 

2. Подход к решению

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

Когда вы думаете о том, как вы должны подойти к своему решению (или написать код), учтите следующее:

1. Есть несколько способов написать код?
2. Сформулируйте свои предположения
3. Разбейте решение на этапы
4. Начать кодирование

я. Есть несколько способов написать код?

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

Имейте это в виду. Это важно по нескольким причинам. Во-первых, может быть какой-нибудь простой трюк или функция, которая легко решает то, что вы думаете решить с помощью длинного кода, например, используя оконные функции или CTE вместо написания кода с бесконечными подзапросами.

Всегда выбирайте то, что легче написать, с минимальным количеством строк кода. Когда вы на собеседовании, вы также должны распоряжаться временем, которое есть в вашем распоряжении. Это один из способов.
Конечно, если есть несколько более-менее одинаково сложных решений, подумайте, как будет работать код. При больших объемах данных разные коды могут занимать гораздо больше времени и памяти для выполнения, чем другие.

Короче говоря, вы должны думать об эффективности кода двояко. Один из них — личная эффективность или скорость написания кода. Второй — эффективность кода или скорость, с которой код будет выполнять то, что вы хотите.

II. Сформулируйте свои предположения

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

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

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

Четвертая и последняя причина высказывания ваших предположений заключается в том, что даже если вы получите совершенно неправильный ответ, но правильный в рамках высказанных вами предположений, есть вероятность, что вы все равно получите за это несколько баллов. Мышление в этом случае идет по следующему пути: хорошо, может быть, кандидат совершенно неправильно понял вопрос, но решение на самом деле правильное в контексте того, что он понял.

Это все приводит к убедиться, что вы дали правильный ответ на вопрос интервью.

III. Разбейте свое решение на этапы

Это также полезный момент, который облегчит вам получение ясной идеи решения, а затем написание чистого кода.

Разбить в данном случае означает записать. Да, запишите все ключевые шаги и функции вашего решения. Подумайте, следует ли вам объединять таблицы, сколько таблиц и какое объединение вы будете использовать. Должны ли вы написать подзапрос или CTE? Запишите свой выбор. Подумайте, какие агрегатные функции вам придется использовать, придется ли вам преобразовывать типы данных, должны ли данные упорядочиваться определенным образом, должны ли они фильтроваться и группироваться и т. д.

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

IV. Начать кодирование

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

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

Еще одна причина, которую вы должны иметь в виду: некоторые вопросы даже не предназначены для ответа. Некоторые из них просто (и намеренно!) слишком сложны для решения за то время, которое вам отведено на собеседовании. Полностью их никто не решает. Частичное решение — лучшее, что может получить каждый. Таким образом, вы будете отмечены тем, как далеко вы продвинулись по сравнению с другими неполными решениями.

 
Подход к решению – пример

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

«Найдите общую стоимость заказов каждого клиента. Выведите идентификатор клиента, имя и общую стоимость заказа. Заказывайте записи по имени клиента в алфавитном порядке».

Ссылка на вопрос: https://platform.stratascratch.com/coding/10183-total-cost-of-orders

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

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

Теперь это уже приводит нас к разбивке решения. Нам нужно вывести два уже существующих столбца, поэтому обязательно воспользуемся SELECT. Нам нужно найти общее количество заказов каждого клиента. Нам придется просуммировать его с помощью агрегатной функции SUM(). Хорошо, столы должны быть объединены. Мы сделаем это, используя ключевое слово JOIN. Почему бы не присоединиться к какой-нибудь другой? Поскольку наше предположение гласит, что нам нужны только клиенты, у которых есть хотя бы один заказ. Использование JOIN даст нам именно это: оно объединит две таблицы и найдет только те значения (клиенты), которые есть в обеих таблицах. Что дальше? Я использовал агрегатную функцию, поэтому мне придется использовать GROUP BY. И результат должен быть упорядочен по алфавиту, поэтому я буду использовать ORDER BY и ASC.

Результирующая разбивка решения может выглядеть следующим образом:

• ВЫБОР
• СУММА (общая_стоимость_заказа)
• РЕГИСТРАЦИЯ
• ГРУППА ПО
• ЗАКАЗАТЬ ПО ASC

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

3. Написание кода

 
После оценки вопроса и определения стратегии для вашего кода пришло время приступить к его написанию.

1. Придерживайтесь выбранного диалекта
2. Идите построчно при кодировании
3. Говорите, когда пишете код
4. Сделайте его читаемым
5. Соблюдайте выбранные соглашения

я. Придерживайтесь выбранного диалекта

Это особенно важно, если вы проходите собеседование по кодированию SQL. Как вы уже знаете, существует стандарт ANSI/ISO SQL и множество диалектов SQL. Практически каждая СУБД использует свой собственный диалект SQL. Конечно, вы не можете знать их всех. И компания, в которой вы проводите собеседование, вероятно, использует один из этих диалектов.

Если интервьюеру все равно, какой диалект вы используете, выберите тот, который вам наиболее удобен. Не пытайтесь апеллировать к интервьюеру, выбирая диалект SQL, который он использует, если вы не очень хорошо разбираетесь в программировании на этом диалекте. Лучше выбрать диалект, который вы знаете лучше всего, и решить проблему, чем использовать какой-то другой диалект, в котором вы не уверены. Если вы выберете последнее, скорее всего, вы будете нервничать больше, чем необходимо. Кроме того, незнание конкретного диалекта SQL может привести к тому, что вы испортите решение.

Как только вы выберете диалект SQL, придерживайтесь его. Например, если вы решите писать на PostgreSQL, не путайте его с T-SQL.

II. Идти по строчке

Четкая разбивка решения поможет вам проверить этот момент практически незаметно. Поскольку у вас уже есть функции и разделы вашего кода, вам просто нужно сохранять спокойствие и систематически писать код, следуя схеме решения. Код — это не что иное, как версия ваших мыслей на языке программирования. Если ваши мысли и схема решения ясны, ваш код тоже будет понятен.

Если вы начнете прыгать с одной строки на другую, вы запутаете себя и интервьюера. Что, вероятно, приведет к написанию неправильного кода.

III. Говори как код

Когда вы пишете свой код строка за строкой, вы также должны говорить о том, что вы делаете. Это важно, потому что, говоря вслух о том, что вы делаете, вам легче понять, делаете ли вы что-то не так. В вашей голове все может звучать великолепно. Но когда вы озвучиваете это, не очень хорошие идеи действительно бросаются в глаза! Это дает вам возможность исправлять код по ходу дела. В противном случае вы могли бы закончить свой код, даже не осознавая, что сделали что-то не так.

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

IV. Сделайте его читабельным

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

Главное, что делает ваш код читабельным, упомянуто в одном из пунктов выше: пишите как можно проще. Однако некоторые решения не могут быть простыми. И даже несколько строк кода могут стать кошмаром для чтения, если вы не приложите усилий, чтобы сделать их читабельными.

Один из советов, о котором следует помнить, — использовать пробел, табуляцию и ввод. И много пользуйся! Эти клавиши предназначены для разделения вашего кода на разделы, что упрощает понимание того, что делает код. Думайте об этом как обо всем, что вы говорите или пишете. Пробел, табуляция и ввод сделают ваш код запятыми, предложениями и абзацами.

Если возможно, используйте псевдонимы для таблиц. Но постарайтесь сделать их понятными. Избегайте использования однобуквенных псевдонимов, но и не делайте псевдонимы слишком подробными и описательными. То же самое касается имен переменных.

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

Посмотрите наш пост»Лучшие практики написания SQL-запросов: как структурировать код», в котором основное внимание уделяется тому, как можно улучшить ваши SQL-запросы, в частности, когда речь идет о производительности и удобочитаемости.

v. Соблюдайте выбранные соглашения

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

Если вы хотите написать все новые имена столбцов в нижнем регистре и разделять слова символами подчеркивания, сделайте это и оставьте так. Неплохо выглядит столбец «salport_per_employee». Но старайтесь не называть один столбец «salary_per_employee», другой — «SalaryPerDepartment», третий — «Total Salary» и четвертый — MAX_sALAryPerdeparment. Вы навредите себе, пытаясь прочитать код, особенно последний.

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

Говоря о последовательности, мы покажем вам, как этот раздел контрольного списка работает на практике.

 
Написание кода — пример

Вот вопрос по кодированию от Facebook:

«Facebook отправляет SMS-сообщения, когда пользователи пытаются выполнить 2FA (двухфакторную аутентификацию) на платформе для входа в систему. Для успешного прохождения 2FA они должны подтвердить, что получили текстовое SMS-сообщение. Тексты подтверждения действительны только на дату их отправки. К сожалению, возникла проблема ETL с базой данных, из-за которой запросы на добавление в друзья и неверные записи подтверждения были вставлены в журналы, которые хранятся в таблице «fb_sms_sends». Эти типы сообщений не должны быть в таблице. К счастью, таблица fb_confirmers содержит действительные записи подтверждения, поэтому вы можете использовать эту таблицу для идентификации текстовых SMS-сообщений, которые были подтверждены пользователем.

Подсчитайте процент подтвержденных SMS-сообщений на 4 августа 2020 года».

Ссылка на вопрос: https://platform.stratascratch.com/coding/10291-sms-confirmations-from-users

Если вы напишете такой код, он будет охватывать все, что мы упомянули в этом разделе контрольного списка:

SELECT cust_id, SUM(total_order_cost) AS revenue
FROM orders
WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id
ORDER BY revenue DESC

Давайте представим, что Facebook использует SQL Server, но оставляет за вами выбор, на каком диалекте SQL вы будете писать свой код. Вы не знакомы с T-SQL, поэтому решили писать на PostgreSQL.

Например, EXTRACT() и двойное двоеточие (::) — это функции, типичные для PostgreSQL. Первый извлекает часть даты из типа данных datetime. Его не существует в T-SQL! Поэтому, если вы скажете интервьюеру, что пишете на T-SQL, а затем используете эту функцию, вы совершите ошибку. В T-SQL вы должны использовать функцию DATEPART(). И вы должны знать, что эта функция в PostgreSQL называется DATE_PART(). Одно подчеркивание может означать разницу между вашим кодом, работающим и не работающим.

Точно так же двойное двоеточие (::) в PostgreSQL используется для преобразования типа данных. В T-SQL это не работает; вам придется использовать либо CAST(), либо CONVERT().

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

Во время написания кода вы можете разговаривать с интервьюером следующим образом: я выбираю столбец cust_id с помощью функции SUM() для расчета дохода от заказов за столом. Затем я использую предложение WHERE для фильтрации данных по месяцу и году из столбца order_date. После этого я группирую данные на уровне клиентов и упорядочиваю результат по убыванию.

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

ВЫБЕРИТЕ cust_id,SUM(total_order_cost) КАК ДОХОД ОТ ЗАКАЗОВ, ГДЕ ИЗВЛЕЧЬ('МЕСЯЦ' ИЗ order_date:: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date:: TIMESTAMP) = 2019 GROUP BY cust_id order BY Revenue DESC

Удачи в чтении!

4. Просмотр вашего кода

 
После того, как вы написали код, пришло время просмотреть его, прежде чем он станет вашим окончательным ответом. Если вы до сих пор следовали всем пунктам контрольного списка, вам будет легко его просмотреть.

Проверка вашего кода — это, в некотором роде, проверка его по некоторым пунктам в вашем контрольном списке:

1. Проверьте, сколько времени у вас осталось
2. Проверьте его на требуемый результат
3. Проверьте это против заявленных предположений
4. Проверьте его читабельность
5. Проведите интервьюера через решение
6. Оптимизируйте свой код

я. Проверьте, сколько времени у вас осталось

Все остальные пункты этой части чек-листа зависят от этого. Если у вас не осталось времени, то вы ничего не можете сделать. Вы сделали то, что сделали, и ваш код — это ответ, который вы получили, нравится вам это или нет.

Тайм-менеджмент важен, поэтому вы должны намеренно оставлять некоторое время для проверки кода. В идеале у вас будет время для выполнения трех следующих проверок.

II. Проверьте код на соответствие требуемому выводу

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

Если у вас есть время, исправьте ошибки, которые вы сделали. Если нет времени, оставьте код как есть, но напишите, что вы сделали не так.

III. Проверьте код на соответствие заявленным предположениям

Вы написали свой код на основе некоторых предположений. Вернитесь к списку предположений и проверьте, следовали ли вы им.

Было бы идеально, если бы вы это сделали. Но при написании более сложного кода вы, возможно, отбросили некоторые предположения или ввели новые. Запишите и это. Если вы не следовали всем предположениям, но считаете, что должны были это сделать, и у вас есть время изменить код, сделайте это. Если нет, оставьте как есть.

IV. Проверить читаемость кода

Здесь вы должны проверить, понимаете ли вы то, что только что написали. Вернитесь к своему коду, проверьте еще раз каждую строку на ее синтаксис и логику. Проходя построчно, оцените, можно ли улучшить читаемость кода. Были ли вы последовательны в соглашениях об именах? Ясны ли ваши псевдонимы для понимания? Есть ли неясность? Логически ли структурирован код и состоит ли он из логических частей?

Опять же, если у вас есть время, улучшите читаемость кода. Если нет времени, попробуйте записать или просто вспомнить, что вы могли бы сделать лучше.

v. Проведите интервьюера через решение

Если вы сделали все вышеперечисленные шаги, этот должен прийти к вам естественным образом. Самое главное, чтобы вы были честны, когда объясняете свой код.

Какие бы ошибки вы ни обнаружили в своем коде при его просмотре, укажите их явно. Не рассчитывайте на то, что интервьюер их не заметит. Не пытайтесь скрыть их. Признайте свои ошибки и покажите, что вы знаете, что сделали неправильно. Все совершают ошибки, но не все могут осознать, что совершили их, и признать их. Это показывает, что вы знаете, что делаете, даже если допустили ошибку. Говоря об ошибках, вот самые распространенные из них, которые люди делают на интервью по науке о данных.

Если вы включили в свой вывод ненужный столбец, скажите об этом и продолжайте объяснять полученный результат. Вы отклонились от своих первоначальных предположений или включили новые? Скажи так и объясни почему. Если вы сделали это по ошибке, скажите, что это было непреднамеренно, но вы видите, что ваше решение должно включать некоторые дополнительные предположения. Укажите, какими они должны быть, чтобы ваш код работал. То же самое и с удобочитаемостью: если вы видите, что можете улучшить свой код, объясните, как это сделать.

Делая все это, вы не только продемонстрируете свои способности кодирования, но и то, насколько быстро вы думаете, насколько вы ответственны и честны. Все эти характеристики высоко ценятся всеми компаниями.

ви. Оптимизируйте свой код

Последний вопрос на собеседовании по программированию обычно заключается в том, чтобы оптимизировать ваш код. Таким образом, интервьюер проверит ваши знания теории SQL. Например, если вы знаете, что СОЕДИНЕНИЯ могут занимать много времени в вычислительном отношении? Вас попросят выяснить, есть ли способ исключить JOIN или подзапрос. Например, вы обычно можете удалить подзапрос в предложении WHERE с какой-либо функцией, такой как функция ранжирования, если пытаетесь найти максимальное значение.

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

Заключение

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

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

Это то, что вы должны делать. В нашем посте есть и другие советы по подготовке: 5 советов по подготовке к интервью по науке о данных.

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

 
 
Нейт Росиди специалист по данным и продуктовой стратегии. Он также является адъюнкт-профессором, преподающим аналитику, и является основателем СтратаСкретч, платформа, помогающая специалистам по обработке данных подготовиться к интервью с реальными вопросами интервью от ведущих компаний. Свяжись с ним в Твиттер: StrataScratch or LinkedIn.

Оригинал, Перемещено с разрешения.

Источник: https://www.kdnuggets.com/2022/01/answer-data-science-coding-interview-questions.html.