Comments 118
Собеседование для фронтенд-разработчика на JavaScript
Как-то вы под конец скатились совсем не во фронтенд.
Как выглядит серверное API
Как бы вы спроектировали сетевую подсистему и серверную часть
Расскажите о том, как спроектирована база данных, серверная часть приложения и API
UFO just landed and posted this here
Если можно гуглить на собеседовании то запросто, если же нет, то это нереально или нужно быть совсем задротом.
каждый раз, когда читаю такие типичные вопросы для собеседований, думаю, что не так в том софте, что я писал последние лет 15. Не спорю, аналогов ПО уровня ядра линукса я не делал, но и калькуляторами назвать те клиент-серверные системы с тысячами онлайн клиентов у меня язык не повернется. Но при этом 99,99% кода — это ведь банальные вызовы методов фреймворка (я пишу на C#) и вычисления вида c=a+b. Максимум необычности за последние годы — это приход linq выражений ну и традиционная возня с мультипоточностью.
А все эти "реализуйте 100500 способ сортировки пузырьком" вместо родного метода Sort() — имхо совсем мало говорят о ценности человека в командной работе, его энтузиазме и желании у вас работать. Любой может на досуге подтянуть себя в теоретической базе, если будет чувствовать себя лохом среди сильных коллег, было бы желание.
Не то, чтобы я против того, чтобы программист знал на 5+ теорию, но в современном мире, где ПО устаревает быстрее, чем успевает написаться ТЗ под него — важны немного другие качества. А для гуру место разве что в проектах потипу маткада или там драйверов видеокарт, где на счету каждая ассемблерная инструкция
В целом подборка полезная и интересная.
Немного комментариев по вопросам:
— Не понравились вопросы вида «Реализуйте sort или indexOf». Реализация велосипедов для встроенных в язык методов не является типовой задачей разработчика, и поэтому многие даже опытные разработчики могут показать себя не с лучшей стороны. Если вы хотите проверить понимание работы таких методов, то лучше перенесите их в теорию и вместо «напишите» попросите «рассказать», как бы кандидат реализовал такой метод.
— Понравились вопросы про отладку — такие вопросы позволяют найти хороших кандидатов. Но обращайте внимание не на результат, а на ход мыслей кандидата. Иногда даже если кандидат не справился с задачей из-за небольшого пробела в знаниях (например не знает формулу или какую-то особенность языка), то ход мыслей может выъявить хорошего разработчика.
Немного комментариев по вопросам:
— Не понравились вопросы вида «Реализуйте sort или indexOf». Реализация велосипедов для встроенных в язык методов не является типовой задачей разработчика, и поэтому многие даже опытные разработчики могут показать себя не с лучшей стороны. Если вы хотите проверить понимание работы таких методов, то лучше перенесите их в теорию и вместо «напишите» попросите «рассказать», как бы кандидат реализовал такой метод.
— Понравились вопросы про отладку — такие вопросы позволяют найти хороших кандидатов. Но обращайте внимание не на результат, а на ход мыслей кандидата. Иногда даже если кандидат не справился с задачей из-за небольшого пробела в знаниях (например не знает формулу или какую-то особенность языка), то ход мыслей может выъявить хорошего разработчика.
Мне кажется, значительная часть фронт-ендов, которые успешно работают в больших проектах, и на хорошем счету у начальства, завалят ваше собеседование.
Авторы этого списка вопросов — freeCodeCamp. Занимаются обучением новичков за донат и продажей бумажных сертификатов. Естественно в их интересах составить этот список таким образом, чтобы ученики не расслаблялись и конвертировались на платные курсы к менторам из ближнего круга. Типичный инфобизнес, короче)
Вы хотя бы узнайте что такое freeCodeCamp, а то ваш комментарий похож на типичное «экспертное» мнение.
p.s.
Собственно он им и является.
p.s.
Собственно он им и является.
Если сущность выглядит как утка, крякает как утка и летает как утка, то очевидно что это утка)
Я не верю в добрых самаритян, которые бесплатно тратят свое время на обучение новичков.
Qui prodest?
Я не верю в добрых самаритян, которые бесплатно тратят свое время на обучение новичков.
Qui prodest?
freeCodeCamp — это open source проект. Его созданием и развитием занимаются, в том числе, бывшие ученики.
Там есть страница доната, но мне интересно где вы нашли плату за сертификаты?
В крайнем случае можно просто прочитать на wiki — что такое freecodecamp.
Там есть страница доната, но мне интересно где вы нашли плату за сертификаты?
В крайнем случае можно просто прочитать на wiki — что такое freecodecamp.
Это вроде как стандартная практика. У w3school например эта услуга платная.
Сейчас посмотрел в интернете и не нашел бумажного варианта этого документа. Видимо в этом пункте я ошибся. Признаю.
Сейчас посмотрел в интернете и не нашел бумажного варианта этого документа. Видимо в этом пункте я ошибся. Признаю.
w3school — это ловкие люди, паразитирующие на аббревиатуре w3c.
Не надо к ним ходить, и тем более, что-то покупать у них.
Пользуйтесь MDN, caniuse и другими свободными источниками.
Не надо к ним ходить, и тем более, что-то покупать у них.
Пользуйтесь MDN, caniuse и другими свободными источниками.
UFO just landed and posted this here
Я впервые слышу о нотации О-большое. Что это такое?
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-большое, про курс математического анализа, где оно вводится, про нужность его для разработки форм отчётности.
PS Я прекрасно знаю про O-большое, про курс математического анализа, где оно вводится, про нужность его для разработки форм отчётности.
Интересно.
Я подумал, что речь идёт об O-Data, O-Auth и т.д. Короче завалил бы я это собеседование…
И да. Никогда в жизни не приходилось сталкиваться ни с такими вопросами, ни с такими заданиями в реальной зазработке. Так что фирмы с такими собеседованиями сами себе злобные буратины.
Я подумал, что речь идёт об O-Data, O-Auth и т.д. Короче завалил бы я это собеседование…
И да. Никогда в жизни не приходилось сталкиваться ни с такими вопросами, ни с такими заданиями в реальной зазработке. Так что фирмы с такими собеседованиями сами себе злобные буратины.
… а потом человек, успешно прошедший собеседование будет просто верстать формочки для интернет-магазина…
Настолько глубокие вопросы по всем сферам пригодятся скорее для позиции фронтенд-архитектора, но не для рядового разработчика. Не каждый сеньор занимается подобными вещами в реальной работе, не говоря уже про мидлов. Часть вопросов безусловно полезна, например про отладку, т.к. позволяет понять ход мышления собеседуемого.
Куча вопросов по алгоритмам и ни одного по качеству кода.
Как же вопросы по паттернам, по SOLID, по тестированию, по командной работе, по каким-нибудь заковыристым особенностям JS, которых в нем воз и маленькая тележка?
Без них, и с таким длинным списком (бесполезных, на мой взгляд) вопросов по алгоритмам, есть риск случайно нанять олимпиадника, который продакшн никогда в глаза не видел, и прозевать кучу компетентных специалистов.
Как же вопросы по паттернам, по SOLID, по тестированию, по командной работе, по каким-нибудь заковыристым особенностям JS, которых в нем воз и маленькая тележка?
Без них, и с таким длинным списком (бесполезных, на мой взгляд) вопросов по алгоритмам, есть риск случайно нанять олимпиадника, который продакшн никогда в глаза не видел, и прозевать кучу компетентных специалистов.
Все эти паттерны и заковыристые особенности JS точно также бесполезны, имхо. Типичная задача в совеременной ИТ конторе выглядит как то так: вот есть такая непонятная фигня и вот три каких то тулзы и пара фреймворков написанных на странных диалектах языков похожих на си и джаву, и из них за два месяца надо собрать вот такой прототип который не стыдно будет показать, а там уже допилим если взлетит. Времени на паттерны обычно нет.
Когда я ищу себе человека, я задаю ему лишь 3 вопроса:
1) Почему значение вновь созданной переменной равно undefined? (теория)
2) Как написать делегирование обработки клика на кнопке для структуры элементов типа ul > li > button > «some content» (практика)
3) React это библиотека или фреймворк? Почему так, а не иначе? (критическое мышление)
Потом слушаю ответы и наблюдаю ход мысли. В целом этого достаточно, чтобы составить первичное мнение о человеке. Все остальное покажет практика.
PS:
Писать код на бумажке не заставляю)
1) Почему значение вновь созданной переменной равно undefined? (теория)
2) Как написать делегирование обработки клика на кнопке для структуры элементов типа ul > li > button > «some content» (практика)
3) React это библиотека или фреймворк? Почему так, а не иначе? (критическое мышление)
Потом слушаю ответы и наблюдаю ход мысли. В целом этого достаточно, чтобы составить первичное мнение о человеке. Все остальное покажет практика.
PS:
Писать код на бумажке не заставляю)
На третий вопрос я бы не смог ничего внятного ответить. Хз что это. Экосистема наверно. И да, я один из тех кто пишет этот реакт :)
Там все дело в инверсии управления)
Вы о том, что у библиотеки мы вызываем ее методы, а фреймворк вызывает наши методы?
Именно так)
Т. е. библиотека дёргающая callback'и уже фреймворк? А фреймворк, который настраивается и запускается из условного main — уже библиотека? Смело.
Не совсем. Callback можно передать методу библиотеки, но мы сами решаем когда вызывать этот метод. Например объект XMLHttpReques. Пока мы явно не сделаем ajax запрос, переданный в него callback будет висеть и ждать внутри свойства этого объекта. В случае с фреймворком, он сам решает что и когда должно произойти, следуя своей внутренней логике. Нам остается лишь предоставить колбэки и ждать пока система их сама вызовет.
Да и первоначальный вопрос был больше о React, который очевидно не библиотека, в классическом смысле этого слова, и явно не просто view. Однако многие люди склонны верить тому что написано, а не тому что видят.
О тонкостях в настраивании фреймворков внутри main судить не берусь, ибо не совсем понял как это должно работать)
Да и первоначальный вопрос был больше о React, который очевидно не библиотека, в классическом смысле этого слова, и явно не просто view. Однако многие люди склонны верить тому что написано, а не тому что видят.
О тонкостях в настраивании фреймворков внутри main судить не берусь, ибо не совсем понял как это должно работать)
У почти любого фреймворка есть какие точки входа/процедуры инициализации. В том же react вы рано или поздно должны сделать ReactDOM.render, чтобы подцепить компонент к реальному dom'у. Примерно такая же ситуация часто и в других языках, где рано или поздно надо вызвать точку входа в конкретный фреймворк.
Иногда этот кусок уже написан и про него не нужно париться: java war в сервлет-контейнере/аппсервере, spring boot приложение (с некоторой натяжкой, один static метод с одним аргументом там таки дёрнуть надо), rails и многие другие.
Я обычно провожу водораздел библиотека/фреймворк по тому, насколько сильно конкретная вещь заставляет использовать определенную архитектуру, а не по cflow.
Я лично руководствуюсь фразой Мартина Фаулера:
Вообще в IT очень много сложных вещей, которым тяжело дать однозначное определение. Тот же паттерн MVC: одна и та же схема взаимодайствия компонентов у Майкрософт называется MVP, однако Эппл считает тоже самое истинным MVC. Нам остается лишь принимать сторону того, кого считаем авторитетом в исследуемом вопросе. Главное не устраивать крестовых походов)
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. В частности, второй абзац вашей цитаты по сути про навязывании архитектурного решения.
И там кстати он акцентирует внимание на том, что это одна из ключевых особенностей, но не единственная. Тем самым оставляя пространство для маневров и существования иных мнений. Я считаю что при взаимодействии в команде желательно иметь рядом тех людей у которых почитаемые авторитеты в мире разработки ПО по большей части совпадают с вашими. Это разрешает многие вопросы о code style, паттернах, best practices и т.д.
React.createElement, React.createFactory, React.cloneElement — React библиотека?
componentWillMount, componentDidMount, shouldComponentUpdate, render — React фрэймворк?
И это касается не только React.
componentWillMount, componentDidMount, shouldComponentUpdate, render — React фрэймворк?
И это касается не только React.
А я всегда думал что фреймворк — это набор библиотек
По первому вопросу. Там наверно есть какой то умный ответ, но почти наверняка оно undefined лишь потому что когда то у Брендана Айка не было времени (как обычно) и он что то там нахреначил с пометкой TODO, а оно так и осталось, а потом уже поздно было менять потому что много чего бы поломалось.
UFO just landed and posted this here
Это связано со внутренними свойствами переменной. В целом это практически бесполезное знание, просто интересен ход мысли)
А второй вопрос не вызвал сложностей? В интернете в различных туториалах оно показано в упрощенном виде, что в определенных ситуациях вызывает ошибки (возможно встречали сайты, у которых пункты меню иногда не реагируют на нажатие)
А второй вопрос не вызвал сложностей? В интернете в различных туториалах оно показано в упрощенном виде, что в определенных ситуациях вызывает ошибки (возможно встречали сайты, у которых пункты меню иногда не реагируют на нажатие)
хороший список, чтобы не тратить время на интервью с вами :)
1) и почему?
Зануда-мод скажет, что Реакт это идея, нормативы, а вот ReactJS…
попробую пройти данный опросник, будет забавно узнать.
Насколько актульны знания JS если спецификации обновляются каждый год, каждый релиз браузера поддерживает разные фичи?
Глядя на усилия, что тратятся что бы обойти «нюансы» JavaScript уже можно было бы пару раз сделать нормальный вменяемый язык для разработки. А так это выглядит как попытка на детскую пластиковую машинку приделать двигатель «как у больших дядей».
Мыши продолжают хрустеть кактусом, в надежде что получится текилла :)
Глядя на усилия, что тратятся что бы обойти «нюансы» JavaScript уже можно было бы пару раз сделать нормальный вменяемый язык для разработки. А так это выглядит как попытка на детскую пластиковую машинку приделать двигатель «как у больших дядей».
Мыши продолжают хрустеть кактусом, в надежде что получится текилла :)
UFO just landed and posted this here
А можно пояснить Ваш посыл?
У нас есть 12 стандартов, давайте сделаем 1 универсальный — компания А
У нас есть 13 стандартов, давайте сделаем 1 универсальный — компания B
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
У нас есть 13 стандартов, давайте сделаем 1 универсальный — компания B
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
Понятно :) Вопрос универсальности я не ставил, и не понятно откуда Вы его придумали.
Ну давайте посмотрим эволюцию ECMA-262. Let добавили с более адекватным поведением, class добавили. На мой взгляд — двигаются в сторону «как у всех», а поскольку сделали TypeScript, который еще более «как у всех» и webAccembly шустро распихали по основным движкам, видимо не достаточно быстро JS двигается в сторону «как у всех»
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
Ну давайте посмотрим эволюцию ECMA-262. Let добавили с более адекватным поведением, class добавили. На мой взгляд — двигаются в сторону «как у всех», а поскольку сделали TypeScript, который еще более «как у всех» и webAccembly шустро распихали по основным движкам, видимо не достаточно быстро JS двигается в сторону «как у всех»
Какой-то институтский список вопросов от теоретиков программирования. Мне бы показалась довольно странной компания, которая на собеседовании фронтендера задаёт подобные вопросы. С реальной работой все эти вопросы никак не связаны, за исключением раздела «найдите ошибку».
Супруга проходила собеседование в прошлом месяце. Два этапа: на первом просили выполнить тестовое задание с AngularJS, на втором этапе в скайпе просили рассказать о себе и своём опыте работы. Всё, никаких бинарных деревьев, O больших и серверного API.
Супруга проходила собеседование в прошлом месяце. Два этапа: на первом просили выполнить тестовое задание с AngularJS, на втором этапе в скайпе просили рассказать о себе и своём опыте работы. Всё, никаких бинарных деревьев, O больших и серверного API.
Первый встречный вопрос — сколько мне заплатят за прохождение этих тестов? )))
Четырёхглазые задроты мучают нормальных пацанов, которые просто хотят решать бизнес проблемы.
По роду занятий я видел много разного кода и в компаниях которые зарабатывают деньги своим продуктом, код часто выглядит ужасно, с кучей костылей и велосипедов. Но он работает и приносит деньги.
А четырехглазые задроты в стартапах умеют только бесконечно рефакторить, рассуждать о высоком и проедать деньги инвесторов.
А четырехглазые задроты в стартапах умеют только бесконечно рефакторить, рассуждать о высоком и проедать деньги инвесторов.
А мне понравился список. Мне часть из этих вопросов задавали, ответил без особых проблем. Правда, брали на тимлида по бэкенду.
Это хороший список для тех кто только закончил ВУЗ.
Человека с опытом это может даже оскорбить и в итоге фирма сможет набрать разве что кучу студентов без опыта разработки бизнес приложений.
Человека с опытом это может даже оскорбить и в итоге фирма сможет набрать разве что кучу студентов без опыта разработки бизнес приложений.
И сами вопросы (много очень простых алгоритмических задач и ничего толкового по самому языку, его рантайму, архитектуре, etc) и реакция на них в комментариях (блин, ребят, это очень простые задачи, для решения которых достаточно прочесть ОДНУ не очень длинную книжку, и, да, эти вещи нужно знать для программирования) очень хорошо показывают текущее состояние фронтенда.
Ну вот прочитал человек в свое время книжку, может и не одну, по каким-нибудь структурам данных и алгоритмам работы с ними. Прошли годы, и за это время ему эти знания пригодились ровно ноль раз, так как в языке и платформе, с которым он работает, все эти структуры уже есть. Более того, его род занятий никак не пересекался с прочтенным. Очевидно, знания эти вылетели за ненадобностью.
И вот сидит он, бедняга, на собеседовании со своим багажом ценных знаний и опыта разработки приложений и пытается вспомнить механизмы разрешения коллизий в хэш-таблицах. И сам на работу не устроился, и настроение испорчено, и компания осталась без ценного сотрудника. Смешно.
Там нету задач, для которых требуется помнить какие-либо сложные алгоритмы. Если человек помнит базовые принципы бинарного поиска, бинарного дерева и знает что такое рекурсия — то бинарное дерево и квиксорт он напишет. И механизм разрешения коллизий придумает, если просто знает что такое хэш-функция. А если не помнит… Это не «не помнит», это «не знает». Он просто не потратил за всю свою карьеру два-три вечера чтобы разобраться с простейшей базой (которую надо знать, даже если в работе он использует готовые библиотеки. Потому что абстракции текут). Тогда пусть говнокодит в другом месте, ни программировать ни учиться он просто не умеет, и пригоден только для решения типовых сценарных задач.
Даже если прочтешь эту книжку, то все равно все это забудешь через год-два по причине неиспользования.
Ни разу не встречал человека забывшего базовые вещи.
Забудет даже то, что не знал. Как студенты регулярно забывают на экзаменах.
Ни разу не встречал человека забывшего базовые вещи.
Базовые для кого?
Пошел я как-то пообщаться пару лет назад. И спрашивают у меня «а скажите нам, а что такое SOLID для архитектуры ?» Я честно сказал не знаю, потому что этот SOLID у меня ни с чем не ассоциировался, только на переферии сознания мелькнуло «что-то знакомое». Пришел я домой и начал читать что такое SOLID? И где-то минут через 10 вспомнил! Читал я расшифровку этого SOLID лет 5..7 назад, но поскольку эти принципы и так использовались по отдельности и под другими названиями и ничего нового не давало, то в голове просто не запомнилось, а мозг решил не запоминать «мусор».
И вот вопрос: ты не знаешь как проектировать/писать софт или не знаешь как расшифровывается SOLID? Да и сейчас мозг просто отказывается это запоминать.
Я не вижу в этой ситуации ни одной выйгравшей стороны.
Сейчас плодится столько разной фигни делающие весьма схожие вещи, но под разными названиями что мозг просто заполнен всяким шлаком. А если учесть, то у тебя есть еще и текущий проект(ы) со своей предметной областью, то это все превращается в какой-то сюрреализм.
Перечитайте задачи. Речь о совершенно базовых вещах — бинарный поиск, обход бинарного дерева, рекурсивная сортировка. Это есть в ЛЮБОЙ книжке по базовым алгоритмам. Вы этим пользуетесь каждый день, когда используете, например, ассоциативные массивы или индексы в базах данных. Это вещи которые с листком бумажки и ручкой объясняются за несколько минут и потом не забываются, потому что они слишком простые чтобы их забыть и вы их начинаете видеть их везде. Даже если какие-то детали забываются — с тем же листком бумажки они восстанавливается за минуты, если вы хотя бы один раз в жизни написали руками этот несчастный бинарный поиск.
А то о чем вы написали имеет место, но не имеет ни малейшего отношения к обсуждаемым примерам задач.
UPD. И да, если человек придет на собеседование и не сможет рассказать про бинарный поиск — у меня возникнут очень большие сомнения в его способности программировать. Именно программировать, а не собирать что-то по туториалу из кусочков кода. Потому что очень сложно научиться программировать и пройти мимо настолько базовых вещей.
А то о чем вы написали имеет место, но не имеет ни малейшего отношения к обсуждаемым примерам задач.
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). Ни разу не помню, что бы заостряли внимание на бинарных деревьях как на таковых, зато отлично вбили в голову как анализировать алгоритмы и оптимизировать их исходя из поставленных задач и доступных ресурсов. «Этот несчастный бинарный поиск» проходил просто как один многих наглядных примеров. Учили создавать и опимизировать, а не тупо пользовать.
Есть разница между заполнить таблицу умножения и просто уметь умножать :)
Вы требуете «таблицу уможение», а не умения умножать :)
За эту науку им благодарен безмерно, а не за алгоритмы как таковые.
Последний раз я писал свой индекс два месяца назад. Но, соглашусь, это специфика задач.
А дальше вы зачем-то спорите сами с собой. Вот дальше я именно говорю о том, что если вас учили именно создавать и анализировать, а не использовать, то в процессе вы именно простой бинарный поиск и писали. И именно поэтому он есть в задачах, а красно-черных деревьев там нет. И потому что это основа без которой люди даже не задумываются о том, что лежит под рекомендованными абстракциями, почему и как их правильно использовать.
Неплохо было бы представить решение задачек, я кое как их решил, но интересно как это сделать красиво.
Как работает прототипное наследование и чем оно отличается от классической модели наследования? (По моему мнению, это не особенно полезный вопрос, но многим нравится его задавать.)
Кто-нибудь может привести примеры отличий? Мне в голову приходит только то, что в прототипном наследовании можно добавлять методы динамически
Как работает прототипное наследование и чем оно отличается от классической модели наследования? (По моему мнению, это не особенно полезный вопрос, но многим нравится его задавать.)
Кто-нибудь может привести примеры отличий? Мне в голову приходит только то, что в прототипном наследовании можно добавлять методы динамически
Как по мне, так это похоже на ручную сборку таблицы функций «руками» в момент исполнения, вместо компилятора.
Вот, что хочется сказать насчет задач, вот делаю я их все на таких ресурсах как codewars, hackerrank, и т.д Но это все тогда когда моя голова чиста и хочет нагрузиться, но дай мне эти вопросы в обстановке интервью, я буду на них смотреть как баран на новые ворота, и так даже пару раз бывало. Самое обидно, что в действительности эти знания реально не нужны в 80 процентах случаев. И я честно говоря, не понимаю зачем задавать все эти вопросы на интервью, создайте тестовое задание, приближенное к реалиям вашей фирмы дайте срок человеку, и если он его выполнит успешно это будет ответ на вопрос как он программирует, на крайний случай задайте вопросы по его коду, а это вся теория, блин, я ее забыл больше за 10 лет, чем многие знали, потому как голова забита текущими проблемами
Интересно читать комментарии вроде: «я Senior Angular Developer и такие задачи оторваны от практики и вообще оскорбляют мои религиозные чувства...», «да это только студенты помнят...», «да уже же всё давно реализовано...» и т.п.
Я может быть сейчас скажу очевидную вещь, но эти задачки просто проверяют способность человека думать и решать проблемы. Большую часть из них вообще можно оторвать от конкретного языка программирования. Ты можешь, например, забыть какие-то свойства красно-чёрных деревьев, но их всегда уточнить в том числе и на собеседовании. Грубо говоря, никто (окей-окей, зануды, почти никто) на собеседовании не хочет проверить помнишь ли ты число пи до n-ного знака, интереснее знаешь ли ты что это и зачем, и сможешь ли при необходимости использовать. Ход твоих мыслей, варианты решения, вопросы которые ты задаёшь — это реальная ценность таких собеседований. Причём, максимальная оторванность от технологий и языков — это плюс. Технологии меняются, и человек с соответствующим уровнем инженерной культуры и мышлением без труда в них разберётся.
Вопрос только в том, кто нужен компании: обезьяна для решения бизнес задач, которая гуглит и копипастит или разработчик. Пока абстракция не потекла или страничка не начала загружаться два часа (потому что кто-то написал 6 вложенных for'ов :)) и рендеринг тормозить, можно говорить, что базовые знания не нужны, но вот когда это случится, знания очень даже пригодятся. Я при этом не хочу сказать, что гуглить это плохо, не думать и не понимать при этом, вот что гораздо хуже.
И ещё раз, это не просто какая-то ненужная в 99% случаев теория. Это фундаментальные знания, которые формируют тебя как профессионала и влияют на твоё мышление.
Я может быть сейчас скажу очевидную вещь, но эти задачки просто проверяют способность человека думать и решать проблемы. Большую часть из них вообще можно оторвать от конкретного языка программирования. Ты можешь, например, забыть какие-то свойства красно-чёрных деревьев, но их всегда уточнить в том числе и на собеседовании. Грубо говоря, никто (окей-окей, зануды, почти никто) на собеседовании не хочет проверить помнишь ли ты число пи до n-ного знака, интереснее знаешь ли ты что это и зачем, и сможешь ли при необходимости использовать. Ход твоих мыслей, варианты решения, вопросы которые ты задаёшь — это реальная ценность таких собеседований. Причём, максимальная оторванность от технологий и языков — это плюс. Технологии меняются, и человек с соответствующим уровнем инженерной культуры и мышлением без труда в них разберётся.
Вопрос только в том, кто нужен компании: обезьяна для решения бизнес задач, которая гуглит и копипастит или разработчик. Пока абстракция не потекла или страничка не начала загружаться два часа (потому что кто-то написал 6 вложенных for'ов :)) и рендеринг тормозить, можно говорить, что базовые знания не нужны, но вот когда это случится, знания очень даже пригодятся. Я при этом не хочу сказать, что гуглить это плохо, не думать и не понимать при этом, вот что гораздо хуже.
И ещё раз, это не просто какая-то ненужная в 99% случаев теория. Это фундаментальные знания, которые формируют тебя как профессионала и влияют на твоё мышление.
обезьяна для решения бизнес задач, которая гуглит и копипастит или разработчик.
ну тут явно вопрос в цене.
За одну сумму при таких задачах, я просто встану и уйду с собеседования, за интересную зарплату, буду сидеть и вспоминать всю теорию.
Как сказал человек выше, я за 10 лет забыл больше, чем знают текущие разработчики. Вопрос в цене.
Компенсация напрямую зависит от ваших знаний. Т.е. пока люди не узнают что вы реально можете и насколько это соотносится с теми задачами, которые они хотят с вашей помощью решить, я уверен, что они вам не предложат существенную сумму.
Никто же не скажет: «решишь вот эти базовые задачки, и мы тебе будем платить 10k USD net в месяц». Нормальная компенсация предполагает, что либо у вас есть репутация и вы известный спец, либо вам придётся доказывать, что вы чего-то стоите и вас прогонят через 2-3 собеседования (в лучшем случае), первым из которых будут те самые задачи, которые описали выше. Это разумно, что если у человека нет базовых знаний, то дальше он не пойдёт.
Никто же не скажет: «решишь вот эти базовые задачки, и мы тебе будем платить 10k USD net в месяц». Нормальная компенсация предполагает, что либо у вас есть репутация и вы известный спец, либо вам придётся доказывать, что вы чего-то стоите и вас прогонят через 2-3 собеседования (в лучшем случае), первым из которых будут те самые задачи, которые описали выше. Это разумно, что если у человека нет базовых знаний, то дальше он не пойдёт.
Вот только разговор о совсем-совсем базовых вещах (бинарное дерево, блин!).
Вы можете себе представить инженера-электронщика забывшего закон Ома? Как такое может случиться?
Только если он его и не знал и проектировал схемы эвристически и копипастом, не понимая законов лежащих в основе этих схем.
Вы можете себе представить инженера-электронщика забывшего закон Ома? Как такое может случиться?
Только если он его и не знал и проектировал схемы эвристически и копипастом, не понимая законов лежащих в основе этих схем.
Я не говорю, что я их не знаю, я говорю что я не буду их решать. Хотите что бы что то было — давайте тестовое задание. А теория учится за время испытательного срока.
Он его использует в той или иной степени каждый день, все-таки. А вот типичный электрик может его и не знает. Ну то есть он помнит из школы что-то невнятное про «сила тока прямо пропорциональна напряжению и обратно пропорциональна сопротивлению», но не понимает природы закона и его физической сути.
Зато он знает какие провода с какими соединять нельзя.
Я вот, к сожалению, уже не помню некоторых замечательных пределов или известных интегралов. И, не уверен, что смогу в стрессовой ситуации посчитать детерминант матрицы. Но знаю, что за полчаса разберусь и все вспомню, если будет доступ к источнику знаний, так как вспоминать гораздо проще чем учить. Вопрос к топику только один — можно ли пользоваться интернетом, как в жизни или все «рожать» из головы?
Зато он знает какие провода с какими соединять нельзя.
Я вот, к сожалению, уже не помню некоторых замечательных пределов или известных интегралов. И, не уверен, что смогу в стрессовой ситуации посчитать детерминант матрицы. Но знаю, что за полчаса разберусь и все вспомню, если будет доступ к источнику знаний, так как вспоминать гораздо проще чем учить. Вопрос к топику только один — можно ли пользоваться интернетом, как в жизни или все «рожать» из головы?
Причём, максимальная оторванность от технологий и языков — это плюс. Технологии меняются, и человек с соответствующим уровнем инженерной культуры и мышлением без труда в них разберётся.
Всё-таки у каждой области есть своя специфика. Я вот имею высшее образование в области Информационных Технологии, в школе был олимпиадником по математике и программированию, занимал призовые места на областных соревнованиях. В общем теоретически подкован. Уже 6 лет работаю в области веб-разработки и вот хоть убейте не могу представить, как я прихожу в гейм-девелопмент и «без труда в нём разбираюсь».
В то же время живо представляю картину: ко мне в команду приходит фронт-енд разработчик, которого на собеседовании гоняли по «оторванным от технологии и языков» вопросам, и когда ему нужно поменять стили при наведении на кнопку он превращается в
обезьяна для решения бизнес задач, которая гуглит и копипастит
Я не писал, что если у человека есть фундаментальные знания, то не должно быть знаний предметных, а лишь подчеркнул их важность. Если вы приходите в тот же гейм-дев (или вообще куда угодно) не на должность интерна, то разумеется вы должны иметь соответствующий набор прикладных навыков. Но этот набор надо расширять, совершенствовать, рано или поздно появятся нестандартные задачи, которые не укладываются в рамки текущего инструмента, где-то надо будет заняться оптимизациями и т.п. Вот тут-то и сыграют роль те самые фундаментальные знания и мышление. Вы сможете, или нет.
Перечитал ваш комментарий, возможно я не правильно понял ваш посыл. Я с вами в целом согласен, однако далеко не всем компаниям хоть сколько-то важны эти самые фундаментальные знания именно в контексте найма фронтенд-разработчика. Не кидайте в меня камнями, это не мое мнение, это факт. Я работал на крупном проекте в качестве фронтенд-разработчика, в команде был человек «из глубинки». У него были серьезные прогалы в знаниях школьной математики, которые всплыли за год ровно один раз. И с ним не было проблем до или после этого, он писал хороший код, который было приятно читать и легко поддерживать. И его не уволили с пометкой «отучиться в школе ещё раз».
А где ответы-то, гуглить что ли?)
Не представляете, сколько людей сыпется на банальном «загрузить и выполнить N js-файлов по порядку»
Тут многие говорят, что задачи «простые», нуну:
- Алгоритм нахождения простых чисел там же в комментариях автору указывают про Решето Эратосфена
- Фибоначчи (просто несколько ссылок)
- Про sort бесконечность, но для фронтендера будет интересна Реализация сортировки в V8 от Google
- и так далее.
Задавая такие вопросы на собеседовании, максимум, что можно получить, это говнокод, который никак не характеризует фронтендера.
Ну в данном контексте вопросы были простыми, потому что решение (по моему скромному мнению) предлагалось найти в лоб. Все что вы перечислили хорошо, но не для фронтенд разработчика.
А по поводу сложности алгоритмов и разные подходы: люди, которые участвовали в олимпиадном программирование на пересчет знают как и все алгоритмы сортировки и спектр их применения, так и узконаправленные алгоритмы быстрого поиска нахождения простых чисел (фибоначчи ect). Но это уже другая сфера, с фрондендом никак не связанная.
А по поводу сложности алгоритмов и разные подходы: люди, которые участвовали в олимпиадном программирование на пересчет знают как и все алгоритмы сортировки и спектр их применения, так и узконаправленные алгоритмы быстрого поиска нахождения простых чисел (фибоначчи ect). Но это уже другая сфера, с фрондендом никак не связанная.
Так я и говорю, что не понимаю, зачем мне ответ в виде говнокода?! Что он должен мне показать? Если хочется понять, знает-ли человек про рекурсию, ну так спросите его про неё, даже про виды можно поговорить.
Деревья? Не вопрос, есть DOM, чем не дерево и так далее.
Ну вопрос про какие-то минимальные знания в математике и алгоритмизации (знание простых чисел, чисел фибоначчи, разных видов деревьев) + умение писать. Этот «говнокод» может и нафиг никому не нужен, но умение человека применить какие то теоретические знания в практике по другому не выявить. Ты можешь знать в теории много чего умного, но какой от этого толк, если применить не можешь?
Похоже не сильно себе представляют что ищут и как.
Давайте наймем водителя с такой логикой?
Итак, задачи водителя при найме:
Ага, не знаешь! Как ты тогда собираешься водить такси или трактор?
Вот как-то же без этого мозгоклюйства решили проблему в остальном мире, и права признают выданные в другой стране, и медицину и еще много чего.
А тут какое-то мерянье професионалов «на вес и в ширину»… Как прием в средневековую гильдию :)
Давайте наймем водителя с такой логикой?
Итак, задачи водителя при найме:
- Что такое цикл Карно ?
- расчитайте трения качения колес вашей машины ?
- Нарисуйте фронт детонации от свечи в двигателях машин ?
- Чем отличается двигатель из чугуна, стали, аллюминия, керамики ?
- Что такое двигатель внутреннего сгорания, внешнего сгорания ?
- Соберите паровую машину из зажигалки зиппо, пружинки от шариковой ручки и корпуса металлического карандаша ?
Ага, не знаешь! Как ты тогда собираешься водить такси или трактор?
Вот как-то же без этого мозгоклюйства решили проблему в остальном мире, и права признают выданные в другой стране, и медицину и еще много чего.
А тут какое-то мерянье професионалов «на вес и в ширину»… Как прием в средневековую гильдию :)
UFO just landed and posted this here
фибоначчи, прочтые числа, сортровка, О(n)… ясно, понятно.
Алгоритмы — это хорошо, но нужно говорить не об абстрактных алгоритмах, вроде простых числел, фибоначчи и т.д., а о практических вариантах их применения. Т.е. ответ на вопрос «Как вы организуете очередь в многопоточном приложении» в 100 раз важнее умения написать сортировку или поиск в дереве. Я бы старался придерживаться соотношения 20%/80% в теории и практических заданиях. А практические задачи бы брал из бизнеса, а не из науки.
UFO just landed and posted this here
Спрашивать у среднестатистического фронтендера «Как вы организуете очередь в многопоточном приложении» бессмысленно, к front-end'у этот вопрос имеет точно меньше отношение чем простые числа и бинарные деревья. Еще варианты? Брать же практические задачи из бизнеса проблематично, потому что уходит много времени на упрощение и формулировку требований. Задачи из статьи уже сформулированы, все определения с ними связанные описаны в wikipedia.
Про очереди согласен — это для бекэнда вопрос. Просто привёл его для примера.
Но для фронтэнда тоже полезных вопросов много:
— Как правильно использовать кэширование браузера?, Как его отключить?
— Плюсы и минусы использования CDN?
— Как можно ускорить время загрузки страницы?
— Основные виды атак на сайт и как от них защититься
— С какими проблемами браузерной совместимости сталкивались и как решали?
— Нужно написать интерфейс для существующих WebAPI сервисов за максимально короткий срок, но с возможностью масштабирования в будущем. Какие технологии выберите? Объясните почему…
Как видите на эти вопросы часто нет однозначного ответа, поэтому спрашивающий должнен сам хорошо разбираться в этих вопросах. Но зато пользы от этих вопросов намного больше чем от алгоритмов, которые никогда не пригодятся в реальной разработке.
Также хорошим вопросом может быть кусок кода реального проекта и просьба найти недостатки и посоветовать как оптимизировать, а также найти замечания по оформлению кода.
Но для фронтэнда тоже полезных вопросов много:
— Как правильно использовать кэширование браузера?, Как его отключить?
— Плюсы и минусы использования CDN?
— Как можно ускорить время загрузки страницы?
— Основные виды атак на сайт и как от них защититься
— С какими проблемами браузерной совместимости сталкивались и как решали?
— Нужно написать интерфейс для существующих WebAPI сервисов за максимально короткий срок, но с возможностью масштабирования в будущем. Какие технологии выберите? Объясните почему…
Как видите на эти вопросы часто нет однозначного ответа, поэтому спрашивающий должнен сам хорошо разбираться в этих вопросах. Но зато пользы от этих вопросов намного больше чем от алгоритмов, которые никогда не пригодятся в реальной разработке.
Также хорошим вопросом может быть кусок кода реального проекта и просьба найти недостатки и посоветовать как оптимизировать, а также найти замечания по оформлению кода.
Считаю, что алгоритмы знать полезно и решать такие задачи нужно уметь, но после прочтения статьи возник вопрос — зачем человеку, который всё это знает, идти в типичную шарагу шлёпать формы? Иными словами, имеет смысл всё это спрашивать, если компания может предложить задачи, которые заинтересуют такого человека, иначе он же отупеет к херам или уйдёт.
Ни одного вопроса про асинхронное выполнение. Ни одного вопроса про SPA (включая service workers и подобные вещи) это собеседование не на фронтенд.
Или вот банальный вопрос:
назовите хотя бы один случай, когда использование document.write()
может быть необходимо
ответ:
Вы еще спросите что делает css-свйоство hasLayout.
Не могу, потому что нет такого случая. Все что можно реализовать с помощью document.write — можно реализовать с помощью других средств во всех браузерах моложе 8 лет. Если вы собираетесь поддерживать браузеры старше 8 лет — я лучше пойду.
Вы еще спросите что делает css-свйоство hasLayout.
я лучше пойду
так и было :)
Про старые браузеры маргинальный случай и я его не имел ввиду (замена currentScript полагаю?), и нет, кое что сделать нельзя другими средствами, стоит вспомнить что именно делает этот метод. Я конечно никогда такую чушь не спрашиваю, но если кандидат ответит таким образом, то он действительно лучше пойдет.
del
Sign up to leave a comment.
Собеседование для фронтенд-разработчика на JavaScript: самые лучшие вопросы