Я провёл более 600 технических интервью — и вот пять проблемных мест, которые я заметил у кандидатов

Автор оригинала: William Ian Douglas
  • Перевод
Недавно я провёл 600-е собеседование на interviewing.io (IIO). Хотелось бы поделиться опытом, рассказать, как я подхожу к интервью, и пролить свет на типичные проблемы у кандидатов. Каждый интервьюер на IIO индивидуален, поэтому ваши результаты могут отличаться. У нас на платформе сформировалось замечательное сообщество, где каждый работает над улучшением своих знаний, навыков и результатов интервью.

Пробное интервью на interviewing.io


Мы оцениваем людей по трём четырёхбалльным шкалам. Оценка «один» означает плохой результат, а «четыре» — очень хороший. Я обычно вначале даю кандидату три балла, а затем прибавляю/отнимаю очки по мере интервью.

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

Техническая квалификация


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

Решение проблем


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

Общение


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

Общие проблемные области, которые я вижу в интервью


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

Общая проблемная область 1: слишком ранний переход к коду


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

Думаете, это своеобразная гонка, где победителем признают первого, кто пересечёт финишную черту?

Вовсе нет.

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

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

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

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

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

Я видел, как отсутствие планирования привело к ужасному результату в реальном интервью в 2012 году. Кто-то из отдела кадров привёл ко мне кандидата для интервью и пошёл за водичкой. Мы представились друг другу и перешли к технической задаче. Кандидат не поделился ни деталями, ни дизайном, почти не говорил о высокоуровневом подходе, ничего не записал — и начал строчить код на доске. (Это моё предпоследнее интервью на доске в жизни, ненавижу доску!)

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

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

Каков же наилучший подход?

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

Общая проблемная область 2: общение «полумыслями»


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

«Интересно, можно ли… хотя нет, лучше сделать по-другому».

Вернёмся к скиллу общения.

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

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

«Интересно, можно ли… хм… ну, я подумал о реализации поиска в глубину, но учитывая ограничение вокруг ___, наверное, лучше будет ___, что вы думаете?»

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

Общая проблемная область 3: отсутствие уточняющих вопросов


Для разминки я часто задаю примерно такую задачку:

У вас есть группа целых чисел. Напишите метод, который находит два числа, складывающихся в заданное значение — и сразу выдайте эти числа. Верните два значения ‘null’, если ничего не найдено.

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

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

Большинство кандидатов сразу предполагают, что «группа» чисел находится в массиве. Вы можете успешно решить эту проблему, используя массив для хранения чисел. Скорее всего, это будет алгоритм квадратичной сложности O(n²), потому что для каждого значения вы будете перебирать остальные значения. Но существует более эффективный способ решить эту проблему за линейное время O(n), выбрав другую структуру данных.

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

Общая проблемная область 4: предположение, что интервьюер устанавливает все правила


Что-что?

Да, вы меня правильно поняли.

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

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

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

Общая проблемная область 5: долго не просить о помощи


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

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

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

Мои любимые ресурсы для саморазвития


По окончании интервью я люблю обсудить его с кандидатом, поговорить о том, как ему улучшить свои результаты. Обычно я трачу от 10 до 20 минут, иногда выходя далеко за пределы своего часового таймслота, чтобы ответить на вопросы и более подробно о чём-то рассказать. Мне очень нравится помогать людям.

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

Общение


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

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

Решение проблем и среднеуровневое проектирование


Другие сайты для практики интервью HackerRank, CodeWars, LeetCode и др. отлично подходят для кодирования, но не дают никакой возможности упражняться в проектировании (дизайне) задач.

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

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

Одна из моих любимых задач — № 19 в архиве: посчитать, сколько месяцев между январем 1901 года и декабрём 1999 года начинаются с воскресенья. Вам известно количество дней в каждом календарном месяце, и то, что 1 января 1900 года — это понедельник, и способ вычисления високосных лет. Остальное зависит от вас.

Чем больше вы решаете разных задач, тем лучше станете находить закономерности.

Практика, практика, практика


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

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

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

