×Закрыть

Подготовка к собеседованию Middle/Senior Frontend Developer

Всем привет, хотел поделиться с общественностью списком вопросов к техническому собеседованию Middle-Senior уровня.

Вопросы разбиты по нескольким категориям, основной упор сделан на фундаментальные вещи, а не на знание «фреймворка Х». Ответов на вопросы в репозитории нет, но есть ссылки на материалы, где можно найти релевантную информацию.

Темы:
1) Functional programming
2) OOP
3) OOD
4) Architecture & Design
5) Patterns
6) Network
7) TypeScript
8) Testing
0) PWA
10) Git
11) Databases

Ссылка на репозиторий: github.com/...​tware-developer-questions

Надеюсь эта информация будет вам полезна как при подготовке к собеседованию, так и просто для того что бы понять где у вас есть пробелы в знаниях.

LinkedIn

Лучшие комментарии пропустить

За труд респект, сохранил себе, но некоторые вопросы, конечно, это просто жесть.
Во-первых, я не уверен, что среднестатистический фронтэнд синьор знает хотя бы половину понятий, перечисленных в разделе про ФП, его как будто заядлый хаскелист писал.
Во-вторых, вопросы типа «How does Rich Hickey in his report „Simple Made Easy“ describe the difference between Simple and Easy? Why in the first place is it striving for simplicity, and not for ease?» — ну серьёзно? Я бы охренел от так поставленного вопроса. Можно ещё вопрос «а о чем Макконнелл пишет на странице 477 второго издания книги «Совершенный код».

а потім виходиш на роботу, і переписуєш реактік з чогось на хукі :D

Не хватает внезапных вопросов про докер и CI/CD

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Очередное пробитие дна. Этому контенту место, вообще то, на очаровательном.итэ.

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

«Применять шаблоны проектирования»

Оформляется в виде курсовой работы. Минимум пять шаблонов проектирования. Курсовая работа защищается перед комиссией экспертов...

OMG...

Профессиональная деформация — я 10 лет в ХНУРЭ преподавал. :)

Так может надо меняться, а не гордиться «деформацией»?

Я горжусь, что был студентом, аспирантом, ассистентом, преподавателем и старшим преподавателем ХНУРЭ. Почему я должен отказываться от этого? В свою работу я взял оттуда лучшее, в т. ч. и формализацию знаний и полученного опыта в виде курсовых работ.

Потому что эта деформация конкретно ограницивает ваш кругозор.

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

КИУ.
Единственное, что курсовая формализирует — умение пользоваться вордом и паверпоинтом, если честно. Периодически тема курсовой вообще слабо коррелировала с материалом за курс и лекциями.

Ну так получается мы учились у одних и тех же преподавателей. При условии, что вы были на АПВТ или ЭВМ.

А в каких годах вы учились? Я в 2000-2005.

2007-2012 должно быть в линкедине.
Возможно кафедра и факультет накладывают отпечаток. Все же КИУ — Хаханов, и там можно позаимствовать только худшее было (имхо).
С кафедры АПВТ я могу вспомнить у нас навскидку только Алипова. Старик давал материал достаточно понятно и адекватно (АЛУ). Но вот возраст уже тогда сказывался.

Не исключаю, что на других кафедрах/факультетах действительно было что-то хорошее, что можно было перенять. Но из того, с чем я сталкивался...
Кафедра ОБЖ — коррупция (кафедра физкультуры — в меньшей степени, например обязательная покупка «методички» для допуска к экзамену)
КИУ — относительное самодурство декана. И там можно дальше продолжать вспоминать. В том числе и случаи дискриминации. Билетченко и сдача наличием «сисек», например.

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

Я так розумію розробникам ви платите ≥ III квартиль по ринку?

можно написать рабочее, поддерживаемое читаемое и масштабируемое приложение БЕЗ использования ГОФ паттернов. Особенно на TS/Пурсе.

Поделитесь примерами, пожалуйста. Я не против.

Так-то стратегия будет обычной функцией, фабрики и декораторы так используются, chain of responsibility вшит в ивенты, паб саб тоже повсеместно. Это все тот же ГОФ, только без рецептов для джавы. Вся суть паттернов в узнаваемости их при общении, а не в форме исполнения

