Site icon AppTractor

7 причин, по которым я объясняю ответы во время технического интервью

Недавно я проводил собеседование с Android-разработчиком и спросил кандидата, можем ли мы внедрить параметр аргумента через конструктор Activity. Кандидат ответил «да». Зная, что это неправильный ответ, я мог бы продолжить, но вместо этого я попытался дать несколько намеков. Я предложил собеседнику проверить AndroidManifest.xml. Однако собеседник все же ошибся.

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

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

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

И вот почему.

1. Это не экзамен, а взаимодействие

Много раз мы проводили аналогию между интервью и экзаменами. Интервьюер — это экзаменатор, а интервьюируемый — ученик. Вопрос задается определенным образом, и ответ ожидается в определенном порядке. Следовательно, если ответ неверный… тогда просто «X» в этом чекбоксе и двигаемся дальше.

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

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

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

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

2. Так устроена настоящая жизнь: мы помогаем, где можем

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

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

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

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

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

3. Интервьюируемый должен знать ответ

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

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

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

Следовательно, важно заранее заверить интервьюируемого в следующем:

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

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

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

Учитывая это, по крайней мере, собеседник будут теперь в курсе. Я надеюсь, что это даст ценность кандидату.

4. Это должно представлять ценность для интервьюируемого

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

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

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

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

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

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

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

5. Дело не только в технике, но и в том, как человек взаимодействует

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

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

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

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

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

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

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

6. Может быть, мы что-то упустили?

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

Случай 1: Мы упускаем из виду прошлое

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

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

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

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

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

Случай 2: Интервьюируемый мог думать глубже, чем нужно

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

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

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

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

Случай 3. Возможно, мы не предоставили необходимый контекст

Был знаменитый (или, может быть, печально известный) вопрос для интервью. Интервьюер спросил респондента: «Можете ли вы поменять местами содержимое двух переменных, не используя временную переменную?»

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

Когда интервьюер намекнул,

X = 25, Y = 23

Контекст стал другим. Теперь это было осуществимо. Причина была в том, что он применялся только к числу, а не к какой-либо переменной! Вопрос должен был звучать так: «Можете ли вы поменять местами содержимое двух целочисленных переменных без использования временной переменной?». Он не касался вообще любых переменных.

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

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

7. Возможно, наш ответ уже недействителен

Надеюсь, такое бывает редко, но бывает.

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

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

В Android-разработке приложение иногда могло быть уничтожено системой.

Следовательно, вопрос интервью заключается в том, в чем разница между использованием saveInstanceState и ViewModel при восстановлении состояния приложения Android?

Мы ожидали ответа в соответствии с двумя пунктами выше. Однако собеседник не согласился с ним. После некоторого обсуждения мы нашли следующее:

Хотя приведенный выше ответ действителен (до 2019 г.), он устарел. В 2019 году команда Google усовершенствовала ViewModel, добавив в него saveStateHandler, который также выполняет восстановление состояния, как это делает saveInstanceState. (подробнее см. в этой статье).

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

Не существует единственно правильного способа проведения технических интервью…

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

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

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

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

Источник

Exit mobile version