Теперь сотрите работу и сделайте её в третий раз. Потом в четвёртый. Именно на этом этапе в мозге начинаются выстраиваться паттерны со стратегией, необходимой для решения этой конкретной проблемы. Эта «мышечная память» поможет, когда вы увидите другие технические проблемы и сможете заметить сходство: «О, а ведь это похоже на задачу о рюкзаке», а поскольку вы решили её несколько раз, то гораздо быстрее составите высокоуровневый дизайн и проработаете детали реализации.

Одну из моих любимых технических задач можно решить различными алгоритмами (DFS, BFS, DP и т. д.). Если вы считаете, что можете решить задачу подобным образом, решите её три или четыре раза с помощью каждого из этих алгоритмов. Вы действительно хорошо научитесь находить сходства и получите отличную коллекцию стратегий для решения других технических проблем.

Бесстыдная самореклама


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

Я также веду ежедневную почтовую рассылку о вопросах на интервью. Но не с точки зрения того, как идеально на них отвечать (таких ресурсов много), а с точки зрения интервьюера — я рассматриваю, что конкретно мы спрашиваем, что надеемся услышать в ответ, а что не хотим услышать и так далее. Например, когда вас просят «Расскажите о себе», никому не интересна история вашей жизни. На самом вопрос звучит так: «Расскажите вкратце о том, что делает вас ценным сотрудником».