+1. Я бы еще добавил, что суть паттернов — дать шаблон решения в определенном контексте задачи, чтобы не изобретать велосипед.

Лицо рука. Паттерны сами по себе не дают

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

. Это достигается за счёт обобщающей способности системы типов. Вот без хкт вы не сможете сделать абстрактную монаду без хаков системы типов через касты/дейнемик или рек бойлерплейта. Вам нужно будет на каждое F[_] и T рисовать свой отдельный инстанс монады(читай делать кодоген, что жутко гимор и ломко вбольшинстве языков, а ещё комбинаторно сложно потому что покрытие, скажем всех коллекций джавы монадой для каких-нибуть там 1000 бизнес сущностей это будет уже десятки тысяч классов из пустого места) и подставлять его через di или кодоген снова, что обысно ненадёжно. Точно так же и с вашими паттернами — вам нужно изобретать велосипед в точке его применения — переписывать заново каждый раз. Но у вас просто нет другого выбора — ваша система типов и отсуствие вменяемых макросов/кодогена и стейджинга делает свое дело. Безхктшные системы типов и полиморфизм через инвазивную реализацию хорошо работает только на мутации, да и то очень ограниченно. А как мы с вами все хорошо знаем, что код с беспорядочными мутациями в асинхронном контексте = забыть о возможности понять что там творится. Это кстати, причина если не всех то почти всех флаки тестов — беспорядочна недетерминированная асинхронщина.

стратегия будет обычной функцией, фабрики и декораторы так используются, chain of responsibility вшит в ивенты, паб саб тоже повсеместно. Это все тот же ГОФ, только без рецептов для джав

вы упустили одну «маленькую» деталечку. Паттерн не имеет формальное определение, а только определение на пальцах. Из этого вытекает сразу 2 вещи: 1) у каждого писателя своё определение каждого конкретного паттерна, которое может быть как-то соотносится с определениями других писателей. 2) никакой ризонинг о паттернах и построение абстракций поверх паттернов невозможен по причине чудовищного протекания таковых попыток. По этому цель

узнаваемости их при общении

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

узнаваемости их при общении, а не в форме исполнения

. Это раз. Во вторых — в паттерны не заложена ни soundness, ни completeness, ни composability, я не могу наверняка сказать какими свойствами будет обладать фабрика декораторов стратегий, и даже не могу наверняка сказать, будет ли в действительности названая страхолюдина а не что — то на неё похоже. А вот какими свойствами будет обладать стрелка/монада/клейсля/моноид — я знаю, ведь у них есть формальные законы. Кроме того, я вполне могу писать код поверх этих абстракций и описывать какие-то их преобразования, которые бывают полезны. Самый простой и банальный пример — перестановка F[G[_]] в G[F[_]] aka метод сиквенс, в скале это ровно один def в котиках, в ооп — каждый раз переизобретается в точке использования. Паттерны этого не могут. Вообще, совсем, от слова никак.

А всё почему? Потому что паттерны слепили Expert Beginner в области построения теорий. Люди которые клепали прикладные системы и нащупали какие-то абстракции но в силу отсуствия культуры построения теорий не смогли сделать из них что — то стоящее(но побежали продавать и тыкать в каждого программера на перевес и быстрее всех).

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

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

у каждого писателя своё определение каждого конкретного паттерна, которое может быть как-то соотносится с определениями других писателей.

в пределах одной команды они убалтываются

никакой ризонинг о паттернах и построение абстракций поверх паттернов невозможен по причине чудовищного протекания таковых попыток.

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

совершенно не исполняется

Я даже не знаю чем контрить такие аргументы.

в паттерны не заложена ни soundness, ни completeness, ни composability,

Composability дело наживное, насчет первых я могу поспорить что оно никому не впилось, на практике.

Самый простой и банальный пример — перестановка F[G[_]] в G[F[_]] aka метод сиквенс, в скале это ровно один def в котиках, в ооп — каждый раз переизобретается в точке использования.

1. Не пишите ооп.
2. Вы описываете реализацию паттерна в частном контексте фп подхода и языка. Как это противоречит тому, что я написал?

