Комментарии 118
Собеседование для фронтенд-разработчика на JavaScript
Как-то вы под конец скатились совсем не во фронтенд.
Как выглядит серверное API
Как бы вы спроектировали сетевую подсистему и серверную часть
Расскажите о том, как спроектирована база данных, серверная часть приложения и API
каждый раз, когда читаю такие типичные вопросы для собеседований, думаю, что не так в том софте, что я писал последние лет 15. Не спорю, аналогов ПО уровня ядра линукса я не делал, но и калькуляторами назвать те клиент-серверные системы с тысячами онлайн клиентов у меня язык не повернется. Но при этом 99,99% кода — это ведь банальные вызовы методов фреймворка (я пишу на C#) и вычисления вида c=a+b. Максимум необычности за последние годы — это приход linq выражений ну и традиционная возня с мультипоточностью.
А все эти "реализуйте 100500 способ сортировки пузырьком" вместо родного метода Sort() — имхо совсем мало говорят о ценности человека в командной работе, его энтузиазме и желании у вас работать. Любой может на досуге подтянуть себя в теоретической базе, если будет чувствовать себя лохом среди сильных коллег, было бы желание.
Не то, чтобы я против того, чтобы программист знал на 5+ теорию, но в современном мире, где ПО устаревает быстрее, чем успевает написаться ТЗ под него — важны немного другие качества. А для гуру место разве что в проектах потипу маткада или там драйверов видеокарт, где на счету каждая ассемблерная инструкция
Немного комментариев по вопросам:
— Не понравились вопросы вида «Реализуйте sort или indexOf». Реализация велосипедов для встроенных в язык методов не является типовой задачей разработчика, и поэтому многие даже опытные разработчики могут показать себя не с лучшей стороны. Если вы хотите проверить понимание работы таких методов, то лучше перенесите их в теорию и вместо «напишите» попросите «рассказать», как бы кандидат реализовал такой метод.
— Понравились вопросы про отладку — такие вопросы позволяют найти хороших кандидатов. Но обращайте внимание не на результат, а на ход мыслей кандидата. Иногда даже если кандидат не справился с задачей из-за небольшого пробела в знаниях (например не знает формулу или какую-то особенность языка), то ход мыслей может выъявить хорошего разработчика.
p.s.
Собственно он им и является.
Я не верю в добрых самаритян, которые бесплатно тратят свое время на обучение новичков.
Qui prodest?
Там есть страница доната, но мне интересно где вы нашли плату за сертификаты?
В крайнем случае можно просто прочитать на wiki — что такое freecodecamp.
Сейчас посмотрел в интернете и не нашел бумажного варианта этого документа. Видимо в этом пункте я ошибся. Признаю.
Не надо к ним ходить, и тем более, что-то покупать у них.
Пользуйтесь MDN, caniuse и другими свободными источниками.
https://habrahabr.ru/post/188010/
не, это не очень ссылка. Пусть лучше такая: https://ru.wikipedia.org/wiki/%C2%ABO%C2%BB_%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%BE%D0%B5_%D0%B8_%C2%ABo%C2%BB_%D0%BC%D0%B0%D0%BB%D0%BE%D0%B5
тьфу, да что такое со мной:( простите. Вот:
https://habrahabr.ru/post/196560/
https://ru.wikipedia.org/wiki/%D0%92%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B0
Ну и в общем, гуглится по "о большое сложность алгоритма".
PS Я прекрасно знаю про O-большое, про курс математического анализа, где оно вводится, про нужность его для разработки форм отчётности.
Я подумал, что речь идёт об O-Data, O-Auth и т.д. Короче завалил бы я это собеседование…
И да. Никогда в жизни не приходилось сталкиваться ни с такими вопросами, ни с такими заданиями в реальной зазработке. Так что фирмы с такими собеседованиями сами себе злобные буратины.
Как же вопросы по паттернам, по SOLID, по тестированию, по командной работе, по каким-нибудь заковыристым особенностям JS, которых в нем воз и маленькая тележка?
Без них, и с таким длинным списком (бесполезных, на мой взгляд) вопросов по алгоритмам, есть риск случайно нанять олимпиадника, который продакшн никогда в глаза не видел, и прозевать кучу компетентных специалистов.
Все эти паттерны и заковыристые особенности JS точно также бесполезны, имхо. Типичная задача в совеременной ИТ конторе выглядит как то так: вот есть такая непонятная фигня и вот три каких то тулзы и пара фреймворков написанных на странных диалектах языков похожих на си и джаву, и из них за два месяца надо собрать вот такой прототип который не стыдно будет показать, а там уже допилим если взлетит. Времени на паттерны обычно нет.
1) Почему значение вновь созданной переменной равно undefined? (теория)
2) Как написать делегирование обработки клика на кнопке для структуры элементов типа ul > li > button > «some content» (практика)
3) React это библиотека или фреймворк? Почему так, а не иначе? (критическое мышление)
Потом слушаю ответы и наблюдаю ход мысли. В целом этого достаточно, чтобы составить первичное мнение о человеке. Все остальное покажет практика.
PS:
Писать код на бумажке не заставляю)
На третий вопрос я бы не смог ничего внятного ответить. Хз что это. Экосистема наверно. И да, я один из тех кто пишет этот реакт :)
Т. е. библиотека дёргающая callback'и уже фреймворк? А фреймворк, который настраивается и запускается из условного main — уже библиотека? Смело.
Да и первоначальный вопрос был больше о React, который очевидно не библиотека, в классическом смысле этого слова, и явно не просто view. Однако многие люди склонны верить тому что написано, а не тому что видят.
О тонкостях в настраивании фреймворков внутри main судить не берусь, ибо не совсем понял как это должно работать)
У почти любого фреймворка есть какие точки входа/процедуры инициализации. В том же react вы рано или поздно должны сделать ReactDOM.render
, чтобы подцепить компонент к реальному dom'у. Примерно такая же ситуация часто и в других языках, где рано или поздно надо вызвать точку входа в конкретный фреймворк.
Иногда этот кусок уже написан и про него не нужно париться: java war в сервлет-контейнере/аппсервере, spring boot приложение (с некоторой натяжкой, один static метод с одним аргументом там таки дёрнуть надо), rails и многие другие.
Я обычно провожу водораздел библиотека/фреймворк по тому, насколько сильно конкретная вещь заставляет использовать определенную архитектуру, а не по cflow.
Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.
Вообще в IT очень много сложных вещей, которым тяжело дать однозначное определение. Тот же паттерн MVC: одна и та же схема взаимодайствия компонентов у Майкрософт называется MVP, однако Эппл считает тоже самое истинным MVC. Нам остается лишь принимать сторону того, кого считаем авторитетом в исследуемом вопросе. Главное не устраивать крестовых походов)
Тогда моё восприятие плюс-минус совпадает с тем, что утверждает Fowler. В частности, второй абзац вашей цитаты по сути про навязывании архитектурного решения.
componentWillMount, componentDidMount, shouldComponentUpdate, render — React фрэймворк?
И это касается не только React.
А я всегда думал что фреймворк — это набор библиотек
По первому вопросу. Там наверно есть какой то умный ответ, но почти наверняка оно undefined лишь потому что когда то у Брендана Айка не было времени (как обычно) и он что то там нахреначил с пометкой TODO, а оно так и осталось, а потом уже поздно было менять потому что много чего бы поломалось.
А второй вопрос не вызвал сложностей? В интернете в различных туториалах оно показано в упрощенном виде, что в определенных ситуациях вызывает ошибки (возможно встречали сайты, у которых пункты меню иногда не реагируют на нажатие)
Глядя на усилия, что тратятся что бы обойти «нюансы» JavaScript уже можно было бы пару раз сделать нормальный вменяемый язык для разработки. А так это выглядит как попытка на детскую пластиковую машинку приделать двигатель «как у больших дядей».
Мыши продолжают хрустеть кактусом, в надежде что получится текилла :)
У нас есть 13 стандартов, давайте сделаем 1 универсальный — компания B
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
Ну давайте посмотрим эволюцию ECMA-262. Let добавили с более адекватным поведением, class добавили. На мой взгляд — двигаются в сторону «как у всех», а поскольку сделали TypeScript, который еще более «как у всех» и webAccembly шустро распихали по основным движкам, видимо не достаточно быстро JS двигается в сторону «как у всех»
Супруга проходила собеседование в прошлом месяце. Два этапа: на первом просили выполнить тестовое задание с AngularJS, на втором этапе в скайпе просили рассказать о себе и своём опыте работы. Всё, никаких бинарных деревьев, O больших и серверного API.
Четырёхглазые задроты мучают нормальных пацанов, которые просто хотят решать бизнес проблемы.
А четырехглазые задроты в стартапах умеют только бесконечно рефакторить, рассуждать о высоком и проедать деньги инвесторов.
А мне понравился список. Мне часть из этих вопросов задавали, ответил без особых проблем. Правда, брали на тимлида по бэкенду.
Человека с опытом это может даже оскорбить и в итоге фирма сможет набрать разве что кучу студентов без опыта разработки бизнес приложений.
Ну вот прочитал человек в свое время книжку, может и не одну, по каким-нибудь структурам данных и алгоритмам работы с ними. Прошли годы, и за это время ему эти знания пригодились ровно ноль раз, так как в языке и платформе, с которым он работает, все эти структуры уже есть. Более того, его род занятий никак не пересекался с прочтенным. Очевидно, знания эти вылетели за ненадобностью.
И вот сидит он, бедняга, на собеседовании со своим багажом ценных знаний и опыта разработки приложений и пытается вспомнить механизмы разрешения коллизий в хэш-таблицах. И сам на работу не устроился, и настроение испорчено, и компания осталась без ценного сотрудника. Смешно.
Забудет даже то, что не знал. Как студенты регулярно забывают на экзаменах.
Ни разу не встречал человека забывшего базовые вещи.
Базовые для кого?
Пошел я как-то пообщаться пару лет назад. И спрашивают у меня «а скажите нам, а что такое SOLID для архитектуры ?» Я честно сказал не знаю, потому что этот SOLID у меня ни с чем не ассоциировался, только на переферии сознания мелькнуло «что-то знакомое». Пришел я домой и начал читать что такое SOLID? И где-то минут через 10 вспомнил! Читал я расшифровку этого SOLID лет 5..7 назад, но поскольку эти принципы и так использовались по отдельности и под другими названиями и ничего нового не давало, то в голове просто не запомнилось, а мозг решил не запоминать «мусор».
И вот вопрос: ты не знаешь как проектировать/писать софт или не знаешь как расшифровывается SOLID? Да и сейчас мозг просто отказывается это запоминать.
Я не вижу в этой ситуации ни одной выйгравшей стороны.
Сейчас плодится столько разной фигни делающие весьма схожие вещи, но под разными названиями что мозг просто заполнен всяким шлаком. А если учесть, то у тебя есть еще и текущий проект(ы) со своей предметной областью, то это все превращается в какой-то сюрреализм.
А то о чем вы написали имеет место, но не имеет ни малейшего отношения к обсуждаемым примерам задач.
UPD. И да, если человек придет на собеседование и не сможет рассказать про бинарный поиск — у меня возникнут очень большие сомнения в его способности программировать. Именно программировать, а не собирать что-то по туториалу из кусочков кода. Потому что очень сложно научиться программировать и пройти мимо настолько базовых вещей.
Вы этим пользуетесь каждый день, когда используете, например, ассоциативные массивы или индексы в базах данных
Серьезно? :) а почему именно бинарное дерево?
А давайте сразу все эти индексы?
- B-tree indexes
- B-tree cluster indexes
- Hash cluster indexes
- Global and local indexes
- Reverse key indexes
- Bitmap indexes
- Function-based indexes
- Domain indexes
потому что они слишком простые чтобы их забыть и вы их начинаете видеть их везде.Человеку с молотком везде мерещатся гвозди? :)
Сколько раз в жизни Вы реализовали свой индекс для поиска? сколько раз в жизни Вы просчитали цену этого алгоритма и сравнили с другими алгоритмами для всех сценариев? или выбирали из готовых согласно рекомендаций «прозводителя»?
если вы хотя бы один раз в жизни написали руками этот несчастный бинарный поиск.
У меня было пару преподавателей информатики, которые еще с 60-х годов работали на вычислительных машинах (лет 30...35 опыта работы от ламповых шкафов до Intel Pentium). Ни разу не помню, что бы заостряли внимание на бинарных деревьях как на таковых, зато отлично вбили в голову как анализировать алгоритмы и оптимизировать их исходя из поставленных задач и доступных ресурсов. «Этот несчастный бинарный поиск» проходил просто как один многих наглядных примеров. Учили создавать и опимизировать, а не тупо пользовать.
Есть разница между заполнить таблицу умножения и просто уметь умножать :)
Вы требуете «таблицу уможение», а не умения умножать :)
За эту науку им благодарен безмерно, а не за алгоритмы как таковые.
Последний раз я писал свой индекс два месяца назад. Но, соглашусь, это специфика задач.
А дальше вы зачем-то спорите сами с собой. Вот дальше я именно говорю о том, что если вас учили именно создавать и анализировать, а не использовать, то в процессе вы именно простой бинарный поиск и писали. И именно поэтому он есть в задачах, а красно-черных деревьев там нет. И потому что это основа без которой люди даже не задумываются о том, что лежит под рекомендованными абстракциями, почему и как их правильно использовать.
Как работает прототипное наследование и чем оно отличается от классической модели наследования? (По моему мнению, это не особенно полезный вопрос, но многим нравится его задавать.)
Кто-нибудь может привести примеры отличий? Мне в голову приходит только то, что в прототипном наследовании можно добавлять методы динамически
Как работает прототипное наследование и чем оно отличается от классической модели наследования? (По моему мнению, это не особенно полезный вопрос, но многим нравится его задавать.)
Кто-нибудь может привести примеры отличий? Мне в голову приходит только то, что в прототипном наследовании можно добавлять методы динамически
Как по мне, так это похоже на ручную сборку таблицы функций «руками» в момент исполнения, вместо компилятора.
Я может быть сейчас скажу очевидную вещь, но эти задачки просто проверяют способность человека думать и решать проблемы. Большую часть из них вообще можно оторвать от конкретного языка программирования. Ты можешь, например, забыть какие-то свойства красно-чёрных деревьев, но их всегда уточнить в том числе и на собеседовании. Грубо говоря, никто (окей-окей, зануды, почти никто) на собеседовании не хочет проверить помнишь ли ты число пи до n-ного знака, интереснее знаешь ли ты что это и зачем, и сможешь ли при необходимости использовать. Ход твоих мыслей, варианты решения, вопросы которые ты задаёшь — это реальная ценность таких собеседований. Причём, максимальная оторванность от технологий и языков — это плюс. Технологии меняются, и человек с соответствующим уровнем инженерной культуры и мышлением без труда в них разберётся.
Вопрос только в том, кто нужен компании: обезьяна для решения бизнес задач, которая гуглит и копипастит или разработчик. Пока абстракция не потекла или страничка не начала загружаться два часа (потому что кто-то написал 6 вложенных for'ов :)) и рендеринг тормозить, можно говорить, что базовые знания не нужны, но вот когда это случится, знания очень даже пригодятся. Я при этом не хочу сказать, что гуглить это плохо, не думать и не понимать при этом, вот что гораздо хуже.
И ещё раз, это не просто какая-то ненужная в 99% случаев теория. Это фундаментальные знания, которые формируют тебя как профессионала и влияют на твоё мышление.
обезьяна для решения бизнес задач, которая гуглит и копипастит или разработчик.
ну тут явно вопрос в цене.
За одну сумму при таких задачах, я просто встану и уйду с собеседования, за интересную зарплату, буду сидеть и вспоминать всю теорию.
Как сказал человек выше, я за 10 лет забыл больше, чем знают текущие разработчики. Вопрос в цене.
Никто же не скажет: «решишь вот эти базовые задачки, и мы тебе будем платить 10k USD net в месяц». Нормальная компенсация предполагает, что либо у вас есть репутация и вы известный спец, либо вам придётся доказывать, что вы чего-то стоите и вас прогонят через 2-3 собеседования (в лучшем случае), первым из которых будут те самые задачи, которые описали выше. Это разумно, что если у человека нет базовых знаний, то дальше он не пойдёт.
Вы можете себе представить инженера-электронщика забывшего закон Ома? Как такое может случиться?
Только если он его и не знал и проектировал схемы эвристически и копипастом, не понимая законов лежащих в основе этих схем.
Я не говорю, что я их не знаю, я говорю что я не буду их решать. Хотите что бы что то было — давайте тестовое задание. А теория учится за время испытательного срока.
Зато он знает какие провода с какими соединять нельзя.
Я вот, к сожалению, уже не помню некоторых замечательных пределов или известных интегралов. И, не уверен, что смогу в стрессовой ситуации посчитать детерминант матрицы. Но знаю, что за полчаса разберусь и все вспомню, если будет доступ к источнику знаний, так как вспоминать гораздо проще чем учить. Вопрос к топику только один — можно ли пользоваться интернетом, как в жизни или все «рожать» из головы?
Причём, максимальная оторванность от технологий и языков — это плюс. Технологии меняются, и человек с соответствующим уровнем инженерной культуры и мышлением без труда в них разберётся.
Всё-таки у каждой области есть своя специфика. Я вот имею высшее образование в области Информационных Технологии, в школе был олимпиадником по математике и программированию, занимал призовые места на областных соревнованиях. В общем теоретически подкован. Уже 6 лет работаю в области веб-разработки и вот хоть убейте не могу представить, как я прихожу в гейм-девелопмент и «без труда в нём разбираюсь».
В то же время живо представляю картину: ко мне в команду приходит фронт-енд разработчик, которого на собеседовании гоняли по «оторванным от технологии и языков» вопросам, и когда ему нужно поменять стили при наведении на кнопку он превращается в
обезьяна для решения бизнес задач, которая гуглит и копипастит
Тут многие говорят, что задачи «простые», нуну:
- Алгоритм нахождения простых чисел там же в комментариях автору указывают про Решето Эратосфена
- Фибоначчи (просто несколько ссылок)
- Про sort бесконечность, но для фронтендера будет интересна Реализация сортировки в V8 от Google
- и так далее.
Задавая такие вопросы на собеседовании, максимум, что можно получить, это говнокод, который никак не характеризует фронтендера.
А по поводу сложности алгоритмов и разные подходы: люди, которые участвовали в олимпиадном программирование на пересчет знают как и все алгоритмы сортировки и спектр их применения, так и узконаправленные алгоритмы быстрого поиска нахождения простых чисел (фибоначчи ect). Но это уже другая сфера, с фрондендом никак не связанная.
Так я и говорю, что не понимаю, зачем мне ответ в виде говнокода?! Что он должен мне показать? Если хочется понять, знает-ли человек про рекурсию, ну так спросите его про неё, даже про виды можно поговорить.
Деревья? Не вопрос, есть DOM, чем не дерево и так далее.
Давайте наймем водителя с такой логикой?
Итак, задачи водителя при найме:
- Что такое цикл Карно ?
- расчитайте трения качения колес вашей машины ?
- Нарисуйте фронт детонации от свечи в двигателях машин ?
- Чем отличается двигатель из чугуна, стали, аллюминия, керамики ?
- Что такое двигатель внутреннего сгорания, внешнего сгорания ?
- Соберите паровую машину из зажигалки зиппо, пружинки от шариковой ручки и корпуса металлического карандаша ?
Ага, не знаешь! Как ты тогда собираешься водить такси или трактор?
Вот как-то же без этого мозгоклюйства решили проблему в остальном мире, и права признают выданные в другой стране, и медицину и еще много чего.
А тут какое-то мерянье професионалов «на вес и в ширину»… Как прием в средневековую гильдию :)
фибоначчи, прочтые числа, сортровка, О(n)… ясно, понятно.
Но для фронтэнда тоже полезных вопросов много:
— Как правильно использовать кэширование браузера?, Как его отключить?
— Плюсы и минусы использования CDN?
— Как можно ускорить время загрузки страницы?
— Основные виды атак на сайт и как от них защититься
— С какими проблемами браузерной совместимости сталкивались и как решали?
— Нужно написать интерфейс для существующих WebAPI сервисов за максимально короткий срок, но с возможностью масштабирования в будущем. Какие технологии выберите? Объясните почему…
Как видите на эти вопросы часто нет однозначного ответа, поэтому спрашивающий должнен сам хорошо разбираться в этих вопросах. Но зато пользы от этих вопросов намного больше чем от алгоритмов, которые никогда не пригодятся в реальной разработке.
Также хорошим вопросом может быть кусок кода реального проекта и просьба найти недостатки и посоветовать как оптимизировать, а также найти замечания по оформлению кода.
Считаю, что алгоритмы знать полезно и решать такие задачи нужно уметь, но после прочтения статьи возник вопрос — зачем человеку, который всё это знает, идти в типичную шарагу шлёпать формы? Иными словами, имеет смысл всё это спрашивать, если компания может предложить задачи, которые заинтересуют такого человека, иначе он же отупеет к херам или уйдёт.
назовите хотя бы один случай, когда использование document.write()
может быть необходимо
Не могу, потому что нет такого случая. Все что можно реализовать с помощью document.write — можно реализовать с помощью других средств во всех браузерах моложе 8 лет. Если вы собираетесь поддерживать браузеры старше 8 лет — я лучше пойду.
Вы еще спросите что делает css-свйоство hasLayout.
я лучше пойду
так и было :)
del
Собеседование для фронтенд-разработчика на JavaScript: самые лучшие вопросы