Комментарии 47

    +55
    А потом выходишь на работу, а там сплошь интеграции с SOAP и CRUD на ресте с нелогичной бизнес-логикой. И ты такой «это не очень напоминает задачу о рюкзаке». наболело
      –2
      А если нет? SOAP и CRUD пишутся уже крайне быстро и в 2020 не являются основным объемом кода. Основное это встраивание свистелок и перделок (встроить API камеры в JS) в большой код — тут крайне важно уметь мыслить архитектурно, либо решение жестких задач с алгоритмами (финансовыми, картографическими, оптимизационными, фотографическими и т.д.), где требуется дебаг, трассировка и понимание, что происходит.

      Естественно все задачи о рюкзаках решили еще 20 лет назад.
        +5
        Естественно все задачи о рюкзаках решили еще 20 лет назад.

        Так P=NP или нет? А то я походу всё пропустил.

          +2
          Только если N=1 =)
            +3

            < sarcasm> Вы забыли случай P = 0 </ sarcasm>

          +1
          Не знаю, как сейчас, но раньше меня при виде wsdl схемы бросало в жар.
            0
            WSDL (да и все остальное на основе XML) это как сварка — можно пользоваться, но нельзя смотреть…
            0

            Ну как, быстро. Годик вшестером плюс тестирование.

            +2

            И вот пишешь ты реализации CRUD на rest'е, пишешь, а потом у тебя, внезапно, проблема с пачкой конкуретных взаимозависимых вопросов. И вместо того, чтобы сделать из них DAG, продолжаешь фигачить тупые запросы и обкостыливаешь возникающие в рантайме циклические зависимости if'ами.


            Так тоже бывает. Вовремя заметить место, где заканчивается кодинг и начинается программирование — это тоже искусство. IRL никто не даёт вам разжёванную задачку в которой очевидно нужен нетривиальный алгоритм. Наоборот, все стараются это место скрыть, потому что там сложно и думать не хочется. А надо. А можно не думать, а писать if'ы...

              0
              И прежде чем вам окажут великую честь добавить еще N-форм в проект и написать еще пару адаптеров для очередного провайдера чего-то там, отдающего данные через SOAP, придется пройти несколько этапов собеседования с HR, технарями, CTO, CEO, собачкой CEO, уборщицей и полиграфом на заключительном этапе.
                0
                Это да — особенно в эпоху всеобщей изоляции и Zoom-а. Раньше в небольшую контору можно было за пол-дня устроиться — интервью с TL и синьором, интервью с VP/CTO, интервью с HR. Сейчас же это проект на три недели.
                0
                А потом выходишь на работу, а там сплошь интеграции с SOAP и CRUD на ресте с нелогичной бизнес-логикой. И ты такой «это не очень напоминает задачу о рюкзаке». наболело


                Собеседование при приёме на работу — обоюдный процесс.
                Вы тоже можете задать вопросы: «а чем именно я буду заниматься».
                +16
                У каждого свои тараканы. У интервьювера тоже. У этого интервьювера тоже. То, что так важно для него, почти не имеет значения для меня.
                  +1
                  У каждого свои тараканы. У интервьювера тоже. У этого интервьювера тоже. То, что так важно для него, почти не имеет значения для меня.


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

                  То есть он не проверяет глупости типа «реализуете ли вы без интернета сортировку 101 методом».
                  +10
                  посчитать, сколько месяцев между январем 1901 года и декабрём 1999 года начинаются с воскресенья
                  Хм, взять библиотеку дат и посчитать разницу ей? Другие способы применять опасно, т.к. можно не учесть какие-то дополнительные особенности, а пользователи потом будут гадат, почему так криво программа работает.
                    +8

                    Ага, особенно актуально для нас из-за смены календаря в начале века.

                      0
                      а-ха-ха, я бы посмотрел как автор-американец решил бы эту задачку на русском интервью. Послушал бы его уточняющие вопросы )))
                        +2
                        У них Аляска есть, к слову, которая в момент передачи России сменила календарь.
                        –2
                        а как смена календаря повлияла на количество месяцев? просто месяц стал короче, т.е. дней меньше, а количество месяцев не изменилось.

                        Можно вспомнить еще советский революционный календарь, там вообще забавно с датами было)
                          0
                          А причём тут количество месяцев?
                            –1
                            посчитать, сколько месяцев между январем..

                            «сколько месяцев» это не про количество месяцев?
                              0
                              Там задача не посчитать количество месяц, а посчитать количество месяцев, начинающихся с воскресенья. Вы задачу полностью прочитали?
                                0
                                действительно, с воскресеньем протупил(
                        0
                        Так речь не идет о продакшине, это просто задачка для того, чтобы мозги поразминать. Я тоже очень люблю Эйлер — если какой-то новый язык изучаю или просто размять мозг хочется, там прикольные задачки есть.
                        +15

                        Вы не провели 600 технических интервью, у interviewing.io просто стартовала маркетинговая кампания. На Hacker News вас быстро раскусили.

                          0

                          поделитесь пожалуйста ссылкой? нашла статью, но в комментариях такого не вижу

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

                          • Резюме 1: кандидаты не имеют опыта прохождения собеседований :)
                          • Резюме 2: автор из раза в раз видит природу поведения кандидатов на собеседованиях, но так и не смог выстроить процесс общения так, чтобы человек смог раскрыть свои архитектурные и менеджерские навыки, видимо автор задает вопрос «решить задачу» и потирая руки ловит кандидата на том, что он как на всех прочих собесах решает ее первым быстрым способом, чтобы потом подтюнить, но решить… Итого: автор за 600 встреч не способен учиться
                            +2
                            И выходишь ты на работу, а там непонятные неподдерживемые спагеттины с багами в каждой строчке
                              +1
                              К нам иногда приходят новые разработчики в крупный энтерпрайз проект, который делается на государственные деньги. У этих бедолаг изначально глаза горят, а потом через несколько дней они понимают куда попали и огонь в глазах потухает и в них видно только отчаяние. Слава богу я больше не работаю в этом проекте, это был ужасный опыт.
                              +2
                              Кандидаты замалчивают решение, вы замалчиваете ожидания поведения. Перед интервью давайте кандидатам почитать эту статью. Тогда они сразу скорректируют поведение. Знания одни, поведение разное. В итоге будет гласное решение, ожидаемое поведение.
                                +1
                                Вот именно. Или касательно вот такой фразы: "… когда вас просят «Расскажите о себе», никому не интересна история вашей жизни. На самом вопрос звучит так: «Расскажите вкратце о том, что делает вас ценным сотрудником»." — Хмм, а почему бы не спросить явно: «Расскажите вкратце о том, что делает вас ценным сотрудником»
                                0
                                Всё вышеописанное мало имеет отношения к работе. Выявлением подобных минусов работодатель просто пытается срезать вам зарплату.
                                  0
                                  Всё вышеописанное мало имеет отношения к работе. Выявлением подобных минусов работодатель просто пытается срезать вам зарплату.


                                  Сумма вашей зарплаты зависит не от задаваемых вопросов.
                                  А от того примите ли вы предложение с суммой Х или пойдете искать лучшие варианты.

                                    0

                                    От вопросов зависит какой X я назову в итоге, если вообще назову.

                                      0
                                      От вопросов зависит какой X я назову в итоге, если вообще назову.


                                      То есть зависит от вас.
                                        0

                                        Зависит и от компании — какие вопросы они будут задавать и какие ответы давать на мои вопросы — и от меня. Циклические зависимости )

                                          0
                                          Зависит и от компании — какие вопросы они будут задавать и какие ответы давать на мои вопросы — и от меня. Циклические зависимости )


                                          Заставить то вас принять предложение не в ваших интересах они не могут.

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

                                            Они могут ввести меня в заблуждение как своими вопросами, так и своими ответами. И даже если на всё ответят абсолютно истинно (что крайне редко бывает — плюсы приукрашаются, минусы уменьшаются или замалчиваются), я могу впасть в когнитивное заблуждение сделав вывод, например, что раз меня по архитектуре гоняли, то и заниматься мне предстоит архитектурой, и не уточнив это. А человек просто не знал, что ещё спрашивать. Привели архитектора на собес, который "моих" языков не знает. Вот и нашли общий.

                                      0
                                      Сумма вашей зарплаты зависит не от задаваемых вопросов.

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

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

                                    +1
                                    Когда я проходил последнее интервью, волнение не дало мне задуматься о задаче и вместо неловкого молчания и оцепенения я просто начал писать.
                                    Мне понадобилось написать первое пришедшее на ум решение, чтобы понять проблему. Тогда задача и сложность стала ясна и через 2 минуты реализован оптимальный алгоритм. Но интервью уже было провалено, ведь надо знать что от тебя ждут сначала поговорить, да.
                                      +1
                                      Они слышат проблему, обсуждают высокоуровневый дизайн в течение 30 секунд или меньше — и начинают программировать. Как будто стоит задача сделать как можно быстрее, они реально торопятся закончить работу.

                                      будешь сидеть долго рассуждать — 9 из 10 интервьюеров скажут что слишком тормоз, это ошибка не кандидата а общая

                                        +1
                                        Продолжайте спрашивать интервьюера о проблеме.


                                        Угу, и в какой-то момент задавания 100500 уточняющего вопроса в комнату войдет мужик с унитазом и жопой. Не заваливать интервьюера вопросами надо, а быть с ним так сказать, on the same page.
                                          0
                                          Есть еще проблема, когда за счет тебя на собеседовании интервьюер пытается поднять свое ЧСВ.
                                            0

                                            проходит уже на 10-м проведенном интервью

                                            0
                                            Я один полагаю, что проверять самостоятельность мышления и тп на числах фибоначчи и прочих алгоритмах немного странно? по-моему куда важнее понять, понимает ли человек что такое performance и complexity. Не говоря уже о том, что интервьюер, надергавший задачки из какого-нибудь решебника онлайн, сразу расписывается в том, что личный опыт у него отсутствует или не привязан к вопросу, или что он вовсе не компетентен (мы достоверно не знаем) — таким образом, человек проходит собеседнование не с ним, а с неизвестным автором задачи из интернета.

                                            Не нужно делать магические шаги, чтобы окольными способами неявно проверить качества собеседника, надо просто пойти и проверить качества собеседника.
                                              –1
                                              Читаю комментарии — какие-то тролли набежали и еще 10+ оценок имеют.
                                              Лично я действительно тороплюсь выдать ответ на собеседовании. Понимаю это, стараюсь медлить, проверить еще раз и еще. Но все равно что-то упускаю. Как по мне: потому что волнуюсь и спешу. Этот пункт автор четко отметил.

                                              Заглянуть в ход мыслей интервьюера интересно. Может даст преимущество, позволит выделить свою кандидатуру среди многих.
                                              + мне кажется в РФ не так сильно делают упор на навыки общения. Основной упор – «чтобы шарил», а что коллеги часто похожи на угрюмых вурдалаков — скорее привычное дело. Собака бывает кусачей, только от жизни собачей, как мне кажется. Поэтому мы привыкли к отсутствию улыбок на лицах прохожих и толерантности к отличающемуся мнению. Надо срочно прибежать и высказать своё Я и раскритиковать оппонента, не проявляя большого уважения.
                                              По крайне мере по релокации в РФ мне это сильно бросается в глаза.

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

                                              Самое читаемое