в силу отсуствия культуры построения теорий не смогли сделать из них что — то стоящее

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

Вот так и живем, один хитровымороченный однострочник заменяет джава класс вместе со всеми тестами и ценой поддержки

боюсь от тестов (в одном или ином виде) не убежать, и у ФП цена поддержи и когнитивная цена далеко не нулевая.

sound теоркат,

Если вы собрались гнобить 90% индустрии по строгости, то я бы не упоминал soundness и TS в одной ветке.

в пределах одной команды они убалтываются

на это уходит каждый раз много времени, в никуда.

что оно никому не впилось, на практике.

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

с теорией функций

к программированию имеет опосредованное отношение. Теоркат и лямбда калкулус это всё называется.

боюсь от тестов (в одном или ином виде) не убежать

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

когнитивная цена далеко не нулевая.

Вот бывает попадаются простыни в 200 строк одной функции. с 15 точками выхода, кучей уровней вложенности, трайкетчами и асинхронными вызовами в перемешку. Это традиционный кровавый интерпрайз когда функция в 20-30 строчек путем вписывания туда латок-костылей разрастается до таких масштабов. Вот чтобы в этом разобратся и оттрассировать все пути исполнения, вытащить логику и варианты может уйти пару дней спокойно. Это же можно переписать на хреноиды и держать его в районе 30 строчек. или побить на функции и скомпозить и получить решение ещё проще и короче. Да, нужно выучить что эти стандартные хреноиды значат, но это не нужно будет учит каждый раз, но ценой этого когнитивный оверхед схлопывается в несколько раз. Да, иногда нужно будет переделывать набор используемых хреноидов под изменения, но я бы не сказал что это будет особо дороже чтобы за 15 минут вкрючить трайчик и ифчик и потом 3 дня думать почему падают тесты.

Composability дело наживное

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

Они описали часто используемые шаблоны

и ринулись их продавать и впихивать в каждую репу под видом «чистого кода».

как в классической среде

классическая среда это как раз конструктивная математика из которой выросло ФП. Оно появилось задолго до тех кто выдумал паттерны.

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

я уже описал почему это не паттерн и чем отличается, просто вброс или не читал.

если ты что — то оттайпчекал,

Давай не будем приписывать мне слова. Я говорил именно про саунднесс и комплитнес, а не про типизацию. Тот же тс позволяет типизировать не будучи саундным, и при это закрывать 99% дыр.

Вот бывает попадаются простыни в 200 строк одной функции

Я тоже умею сравнивать дерьмо с одной стороны и конфетку с другой

вам не нужно писать 100500 тестов о том что велосипед переизобретен правильно.

Я и так этим не занимаюсь

Да, нужно выучить что эти стандартные хреноиды значат

чтд

вкрючить трайчик и ифчик и потом 3 дня думать почему падают тесты.

опять крайности против конфетки

я уже описал почему это не паттерн и чем отличается, просто вброс или не читал.

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

повышает собственное чсв и чуство архитектора

Я пожалуй прекращу спорить после этих крипто переходов на личности

На моей памяти там где на собеседовании нужно было выступать перед комиссией экспертов, мало платили

Я уточню: эти карьерные экзамены — они для уже тех инженеров, которые стали нашими сотрудниками, которые идут по карьерному плану. Разумеется, что за час собеседования никаких курсовых люди не делают — на это нет времени. Для штатных сотрудников на подготовку и повышение квалификации дается полгода, год. На собеседовании идет опрос, чтобы определить квалификацию инженера по нашему стандарту: workat.dnt-lab.com/...​are-engineer-career-2020

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

Письменное структурированное оформление мыслей — один из лучших способов закрепления знаний. Лучше только пойти и научить другого. :)

Не вмієш робити сам — вчи інших. Вся суть академічної хєрні.

Альтернативное мнение:

Один из принимающих диплом поинтересовался (Тот же ВУЗ):
— А какая реальная ценность диплома? Как вы думаете, его можно использовать в жизни?
— Да
— Да вы оптимист, а вы знаете, кто такой оптимист? плохо проинформированный реалист

Конец басне про структурирование и оформление мыслей в курсовых/дипломах Украинского выша.

