Самый важный скилл, который никогда не проверяют на собеседованиях
Тут Никита Тонский написал пост про задачки на собеседованиях.
Если коротко, то, мол, алгоритмические задачки это такой сособ проверить пишет ли человек код регулярно и что решение этих задачек это рутина и рефлекс.
В целом, мне кажется, что давать алгоритмические задачки нормально. Но частенько приходится решать хрен пойми что. Вот, например, 5 лет назад на собесе в Тинькофф меня просили написать полифил на Object.create. Я, конечно же, сказал, что не напишу да и что это за метод такой не знаю.
Или вот 2 года назад в ВК просили написать проверку на простое число. Я очень долго тупил, пытался вспомнить, что это ваще за простое число, искал какой-то подвох. С горем пополам решил, а потом получил фидбек «плохо знает JS». Потом со знакомым шутили, что я не тот JS учил — нужно было версию для собеседований учить.
Кстати, помимо оторванности от реальных проблем, многие задачки одноразовые. Если ты один раз её решал, то решишь и ещё раз.
Но самое смешное, что меня никто и никогда не спрашивал про дебаг. Почему-то этот вопрос всегда обходят стороной, хотя частенько разработчики тратят больше всего времени именно в поиске проблемы. Причём не нужно ничего выдумывать: достаточно просто показать вкладку Sources в хроме и попросить рассказать за что отвечает и как пользоваться каждой секцией.
Ну а если хотите разобраться как этим всем пользоваться, то для начала можете поглядеть документацию Chrome DevTools. Ну а моё погружение в эту тему началось 6 лет назад: я увидел доклад Антона Шувалова «Отладка кода в браузере» и ушёл с мыслями «а что, так можно было»?
А ещё, девтул можно подключить и к Node.js.
В общем, know your tools и не дебажьте консоль-логами. Ну а решать задачки на собеседовании или нет это уже вам решать 🙂
Тут Никита Тонский написал пост про задачки на собеседованиях.
Если коротко, то, мол, алгоритмические задачки это такой сособ проверить пишет ли человек код регулярно и что решение этих задачек это рутина и рефлекс.
В целом, мне кажется, что давать алгоритмические задачки нормально. Но частенько приходится решать хрен пойми что. Вот, например, 5 лет назад на собесе в Тинькофф меня просили написать полифил на Object.create. Я, конечно же, сказал, что не напишу да и что это за метод такой не знаю.
Или вот 2 года назад в ВК просили написать проверку на простое число. Я очень долго тупил, пытался вспомнить, что это ваще за простое число, искал какой-то подвох. С горем пополам решил, а потом получил фидбек «плохо знает JS». Потом со знакомым шутили, что я не тот JS учил — нужно было версию для собеседований учить.
Кстати, помимо оторванности от реальных проблем, многие задачки одноразовые. Если ты один раз её решал, то решишь и ещё раз.
Но самое смешное, что меня никто и никогда не спрашивал про дебаг. Почему-то этот вопрос всегда обходят стороной, хотя частенько разработчики тратят больше всего времени именно в поиске проблемы. Причём не нужно ничего выдумывать: достаточно просто показать вкладку Sources в хроме и попросить рассказать за что отвечает и как пользоваться каждой секцией.
Ну а если хотите разобраться как этим всем пользоваться, то для начала можете поглядеть документацию Chrome DevTools. Ну а моё погружение в эту тему началось 6 лет назад: я увидел доклад Антона Шувалова «Отладка кода в браузере» и ушёл с мыслями «а что, так можно было»?
А ещё, девтул можно подключить и к Node.js.
В общем, know your tools и не дебажьте консоль-логами. Ну а решать задачки на собеседовании или нет это уже вам решать 🙂