Мои выводы из технических собеседований в качестве выпускника учебного курса по программированию

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

Одним из самых неприятных моментов в этом путешествии было то, что я не получал много собеседований, пока пару месяцев назад я наконец не получил свое первое техническое собеседование, которое я проходил в последнем раунде ... и да, меня отвергли, потому что из-за отсутствия у меня знаний о методах жизненного цикла React в React Hooks (я знал, как использовать componentDidMount, и было очень сложно использовать useEffect, поскольку в то время я впервые действительно знал, как это использовать). С тех пор я понял свои сильные и слабые стороны и был полон решимости стать лучшим кандидатом.

Мне потребовался еще месяц или около того, чтобы наконец получить еще два технических собеседования - всего 3 технических собеседования на протяжении всего пути. Я очень хорошо знал, что бомбил их обоих, но я был очень благодарен за эти два интервью. И что интересно, содержание двух интервью сильно различалось. Одним из них было традиционное собеседование на доске, на котором меня попросили решить средний вопрос Leetcode, и, о боже, я был в ужасе перед этим собеседованием, потому что я стремился занять позицию фронт-энда и не тратил много времени изучение структур данных. Другой был анализ данных CSV, то есть превращение очень длинной строки во вложенный организованный объект.

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

Вот мои выводы из этих двух интервью:

  1. Распечатайте входные данные в функции, если возникли проблемы

Всегда console.log вводимые данные, особенно если мне трудно это видеть. Я имею в виду, что иногда в той строке, которую вам предоставляют, что-то спрятано, или, в моем случае, даже интервьюер так много раз намекал, что есть разрыв строки. Этого не было внутри строки, и я не понимал, что \n это то, что она имела в виду под разрывом строки. После того, как я изо всех сил пытался разбить строку с помощью этой «штуки с разрывом строки», мой интервьюер дал мне большой намек на console.log ввод, разделив строку на массив, и да, теперь я вижу, что \n висит внутри массива.

2. Прежде чем беспокоиться об оптимизации, сначала поработайте над рабочим решением.

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

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

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

4. Не просто говорите, напишите код и заставьте его работать

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

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

5. Разбейте проблему по частям.

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

Это похоже на решение вопроса по алгебре типа 3x + 1 = 6x + 5. Как будто ты не сразу начнешь думать, что такое х. Да, это конечная цель. Но мы должны думать так, как получить все x на одной стороне и все числа - на другой. Это похоже на то, как мы решаем структуру данных.

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

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

И последнее, но не менее важное: выпейте кофе / чай, потанцуйте под веселую музыку и веселого кодирования!