* дополнение к побасенке: есть куча людей, которым там не место и которые действительно давали полезную информацию. Включая Семенова и Кузнецова из твоего вуза. Я не знаю, пересекался ли ты с ними. И этот перл выше выдал тоже очень годный препод. Но к сожалению, курсачи и дипломы — бесполезны. Даже если и интересная тема

и просто оставлю это ниже:

Как часто нужно комитить код в репозиторий? Почему?
Можно ли закомитить сразу три бага в одном комите? Почему?
В какой статус переводится задача в Джире, когда начинается над ней работа?
Обязательно ли запускать тесты перед пушем в репозиторий? Почему?
Что делать, если застрял на задаче?
Почему нельзя указывать реальные ключи доступа к сервисам?
Почему важно, чтобы не было орфографических ошибок в коде?
Сколько в одном юнит-тесте должно быть asserts?
На основании чего составляется личный ежедневный план?
Что значит «блокировать» по работе?
Что делать с задачами, которые кого-то блокируют?
Как нужно реагировать на комментарии на код ревью?
Можно ли пушить в репозиторий код не проходящий тесты?
Как должен быть настроен Битбакет?
Как организуются бранчи в гите?

вы что, действительно только с студентами работаете?
по пунктам без комментариев. оставим это для фантазии читателя

Семенова и Кузнецова

Не знаком.

ХАИ.
Кузнецов — автор одного из прокетов на конкурс стандарта БСШ в Украине. 2011 (вроде) год.
Я их упомянул в контексте предыдущего комментатора.

Эти двое — варяги. Я, если честно, даже не знаю как эта штука между ВУЗами работает.

Наче в совок на завод попав...

Какая прелесть. Такое было в совке и таким пользовались. Вы реинкарнировали хорошо забытое старое.

Рассказываю. Если тебе собеседует не твой будущий начальник, а нечто другое то:
1. Собеседует один человек. Это в пул ресурсов. Могут спрашивать по С++, а програмить будешь в будущем на жабаскрипте или наоборот
2. Собеседует комиссия. Это значит, что на конторе никто не хочет и не принимает никаких решений, все сваливают всё друг на друга и вся работа будет в таком же стиле. Зашедший проект на Т времени будут обсуждать на больших митингах T*0.9 времени. Затем в последний момент за время Т*0.1 поручат его быстро закодить 1-3 джунам и 1 сеньору.

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

Уххх. Можно фигануть абстрактную фабрику по производству фабрик синглтонов-декораторов для абстрактных фабрик.

Цікаво, для покарання за баги ваша компанія використовує різки чи перейшли на якісь більш сучасні методи — електрошокери там, чи пиляння зубів напилком?

Откуда у вас такие ассоциации? С текущего или предыдущего места работы? У нас по другому: у кого надежней код, тот получает больше вознаграждение.

Асоціації — із совкового минулого.

Мене — ні. Інших — так. А вас били? Чи ви були по іншу сторону?

Нет. И мне не знакомы люди, которых бы били током за ошибки.

Краще за прикладом якудза фаланги пальців. Через деякий час такому говнокодеру просто говнокодити буде вже нічим. Й при співбесіді при прийомі на роботу можна буде просто попросити показати руки й все стане зрозуміло. Японія не совок, коли що.
З.І. Робота з тою ж болгаркою чи навіть звичайна їзда за кермом не пробачають грубих помилок, а от АйТі деяким дуже багато сходить з рук.

от что мы в Design and Test Lab спрашиваем

надеюсь, после такого выноса мозга, там зарплаты у вас уровня гугла, а не немецкого водителя автобуса.

В чем там «вынос мозга»? В знании базовых понятий объектно-ориентированного проектирования?

да ну, прям таки базовых? там половина бесполезный теоретический мусор, предназначенный исключительно для ЧСВ и очковтирательства. Для веба (раз там тайпскрипт упоминается) на 90% состоящих из самоучек вообще умора. Кто вообще такое спрашивает? Гарантировано 75-90% сеньйоров зафейлит блок OOP/OOD при том что задачи свои выполняет.

Если вы не знаете как базовые паттерны применяются — это недостаток вашей квалификации и квалификации тех самопровозглашенных сеньоров.

