Когда ваши объяснения так же важны, как и код, который вы пишете

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

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

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

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

Запросить разъяснения

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

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

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

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

apple, orange, Apple, 1apple

У нас здесь четыре строки, и мы хотим их отсортировать. Вы можете пройтись по каждой строке и озвучить, что 1apple должен идти первым, потому что 1 имеет более низкое значение ASCII, чем буквенные символы. Следующим должно быть Apple, так как оно написано в верхнем регистре. Тогда apple, orange будет просто отсортировано по алфавиту. Опять же, в этом примере может показаться бесполезным проходить весь тестовый пример, но это очень важно. Здесь вы сможете подтвердить, что понимаете, что числа предшествуют буквам, а прописные буквы предшествуют строчным, и вы увидите, есть ли какие-либо нюансы проблемы, которые вы пропустили, - и все это до того, как вы напишете одну строку кода.

Объясните свой мыслительный процесс

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

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

Даже если вы не знаете оптимального ответа на проблему, вы можете сформулировать его словами: «Я не уверен, что это оптимально, но у меня была идея двойного цикла for для ввода и сохранения ответов в наборе. « Сразу же вы можете обнаружить, что O(n^2) - это не та среда выполнения, которую вы ищете, и вы можете узнать, не является ли набор той структурой данных, которую вы должны использовать, на основе их ответа. Теперь вы можете вести беседу вперед и назад, обдумывая идеи о более оптимальном решении в надежде найти его, даже если, войдя в него, вы не были уверены, что оно существует.

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

Определите болевые точки

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

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

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

Если вы выполнили задачу и не прошли тестовые примеры, сказав: «Я думаю, что эта часть кода может привести к сбою тестового примера, поэтому я думаю, что прочитаю это на секунду» - это идеальный вариант. Это дает вам четко определенную цель - прочитайте строки X-Y. Он сообщает интервьюеру, что именно вы делаете, чтобы он также мог перейти к этой части кода. И ваш интервьюер может дать вам представление о том, влияет ли этот блок кода на ваши неудачные тестовые примеры.

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

Если вы используете язык, с которым не знаком на 100%, вполне допустимо сказать интервьюеру: «Я знаю, что могу сделать это на Java с помощью Comparable, но не знаю, как это сделать на C ++». Теперь, когда интервьюер знает, что это языковая проблема, объем которой вы понимаете, он может дать вам советы о том, как это сделать на том языке, на котором вы в настоящее время работаете.

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

TL; DR

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