И да, паттерны на вебе тоже нужны, не меньше чем на беке.

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

Вы что-то путаете. Теоретические разглагольствования не мои — они Эриха Гаммы — уважаемого ученого в Европе и на западе.

Эрих Гамма — это Эрих Гамма, а не ты.
Вот если твои книжки будут, как у Эриха Гаммы я их почитаю.

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

Так какие ко мне вопросы? Вот я взял книгу Гаммы, на основе этой книги составил вопросы. Мне нужно было свои паттерны что-ли выдумать? Относительно же этой книги делается код-ревью внедрения паттернов в коде.

это у тебя полное отсутствие опыта практического программирования

Про вот это я кстати не понял. Я с 2011 года регулярно каждый день программирую и руковожу разработками. Сейчас своя компания 28 человек. О каком полном отсутствии практического опыта программирования идет речь?

Я с 2011 года регулярно каждый день программирую и руковожу разработками. Сейчас своя компания 28 человек.

В этом случае ты гений. По-моему опыту, если у человека в подчинение 5 −10 человек, то программировать у него получается только полдня. Если больше людей, то либо он руководит, либо он не программирует, а гадит в коде.

А о твоем практическом опыте очень много рассказали твои посты здесь.

как то проходил собеседование давным давно и спросили меня за паттерны на что сказал что не знаю. попросили написать функцию.

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

потом меня спросили какие паттерны я заюзал — сказал что вроде никаких, и так все просто.

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

к чему это все — паттерны сильно переоценены

Но с паттернами есть такой момент. Джуну очень полезно почитать книжки по ним, чтобы увидеть, как люди разные задачи решали, но вот спрашивать это на собеседованиях — это бред.
Но сейчас уже как-бы эта дурь схлынула большей часть. Лично я на вопросы о паттернах всегда отвечал: «Только Low coupling и High cohesion. С остальными пойдете лесом.»

почитать — и зазубрить — это 2 разных дела

как по мне куда важнее если человек будет иметь правильное понимание SOLID, DRY, KISS & etc.

и зазубрить

И как ты это у меня в посте выше вычитал?

Ну вот в js каждый более-менее опытный разработчик писал функции, которые принимают или возвращают другие функции. Но нужно ли для работы знать что они называются Higher-order functions? Я считаю что достаточно знать что язык так позволяет делать

ну как бы цель одна — почесть свое чсв

Если вы не знаете как базовые паттерны применяются

Недостаток квалификации, это когда ты не можешь найти для поставленной задачи решение, качество которого подтверждается другими специалистами, а не зубрежка коней в вакууме. С патернами там излишняя конкретика по каждому. Мне это дико напоминает подход теоретиков, а правда она по середине.
Я не говорю, что они вообще не нужны, но и они же не 100% панацея или единственный тру вей. Патерны нужны для расширения кругозора и узнаваемости, не более того. Одно дело иметь представление об их существовании и о чем они в общих чертах, другое дело 10 вопросов по одному патерну- оно нафик никому не сдалось в реальной разработке.

на вебе тоже нужны, не меньше чем на беке.

веб!==фронт. Я имел ввиду весь стек, который традиционно юзается в веб, в том числе со стороны бека.

Под вебом я подразумевал фронт. Т. е. паттерны нужны и на фронте, и на беке.

арантировано 75-90% сеньйоров зафейлит блок OOP/OOD при том что задачи свои выполняет.

В теоретической части да. Они ее 10-15 лет назад джунами учили и уже не помнят.
Они просто применяют эти знания автоматически даже не задумываясь. Просто делают так, как надо и уже не помнят почему так надо, а не иначе.

Помню собеседовался и мне подсунули какой-то пример с наследованием и теоретический вопрос. Я на него не ответил. Хотя именно оный подход в тот момент реализовывал на текущей работе в тот день. Я просто програмил и писал (можно сказать мышечная память работала).
После пошел попить пивка и за пивом вспомнил теорию, которую я разбирал за 10 лет до того дня.

Что такое инкапсуляция? В двух словах пжлст.

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

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

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

Правильное отношение к карьерному экзамену — повысить свой уровень квалификации, иметь больше знаний и навыков, чтобы эффективнее решать поставленные задачи, получить больше ответственности и больше полномочий.

По матрице выше сразу вопрос: «а когда не использовать?»
Возьмемся за «Apple, Swift»: Маркап референс... МАРКАП.

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

Документация кода — хорошо, но инструмент документации.. Какая разница?

Это квалификация, которую мы требуем у младших программистов (workat.dnt-lab.com/...​are-engineer-career-2020). И мы не принимаем код, если у него интерфейсы без документации.

2. Что такое «запах кода»?

— Фу, что за запах в опенспейсе?
— Это запах кода...

Да, этому термину уже вот как 14 лет. :) См. у Мартина Фаулера: martinfowler.com/bliki/CodeSmell.html

Не этому, а «code smell») Я обычно в оригинале читаю, но если уж переводить, то это «код с душком», или какое-то другое похожее по смыслу выражение в русском языке, не связанное с запахом. «Запах кода» — это не то, зато весело)

Код с душком — это код с душком. А запахи кода — это запахи кода.

ru.wikipedia.org/...​тно-ориентированного_кода

Ладно, это какой-то спор ради спора. «Запах кода» — это неудачный перевод «code smell» на русский язык, и никакое количество ссылок на википедию это не изменит. Если в «code smell» явно заложен негативный смысл, то запах — это запах. «code smell» — это код, который уже попахивает. «Запах кода» — это как «запах хлеба» или «запах напалма по утрам». Поэтому «запах кода» звучит смешно, ничего личного. :)

Там и сам Фаулер много пишет просто слово smell, без привязки к коду.

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

Термин «запах» мне не нравится, т. к. идет ассоциация с «говнокодом», а слово «говнокод» у нас в организации запрещено.

Слово запрещено, а ... не исчезла.

Совершенно верно. Просто начали называть более точными профессиональными терминами. :)

Не, основная идея, что если кто-то на код-ревью видит «г....д», то нельзя говорить «это г.....д», а надо назвать один из запахов кода: «дубликация кода», «одержимость элементарными типами», «операторы типа switch» и так далее. Т. е. не просто покритиковал, а сразу сказал что не так. Ну а там дальше уже по Фаулеру можно и рефакторинги подходящие подобрать.

вообще, такой подход к собеседованию, гнилой с самого начала.

А права какой категории нужны?

судя по вопросам, то всех + лицензия на управление самолетом

Middle/Senior Frontend Developer
Databases

???

и что эту всю фигню реально спрашивают?

Только в представленной шлюпке. Если на галеру не можешь проникнуть, то и эта шлюпка сойдет на первое время.

По какому принципу вы отбирали вопросы?

кубернетес — будущее фронт-энда

а потім виходиш на роботу, і переписуєш реактік з чогось на хукі :D

Жить ,как говорится, хорошо)

Но чтобы попасть на работу на реакт с хуками — нужно от 3х лет опыта с реактом, и пофиг что он уже не тот

а поки довчишся, то реакт ще інший велосипед винайде і знову обнулить всі ці саспензи, рутери та інший бред 😅😅

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

Из моего опыта, первый фреймворк который я использовал (ember), потребовал день или два чтения документации чтобы начать писать рабочий код и пару недель практики чтобы чувствовать себя в этом всём комфортно. С реактом было примерно так же — 2 дня я плевался что всё не так, через неделю или две уже чувствовал себя комфортно и просто писал приложение. С expo +/- то же самое.

Но некоторые (многие, к сожалению) наниматели просто вот хотят эксперта с 3 годами опыта, и всё тут. И часто читаешь описание проекта — ну обычный CRUD же, да и реакт всё равно быстро меняется. Часто ситуация ещё хуже, когда просят обращаться только тех кто писал вот такое же точно приложение как надо заказчику или работал с той маленькой библиотекой, которую заказчик считает необходимым применить. И я просто ору в монитор «ну если ты не нашел готовых решений проблемы и тебе нужно что-то писать, то откуда найдутся программисты, которые точно такое уже писали?».

Или вот ещё с чего бомбит: «AWS experience». Не подымал (микро)сервисы на амазоне — свободен

оказується я фроент сійнор тоже

Ось ніби і список не поганий і є хороші питання, але поки читав, то відчув себе наче на екзамені де питають купу непотрібної фігні аби отримати оцінку або завалити, деякі питання просто не мають сенсу, деякі занадто прості і таке питати(особливо то міддл плюс), ну блін хз
Ну і якби мене по цьому всьому прогнали на співбесіді, то те що офігів би, то не те слово

Не хватает внезапных вопросов про докер и CI/CD

А ще про алгоритми, ноду, базові речі типу замикання, промісів, верски, хоча б основ дизайну, можна ще додати про побудову інфраструктури мікросервісів, ніби нічого не забув

Согласен, есть чем дополнять еще, думаю со временем расширю новыми темами.

За труд респект, сохранил себе, но некоторые вопросы, конечно, это просто жесть.
Во-первых, я не уверен, что среднестатистический фронтэнд синьор знает хотя бы половину понятий, перечисленных в разделе про ФП, его как будто заядлый хаскелист писал.
Во-вторых, вопросы типа «How does Rich Hickey in his report „Simple Made Easy“ describe the difference between Simple and Easy? Why in the first place is it striving for simplicity, and not for ease?» — ну серьёзно? Я бы охренел от так поставленного вопроса. Можно ещё вопрос «а о чем Макконнелл пишет на странице 477 второго издания книги «Совершенный код».

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

Почти к каждому вопросу вида «что такое .../ может ли.. / etc » можно создать issue. Потому что это вопрос на конкретное знание в конкретной формулировке. Такие вопросы на интервью — это полный провал интервью в принципе, потому как цель интервью вовсе не в ответе на них.

Не удалясь от FP: какова разница по-вашему мнению между вопросами «what are the monads?» и «how do you compose computations?»

Цель интервью, в котором фронтэндера спрашивают про модель OSI, CAP-теорему и «почему сокеты считаются абстрактными объектами» (что вообще?), может быть только одна — сбить рейты.

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

често, то не понимаю как оси модель кому-то может пригодится в наши дни. отличия удп от тсп — ок.

osi модель имхо, как и дизайн паттерны позволяют упростить коммуникацию в понятии стандартно принятых вещей, чтобы не говорить много слов а упомянуть четкий термин который подразумевает многое.
типа если реквест сорвался на хендшейке tls (сеансовый уровень, 5) то очевидно что http-реквеста мы не получаем потому что это происходит уровнем выше (7, уровень аппликейшена)
для кругозора это не будет лишним знать, хотя действительно детально знать модель osi не сетевикам может быть и не нужно
с другой стороны приятно работать и общаться с людьми которые оперируют проф терминологией, а не жуют сопли пол часа пытаясь объяснить ограниченным словарем простую вещь

Обычно говорят реквест не долетел до сервера — и всем все понятно

ага, а еще говорят «у меня ничего не работает, я тут что-то нажал и все пропало»
мы все еще про профессионалов говорим, или... слово «Senior» в названии топика ничего не значит?
хотя, простите что всунулся в сырную тусовку фронтэндеров со своими бековскими заморочками

Сеньор и задрот это разные люди.

Твой пример — это крайне не эффективная коммуникация, и как бы сеньоры, как никто другие должны уметь в абстракции в первую очередь, а знание какой-то конкретной лоу левел вещи это только для того чтобы писюнам мерятся, а не про сеньора.

с другой стороны приятно работать и общаться с людьми которые оперируют проф терминологией, а не жуют сопли пол часа

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

про модель OSI, CAP-теорему

фулстеки могут делать только круды, так и запишем =)

Во-первых, я не уверен, что среднестатистический фронтэнд синьор знает хотя бы половину понятий, перечисленных в разделе про ФП, его как будто заядлый хаскелист писал

Я вообще их не знаю и не понимаю зачем мне знать как по-научному называется функция, возвращающая функцию, например.

В ФП такая фишка, называть простые вещи новыми словами. Точнее, математическими терминами.

Можно ещё вопрос «а о чем Макконнелл пишет на странице 477 второго издания книги «Совершенный код».

youtu.be/xFxAsYVVN7A?t=46

Подписаться на комментарии