Видно, что у гостя большой опыт, при ответе на вопрос появляются бесконечные референсы на случаи из жизни. Иногда это бывает уместно, но в большинстве случаев уводит нить дискуссии от заданного вопроса в бесконечные дебри
классный чел, я бы с ним поработал бы. это интервью еще раз подтверждает, что senior разработчиков никто не спрашивает про this, closures и тд. С ними больше говорят про технологии, архитекруту и тд. но это нормально, что не каждый сразу может ответить на этоти вопросы. в реальности ты можешь месяцами разгребать кучу говна и даже сам не понимать, что это и были те самые замыкания. Спасибо за интервью.
вообще я не соглашусь что это нормально, ни кто не требует определений но на пальцах объяснить что такое замыкание, область видимости, контекст и т.д. это как отче наш, сеньор тем и отличается что с него просят не определения и понимание, чем увереннее ответы тем быстрее прекратят спрашивать
+1000 за внедрение в сложный проект сторибука с базовыми компонентами в различных состояниях. Когда сюда же добавляются куски интерфейса приложения, собранные из базовых компонент, и какие-то пользовательские истории, то ценность сторибука сложно переоценить.
Отлично видно что вопросы на синиора нынче проще чем вопросы на джуна.) Потому что мнение оно как говорится есть у каждого, а вот ты попробуй не нужных для работы энциклопедических фактов рассказать.
Скорее всего тут имелся ввиду "паттерн" когда мы передаём делегаты в конструктор. Это имеет особое название как например "вторичный конструктор" и т.д. Сложно вспомнить с ходу как это называется, но вроде не executor там точно название не в одно слово.
@@nikitaproit executor Объект функции с двумя аргументами resolve и reject. Функция executor получает оба аргумента и выполняется сразу, ещё до того как конструктор вернёт созданный объект. Первый аргумент (resolve) вызывает успешное исполнение промиса, второй (reject) отклоняет его. (C) MDN
Это не senior ни разу. Во-первых, он увиливает от вопросов, когда не знает ответа. Так делают только джуны. Во-вторых, он не может нормально излагать свои мысли. В-третьих, он не знает JS.
DI нужен не для того, чтобы независимо разрабатывать, а для того, чтобы подменять реализацию одну другой не меняя при этом код класса, который использует эту реализацию. Например, мокать при тестировании или передавать одну из двух реализаций какого-то сервиса. А то, что "единый контейнер - это плохо" - звучит как неправильный ответ. Он в 99% случаях один на весь проект и это хорошо. В т.ч. на джаве
Посвящается всем тем, кто говорит, что этот сеньор не знает чего-то, не может рассказать, увиливает от ответа и т.д. Водитель с 30-летним стажем не так хорошо знает и помнит ПДД, как только что сдавший на права первокурсник
Он так сказал потому что работает на реакте, а там с появлением хуков никто this не использует. Я сам не из реакт-групповухи, так что я поперхнулся когда это услышал))
Еще раз убеждаюсь, что вопросы, обсуждаемые на интервью, никак не раскрывают компетенцию человека. Задачи закрываются, код пишется. Всегда можно загуглить, если что-то забыл. Халевара на тысячу ебучих лет, у каждого свое мнение. По мне так идеальное сеньор интервью -- это попиздеть с кандидатом на тему любви к фронтенду и разобрать реальные кейсы из разработки
За последние два года прособеседовал больше сотни кандидатов на позицию scala разработчика (разных уровней). Перестал вообще удивляться современной индустрии разработки. В большей части люди подаются на вакансию даже не удосужившись прочитать полностью хотя бы одну книгу по языку, я уже не говорю про технологии инфраструктуры (БД, очередя, etc). Данный сеньор эталонен для современного IT.
Фигня, я сам в ит 2 года(фронт) начал в 31 до этого работал эникещиком 2 года. Не давно проходил совбес и там их тех лид путает область видимости функция и блочный) Мне пришлось Лив коде показать референс еррор. Считаю себя крепким джуном)
2:06:10 "Не абстрактный User, а конкретный UserVasya" в смысле, класс UserVasya? Или причём тут dependency inversion? Инверсия зависимости - это не про инстансы. Инверсия зависимости - это про программные модули (классы например). В этом смысле собеседуемый всё правильно рассказал. Хоть и многословно.
в tailwind классы которые заданы через @apply в конечной верстке отображаются нормально, со своим названием (не заменяются набором утилитарных классов tailwind)
Ну как раз проблема в том, что теряется киллер-фича тайлвинда - маленький размер css. @apply просто подставит стили в класс (да, там ещё магия layer есть, но это не суть).
Жесть какая-то, мужик в целом всё нормально отвечает, но вопросы задаются настолько кринжово и настолько не связано один с другим, что это просто ужас какой-то, соболезную челу, которого собеседовали. То у них вопрос про инкапсуляцию, которая на самом деле у них Single Responsibility Principle, потом этот S вдруг уже оказался DI и нет, даже не Inversion, а сразу реализация его в ангуляре в виде Dependency Injection, это просто какой-то сумбурный набор несвязанных друг с другом вещей, которые они спрашивают, как будто говорят до сих пор об инкапсуляции, как вообще можно так кринжово всё выкрутить? Это ужас какой-то. Не говоря уже о микротасках, которые "имеют самый низкий приоритет" (нет, макротаски имеют приоритет ниже). И прочем подобном.
у вас наверняка разговор проще пошел бы на тему стейт менеджеров если б кто-то из интервьюеров просто спросил - тыкал ли Александр swr библиотеки. это сравнительно новая штука (повторяю, сравнительно - для тех кто пилит продукт уже 5+ лет с редаксом могло пройти мимо, кто запускал проекты в последние года 2 - скорее всего встречали). если он таких библиотек не юзал и мимо как-то не попадалось - вполне резонно что стейт менеджер рулит серверным кешем - так в общем-то большинство людей и делали до swr подхода. мне показалось вы все друг друга на этом блоке как-то недопоняли
1:53:22 ну вот и правильно указал на ошибку, что это не сокрытие данных, так как сокрытие - это лишь то, что мы можем впоследствие сделать с данными (используя protected и private), которые уже инкапсулированы. Но вместо того, чтобы просто сказать, что это изоляция данных в конкретную сущность, начал затирать про S из SOLID, причём тут Single Responsibility? Если в классе будет куча методов с ним напрямую не связанных - эти методы всё равно будут инкапсулированы в этот класс, инкапсуляция от этого никак не зависит, это просто изоляция данных (и методов) в конкретной сущности, именно поэтому это и называется инкапсуляцией, если по-русски - заключать в капсулу, где капсулой является сущность (класс), в который мы методы и свойства как раз инкапсулируем. Причём тут вообще логгер и дебаггер (это про раздувание класса, то есть S, а не про инкапсуляцию), как можно собеседовать, если сам даже нормально сформулировать не можешь?
Пока самый сложный выпуск (посмотрел 10 и 14). Очень много примеров, и очень сложно держать это в голове. Порой примеров недостаточно бывает, здесь же каждый ответ рассматривается на долго описываемом примере. Но лайк все равно поставил )
Странно, что такому опытному разработчику задают джуновские вопросы.. Или меня испортили видео собесов Яндекса? Там без пары обходов графов не обходится.
Почему сеньор не подготовился к собесу? Хотелось бы услышать умные и глубокие ответы, чтобы узнать что-то новое, а не скипать плохие ответы. Всё-таки человек понимает, что собес на Ютуб идёт. Попросите людей лучше готовиться((((
Не согласен. В сторибуке можно создавать "маленькие кусочки" приложения и смотреть на них в разных состояниях. Пример: скелет приложения во время загрузки приложения. В "полном" приложении это состояния проскакивает за 1 секунду. Что-то менять в коде, что бы "задержать" это состояния не всегда удобно.
Как же у меня подгорает от адептов атомарного CSS.🤬 Складывается впечатление, что такие люди никогда нормально не верстали и в принципе не знают как это делается.
Какое-то балабольство, причем на фундаментальные вопросы этот бородач откровенно плавает. Вобщем очередной прокаченный софт скилл - прохождение собеседований. Шутеечки, истории из жизни, время проходит.
1:39:37 што. Микротаски вообще более приоритетны, чем макротаски. И выполняются они не первыми, а только после синхронного кода, максимально кринжовая формулировка. Просто разберём: 1. "Микротаски у них самый низкий приоритет" (нет) 2. "Они выполняются самыми первыми" (шта, из первого следует обратное, но они не первые, а после синхронного кода) 3. "Потому что выполняются в конце стека" (каком конце? это просто какое-то шизобезумие реально) Противоречие на противоречии. Последними выполняются макротаски. А первыми синхронный код, в видео сказана просто куча глупости по этому поводу.
Само собой в спецификации нет макротасок, так как там нет и микротасок и вообще всего событийного цикла, eventloop - это вопрос среды выполнения js, к спецификации это не имеет никакого отношения в принципе. Жаргонов тут никаких нет, это понятия в рамках выполнения eventloop в браузере, макротаски - это settimeout и setinterval, микротаски - вся остальная асинхронщина. Как из того, то eventloop нет в спецификации следует, что термины, которые вообще к спецификации отношения не имеют - жаргон? В чём вообще суть тезиса?@@onet1589
@@serafim2885 Боже, спасибо тебе большое, теперь я во всём разобрался! Мб не достаточно детально, но с головой хватит для того, что бы уверенно рассказывать об этом на собесе)
инкапсуляция подразумевает собой "скрытие" реализации, а не информации, за которое зацепились интервьюеры и прервали человека. Не факт, что собеседуемый бы, конечно, сказал про это. Все таки с классическим ООП он кажется работал не много. Скрытие реализации - это про то, что экземпляр класса сам должен следить за своим состоянием и поддерживать его в валидном состоянии. Например, существует проблема связных полей, когда ты не можешь обновить свойство А, не обновив свойство В. На примере треугольника - если у нас есть 3 сеттера (А, В, С) - возможна ситауция, когда устанавливая из внешнего мира А - треугольник перестает существовать. Даже если мы напишем t.A = 3, t.B=4, t.C=5 - вроде бы мы быстро заменили поля, но это нарушение. 1 - мы можем поменять не три стороны, а одну; 2 - какой-нибудь процесс/поток может вмешаться и оспользоваться не валидным объектом. Решение - не предоставлять сеттеры для А, В, С и сделать метод setABC (setTriangle). DI - как способ решения некоторой проблемы. По сути это паттер проектирования (под капотом - фабрика фабрик) ну а остальное - что-то интересно, что-то видно большой опыт. А что-то - не плохо было бы повторить, почитать еще книжек;) по подписчики сами хотели "синьора+замыкания") За собеседование плюс!
Крутой парень. Хороший пример про переменные с атомиком. Ещё есть пример с адаптивом, потому что медиа часто зависят от конкретного компонента конкретной страницы и не должны быть в дизайн системе. Интересно даже посмотреть как Александр реализует логику без js классов или их аналогов и почему.
@@kawaikaino5277 Дак он вроде только про инкапсуляцию что-то напутал...но там же норм рассказал про каплинг. Но согласен, иногда уходил от некоторых вопросов совсем в другую сторону
сорри за токсичность, но чет ору на секции про стейт-менеджмент. Наконец-то во фронте настала эпоха изобретения велосипедов, выстрелов себе в ноги, наступания на грабли и прочих приключений, через которые уже прошли 20 лет назад в бэке и десктопе, и 10 лет назад в мобильной разработке (последние два по сути тоже фронтэнд). Автор МобХ отделил модель от вьюшки! Вот это да! Лет через 5 научатся отделять бизнес-логику от юзкейсов и инфраструктуры, нарезать все это на контексты и кидать эвенты между ними, а лет через 10 седой Дядюшка Дэн Велосипедович Абрамов напишет свою "Чистую архитектуру". Самое интересное, что многое из этого уже есть в Ангуляре
Единственное я не понял зачем он такие вроде бы очевидные вещи пересказывает как напрмер как работают css modules или про state managment , где сетевой запрос надо выполнять, он очень много воды льет, мне кажется это лишнее, но в целом спасибо!
@@leaf5960 не всякий di позволяет делать ioc, и обратное тоже верно. Вы можете имея 2 класса передать один в конструктор другого и это уже будет внедрением зависимостей. Но если вы создадите интерфейс в контексте принимающего класса и используете его как тип параметра - вы сделаете инверсию зависимостей. Дальше можно не продолжать, как видите ангуляр не справился уже на втором шаге.
Честно, хотел бы увидеть чтобы на собеседование к этим ребятам попал кто-то из разработчиков движка V8 и опустил их так, чтобы они поняли что во многих моментах они не правы и нефиг строить из себя великих умников.
Что-то душно и бесполезно для подготовки. Лучше смотреть не философские рассуждения без чёткого ответа, а четкие правильные ответы, которые хочет услышать работодатель. Пока слушала dependency inversion чуть не уснула, лучше про это у Непомнящих. То как человек выражает свои мысли, отражает то, как он мыслит. Здесь четкости нет. Значит и голове каша
Не понял кого как зовут, но чел в левом верхнем углу не знает что значит «семантика» и что она бывает не только в HTML, понятие из лингвистики вообще. Кандидату респект за кругозор.
блин слушаю секцию про стейт менеджер и удивляюсь, почему так топит за нее разработчик а потом прочитал что он из мейла и вопросы отпали у них там вообще все на стейтах
Собеседующий сам что-то своё выдумывает про инкапсуляцию. Во-первый, инкапсуляция это всегда про сокрытие. Инкапсулировать даже переводится как скрывать. Объединение данных и методов это тоже сокрытие этого всего от остального кода. Про сокрытие деталей реализации от пользователя, чтобы пользователь не мог никак (через публичную переменную) в обход поменять класс. Пример инкапсуляции -это объявление интерфейса доступного всем и реализации этого интерфейса, его деталей, доступные же классу - инкапсуляция логики. И если ты работаешь через интерфейс, то у тебя не будет лишнего метода или доступа полям, которые можно подправить в обход методов интерфейса. Проблема уменьшения внешних связностей (low coupling - именно так переводится на русский язык) это лишь следствие, результат, вытекающий из принципа инкапсуляции. Во-вторых, то что интервьюер начал говорить про класс чтение книжек, в котором не должен лежать дебаггер или логгер это вообще про нарушение SRP.
Может сначала переведёшь слово encapsulate в переводчике? Инкапсуляция к сокрытию сама по себе отношения не имеет. Инкапсуляция - про изоляцию данных, а не про сокрытие данных.
![[ПЕРЕЗАЛИВ] Собеседование в Альфа-банк Senior frontend-разработчиком с ЗП 170к](http://i.ytimg.com/vi/srpXEgvIzoQ/mqdefault.jpg)
Владислав и Станислав отсобеседуйте друг-друга на разных уровнях, а мы слушатели, ума наберёмся.
Полученное видео выгрузите на порнхаб
Сразу на замыкания перемотал 😂
Аналогично ))) Ахахахаха )))
Аналогично😂
джун спалился
Ничесе. Фред Дерст проходит собеседование.
Мне показалось или интервьюируемый это Senior в технологии уходить от прямого ответа.))))
Видно, что у гостя большой опыт, при ответе на вопрос появляются бесконечные референсы на случаи из жизни. Иногда это бывает уместно, но в большинстве случаев уводит нить дискуссии от заданного вопроса в бесконечные дебри
@@MoreArrowsInTheKnee так и есть. Сам собеседую людей и большинство кандидатов уходят в какие-то дебри, если не знают ответа
+, тоже заметил, воды льет люто, хотя ответ можно в 1-2 предложения уместить
зашел послушать, что сениоры говорят о контексте и замыкании очень удивился 😀
классный чел, я бы с ним поработал бы.
это интервью еще раз подтверждает, что senior разработчиков никто не спрашивает про this, closures и тд. С ними больше говорят про технологии, архитекруту и тд.
но это нормально, что не каждый сразу может ответить на этоти вопросы.
в реальности ты можешь месяцами разгребать кучу говна и даже сам не понимать, что это и были те самые замыкания.
Спасибо за интервью.
вообще я не соглашусь что это нормально, ни кто не требует определений но на пальцах объяснить что такое замыкание, область видимости, контекст и т.д. это как отче наш, сеньор тем и отличается что с него просят не определения и понимание, чем увереннее ответы тем быстрее прекратят спрашивать
неудачный ты пример привёл с замыканиями. это же основа основ в js
Грош цена такому синьёру, который не знает подобных вещей.
на реальных собесах в снг компании будут больше спрашивать менеджерские вопросы
К сожалению, создалось впечатление, что ребята общались на разных языках
Спасибо причастным за шикарный материал! Круто!
вообще круто!!! красавцы!)
а можно на монтаже выровнять громкость спикеров и интервьюируемого? Спасибо
Особенно актуально это написать в комментах уже выложенного выпуска.
@@M615243 это замечание для следующих выпусков...и как ты себе представляешь просьбы до выложенного выпуска?
Какой-то монолог собеседующего, а не интервью)
С вопроса уходит в другую локацию просто, приходится возвращать его)
+1000 за внедрение в сложный проект сторибука с базовыми компонентами в различных состояниях. Когда сюда же добавляются куски интерфейса приложения, собранные из базовых компонент, и какие-то пользовательские истории, то ценность сторибука сложно переоценить.
Благодарю. Реально интересно посмотреть на такое интервью
Отлично видно что вопросы на синиора нынче проще чем вопросы на джуна.)
Потому что мнение оно как говорится есть у каждого, а вот ты попробуй не нужных для работы энциклопедических фактов рассказать.
Мужик дело говорит. Странно, что с ним не могут согласиться
1:44:57 ребят, ну зачем так душнить 😑 функцию зовут исполнитель, aka executor, а он уже принимает два коллбека
После этого момента стал сразу искать в комментариях тех кто тоже на это обратил внимание, зато сколько гонора "может все таки коллбэк"
Скорее всего тут имелся ввиду "паттерн" когда мы передаём делегаты в конструктор. Это имеет особое название как например "вторичный конструктор" и т.д. Сложно вспомнить с ходу как это называется, но вроде не executor там точно название не в одно слово.
@@nikitaproit
executor
Объект функции с двумя аргументами resolve и reject. Функция executor получает оба аргумента и выполняется сразу, ещё до того как конструктор вернёт созданный объект. Первый аргумент (resolve) вызывает успешное исполнение промиса, второй (reject) отклоняет его. (C) MDN
Это не senior ни разу.
Во-первых, он увиливает от вопросов, когда не знает ответа. Так делают только джуны.
Во-вторых, он не может нормально излагать свои мысли.
В-третьих, он не знает JS.
Не путайте инженера с энциклопедией)
Каким макаром зацепление и связывание относится к инкапсуляции? Это больше про солид, но уж точно не про инкапсуляцию.
А если точнее то даже не по солид а по грасп
Спасибо, звучит интересно
Но в css модулях можно оставить названия классов, просто добавить хэши к именам для изоляции
мы так обычно и делаем :)
Про стейт менеджер нужно было не начинать отвечать, а задать встречный вопрос:
"Дайте определение стейт менеджеру и поговорим, от том нужен ли он😉"
С кирой было на много интереснее и познавательней) Александр расплывается частенько, и уходит в сторону
Поставил лайк Александру за его бороду!
Спасибо )
отличная дискуссия )
> если вы используете this, то в какой-то момент вы свернули не туда.
В это время я, пишущий тысячу this в день на vue, 🤔
Представь ещё, каково ангулярщикам
Очень растекается по дереву senior, слушать тяжело
Почему?
DI нужен не для того, чтобы независимо разрабатывать, а для того, чтобы подменять реализацию одну другой не меняя при этом код класса, который использует эту реализацию. Например, мокать при тестировании или передавать одну из двух реализаций какого-то сервиса. А то, что "единый контейнер - это плохо" - звучит как неправильный ответ. Он в 99% случаях один на весь проект и это хорошо. В т.ч. на джаве
Посвящается всем тем, кто говорит, что этот сеньор не знает чего-то, не может рассказать, увиливает от ответа и т.д. Водитель с 30-летним стажем не так хорошо знает и помнит ПДД, как только что сдавший на права первокурсник
1:22:57 "если вы используете _this_ в коде, значит вы свернули где-то не туда"
Т.е. мне предлагается все методы и поля класса делать статическими? :)
скорей имелось ввиду явная работа с this -> bind/apply/call
Он так сказал потому что работает на реакте, а там с появлением хуков никто this не использует. Я сам не из реакт-групповухи, так что я поперхнулся когда это услышал))
Да в реакт вам не нужен this м отпадают проблеми с контекстом
Наверно это тонкий намек на то, что this может пораждать много путанницы и проблем, даже у тех, кто в нем разбирается, или думает, что разбирается.
@@luckyman5983 это тонкий намек на то, что ты не работаешь в ООП парадигме. :)
Еще раз убеждаюсь, что вопросы, обсуждаемые на интервью, никак не раскрывают компетенцию человека.
Задачи закрываются, код пишется. Всегда можно загуглить, если что-то забыл. Халевара на тысячу ебучих лет, у каждого свое мнение.
По мне так идеальное сеньор интервью -- это попиздеть с кандидатом на тему любви к фронтенду и разобрать реальные кейсы из разработки
За последние два года прособеседовал больше сотни кандидатов на позицию scala разработчика (разных уровней).
Перестал вообще удивляться современной индустрии разработки. В большей части люди подаются на вакансию даже не удосужившись прочитать полностью хотя бы одну книгу по языку, я уже не говорю про технологии инфраструктуры (БД, очередя, etc).
Данный сеньор эталонен для современного IT.
Вы просто душнилы
Фигня, я сам в ит 2 года(фронт) начал в 31 до этого работал эникещиком 2 года. Не давно проходил совбес и там их тех лид путает область видимости функция и блочный) Мне пришлось Лив коде показать референс еррор. Считаю себя крепким джуном)
2:06:10
"Не абстрактный User, а конкретный UserVasya"
в смысле, класс UserVasya?
Или причём тут dependency inversion?
Инверсия зависимости - это не про инстансы.
Инверсия зависимости - это про программные модули (классы например).
В этом смысле собеседуемый всё правильно рассказал. Хоть и многословно.
"Про О-что?" - проорал xDD
Это же Флокки
Вообще понравилось. Был бы не подписан, подписался бы сейчас.
в tailwind классы которые заданы через @apply в конечной верстке отображаются нормально, со своим названием (не заменяются набором утилитарных классов tailwind)
Ну как раз проблема в том, что теряется киллер-фича тайлвинда - маленький размер css. @apply просто подставит стили в класс (да, там ещё магия layer есть, но это не суть).
2:08:42 «Во фронте менять нечего» АХАХАХАХАХАХАХАХАХАХАХАХАХА то есть мяу
Жесть какая-то, мужик в целом всё нормально отвечает, но вопросы задаются настолько кринжово и настолько не связано один с другим, что это просто ужас какой-то, соболезную челу, которого собеседовали.
То у них вопрос про инкапсуляцию, которая на самом деле у них Single Responsibility Principle, потом этот S вдруг уже оказался DI и нет, даже не Inversion, а сразу реализация его в ангуляре в виде Dependency Injection, это просто какой-то сумбурный набор несвязанных друг с другом вещей, которые они спрашивают, как будто говорят до сих пор об инкапсуляции, как вообще можно так кринжово всё выкрутить? Это ужас какой-то.
Не говоря уже о микротасках, которые "имеют самый низкий приоритет" (нет, макротаски имеют приоритет ниже). И прочем подобном.
Даже на х 2 местами паузы и вода от синьора усложняли восприятие. Хочешь быть синьором - везде ссылайся на RX js. Гы)))
у вас наверняка разговор проще пошел бы на тему стейт менеджеров если б кто-то из интервьюеров просто спросил - тыкал ли Александр swr библиотеки. это сравнительно новая штука (повторяю, сравнительно - для тех кто пилит продукт уже 5+ лет с редаксом могло пройти мимо, кто запускал проекты в последние года 2 - скорее всего встречали). если он таких библиотек не юзал и мимо как-то не попадалось - вполне резонно что стейт менеджер рулит серверным кешем - так в общем-то большинство людей и делали до swr подхода. мне показалось вы все друг друга на этом блоке как-то недопоняли
Когда путаешь Inversion и Injection (тут на вас Java разрабов не хватает). Iverision - это про D из SOLID. IoC это к Injection.
1:53:22 ну вот и правильно указал на ошибку, что это не сокрытие данных, так как сокрытие - это лишь то, что мы можем впоследствие сделать с данными (используя protected и private), которые уже инкапсулированы. Но вместо того, чтобы просто сказать, что это изоляция данных в конкретную сущность, начал затирать про S из SOLID, причём тут Single Responsibility?
Если в классе будет куча методов с ним напрямую не связанных - эти методы всё равно будут инкапсулированы в этот класс, инкапсуляция от этого никак не зависит, это просто изоляция данных (и методов) в конкретной сущности, именно поэтому это и называется инкапсуляцией, если по-русски - заключать в капсулу, где капсулой является сущность (класс), в который мы методы и свойства как раз инкапсулируем.
Причём тут вообще логгер и дебаггер (это про раздувание класса, то есть S, а не про инкапсуляцию), как можно собеседовать, если сам даже нормально сформулировать не можешь?
Пока самый сложный выпуск (посмотрел 10 и 14). Очень много примеров, и очень сложно держать это в голове. Порой примеров недостаточно бывает, здесь же каждый ответ рассматривается на долго описываемом примере.
Но лайк все равно поставил )
Здравствуйте, я отправлял форму, но вы со мной так и не связывались, могу узнать причину?
не одному тебе
Думаю в порядке очереди ну и выбирают самых интересных - долго можно ждать)
Имхо Кандидат засиньорил чела в левом углу. Про правого не могу сказать - мало вопросов задавал
Ребята, а как можно попасть к вам на собеседование?
щас будет жарко)
сеньёр спустя 5 лет работы на 1 месте
Странно, что такому опытному разработчику задают джуновские вопросы.. Или меня испортили видео собесов Яндекса? Там без пары обходов графов не обходится.
В небольших конторах такие вопросы и задают, т.к. задающие такого же уровня
Давайте Джуниоров обратно
ни в коем случае)
@@MrNeosporim джунов не интерестно, одни и те же вопросы.
классно смотреть/слушать аргументированный спор! имхо в собеседовании синьора это самое интересное.
вы не могли бы снова с крепкими мидлами делать собеседование? джунов и мидлов интересно слушать
❤
Почему сеньор не подготовился к собесу? Хотелось бы услышать умные и глубокие ответы, чтобы узнать что-то новое, а не скипать плохие ответы. Всё-таки человек понимает, что собес на Ютуб идёт. Попросите людей лучше готовиться((((
Потому что смысл показать что синьёр думает о таких вопросах. Очень показательно 😂
Если есть готовая библиотека компонентов тогда сторибук не нужен я полагаю
Не согласен. В сторибуке можно создавать "маленькие кусочки" приложения и смотреть на них в разных состояниях. Пример: скелет приложения во время загрузки приложения. В "полном" приложении это состояния проскакивает за 1 секунду. Что-то менять в коде, что бы "задержать" это состояния не всегда удобно.
@@AlexandrShushunov то есть получается сторибук это прослойка между ui kit и приложением ?
@@kirillpavlovskii8342 это скорее песочница, где можно работать с частями приложения. 'Мыть слона по частям'
Как же у меня подгорает от адептов атомарного CSS.🤬
Складывается впечатление, что такие люди никогда нормально не верстали и в принципе не знают как это делается.
Ну что вы за люди такие, даже бородатого сеньора запарили со своими замыканиями)
Какое-то балабольство, причем на фундаментальные вопросы этот бородач откровенно плавает. Вобщем очередной прокаченный софт скилл - прохождение собеседований. Шутеечки, истории из жизни, время проходит.
1:39:37 што. Микротаски вообще более приоритетны, чем макротаски. И выполняются они не первыми, а только после синхронного кода, максимально кринжовая формулировка.
Просто разберём:
1. "Микротаски у них самый низкий приоритет" (нет)
2. "Они выполняются самыми первыми" (шта, из первого следует обратное, но они не первые, а после синхронного кода)
3. "Потому что выполняются в конце стека" (каком конце? это просто какое-то шизобезумие реально)
Противоречие на противоречии.
Последними выполняются макротаски. А первыми синхронный код, в видео сказана просто куча глупости по этому поводу.
примерно так, но термино МАКРОтаски в спецификации нет, это жаргон и надо избавляться от него
Само собой в спецификации нет макротасок, так как там нет и микротасок и вообще всего событийного цикла, eventloop - это вопрос среды выполнения js, к спецификации это не имеет никакого отношения в принципе.
Жаргонов тут никаких нет, это понятия в рамках выполнения eventloop в браузере, макротаски - это settimeout и setinterval, микротаски - вся остальная асинхронщина.
Как из того, то eventloop нет в спецификации следует, что термины, которые вообще к спецификации отношения не имеют - жаргон? В чём вообще суть тезиса?@@onet1589
За луп эвент опять же не пояснили
Заезжает как-то фронтенд на тюрьму, а ему братва с порога- за ивент луп поясни, фраер
ua-cam.com/video/8aGhZQkoFbQ/v-deo.html
@@serafim2885 Боже, спасибо тебе большое, теперь я во всём разобрался! Мб не достаточно детально, но с головой хватит для того, что бы уверенно рассказывать об этом на собесе)
@@serafim2885 это стоит отправить в закреп
Когда дело доходит про стейт менеджер, тут очевидно эффектор
боже, да я походу сеньор. Хотя в принципе для восьми лет опыта походу пора - я себя явно недооценивал
инкапсуляция подразумевает собой "скрытие" реализации, а не информации, за которое зацепились интервьюеры и прервали человека. Не факт, что собеседуемый бы, конечно, сказал про это. Все таки с классическим ООП он кажется работал не много.
Скрытие реализации - это про то, что экземпляр класса сам должен следить за своим состоянием и поддерживать его в валидном состоянии. Например, существует проблема связных полей, когда ты не можешь обновить свойство А, не обновив свойство В.
На примере треугольника - если у нас есть 3 сеттера (А, В, С) - возможна ситауция, когда устанавливая из внешнего мира А - треугольник перестает существовать. Даже если мы напишем t.A = 3, t.B=4, t.C=5 - вроде бы мы быстро заменили поля, но это нарушение. 1 - мы можем поменять не три стороны, а одну; 2 - какой-нибудь процесс/поток может вмешаться и оспользоваться не валидным объектом. Решение - не предоставлять сеттеры для А, В, С и сделать метод setABC (setTriangle).
DI - как способ решения некоторой проблемы. По сути это паттер проектирования (под капотом - фабрика фабрик)
ну а остальное - что-то интересно, что-то видно большой опыт. А что-то - не плохо было бы повторить, почитать еще книжек;) по подписчики сами хотели "синьора+замыкания")
За собеседование плюс!
Senior в непонимании что такое контекст 🤦♂️
Еще говорит ООП используется для сокрытия информации 😐😐😐
Если закрыть глаза то интервью берут у математика саватеева
почему не было вопроса про переменные, Senior их нужно тоже задавать)))
Вы про какие именно var let const ? Они же по разному себя ведут ))) вам как из приготовить в режиме 2000 годов ? В голове включить Бабель
Сами не объяснили зачем стейт менеджер
Крутой парень. Хороший пример про переменные с атомиком. Ещё есть пример с адаптивом, потому что медиа часто зависят от конкретного компонента конкретной страницы и не должны быть в дизайн системе.
Интересно даже посмотреть как Александр реализует логику без js классов или их аналогов и почему.
Классный выпуск!
Правда было ощущение что нахожусь не на интервью, а слушаю доклад о JS 😁
от кого?... Сеньер по моему слился
@@kawaikaino5277 Дак он вроде только про инкапсуляцию что-то напутал...но там же норм рассказал про каплинг.
Но согласен, иногда уходил от некоторых вопросов совсем в другую сторону
Для джуна труднова-то вникнуть)
сорри за токсичность, но чет ору на секции про стейт-менеджмент. Наконец-то во фронте настала эпоха изобретения велосипедов, выстрелов себе в ноги, наступания на грабли и прочих приключений, через которые уже прошли 20 лет назад в бэке и десктопе, и 10 лет назад в мобильной разработке (последние два по сути тоже фронтэнд). Автор МобХ отделил модель от вьюшки! Вот это да! Лет через 5 научатся отделять бизнес-логику от юзкейсов и инфраструктуры, нарезать все это на контексты и кидать эвенты между ними, а лет через 10 седой Дядюшка Дэн Велосипедович Абрамов напишет свою "Чистую архитектуру". Самое интересное, что многое из этого уже есть в Ангуляре
Единственное я не понял зачем он такие вроде бы очевидные вещи пересказывает как напрмер как работают css modules или про state managment , где сетевой запрос надо выполнять, он очень много воды льет, мне кажется это лишнее, но в целом спасибо!
В ангуляре DI без IoC. По крайней мере точно был до 5 версии, если не считать токены IoC, но это сомнительно.
что значит di без ioc? Насколько я знаю di - это реализация ioc
@@leaf5960 не всякий di позволяет делать ioc, и обратное тоже верно. Вы можете имея 2 класса передать один в конструктор другого и это уже будет внедрением зависимостей. Но если вы создадите интерфейс в контексте принимающего класса и используете его как тип параметра - вы сделаете инверсию зависимостей. Дальше можно не продолжать, как видите ангуляр не справился уже на втором шаге.
сейчас фраза "ушёл на фронт" звучит уже совсем не забавно
Честно, хотел бы увидеть чтобы на собеседование к этим ребятам попал кто-то из разработчиков движка V8 и опустил их так, чтобы они поняли что во многих моментах они не правы и нефиг строить из себя великих умников.
Конечно совсем не конструктивно, хотелось услышать какие-то "мудрости" по "простых" вопросах, по замыканию, ООП...
На собеседовании был очень далекий от JS человек =)
мда.. оказывается, синьор это тот, кто может просто бла-бла-бла с такими же любителями побалаболить...
Чувак в желтой рубашке слишком серьезен для мок собеса
классный спич
лучше бы 2-3 месяца назад интервью брали, а то чувак мало знает
Что-то душно и бесполезно для подготовки. Лучше смотреть не философские рассуждения без чёткого ответа, а четкие правильные ответы, которые хочет услышать работодатель. Пока слушала dependency inversion чуть не уснула, лучше про это у Непомнящих. То как человек выражает свои мысли, отражает то, как он мыслит. Здесь четкости нет. Значит и голове каша
1:44:50 - резолвер промиса ))
Не понял кого как зовут, но чел в левом верхнем углу не знает что значит «семантика» и что она бывает не только в HTML, понятие из лингвистики вообще. Кандидату респект за кругозор.
блин
слушаю секцию про стейт менеджер и удивляюсь, почему так топит за нее разработчик
а потом прочитал что он из мейла и вопросы отпали
у них там вообще все на стейтах
this что ли? 🤣
Про ди и иок вообще желе
два с половиной часа чуши. зачем вы это выложили?
Собеседующий сам что-то своё выдумывает про инкапсуляцию. Во-первый, инкапсуляция это всегда про сокрытие. Инкапсулировать даже переводится как скрывать. Объединение данных и методов это тоже сокрытие этого всего от остального кода. Про сокрытие деталей реализации от пользователя, чтобы пользователь не мог никак (через публичную переменную) в обход поменять класс. Пример инкапсуляции -это объявление интерфейса доступного всем и реализации этого интерфейса, его деталей, доступные же классу - инкапсуляция логики. И если ты работаешь через интерфейс, то у тебя не будет лишнего метода или доступа полям, которые можно подправить в обход методов интерфейса. Проблема уменьшения внешних связностей (low coupling - именно так переводится на русский язык) это лишь следствие, результат, вытекающий из принципа инкапсуляции. Во-вторых, то что интервьюер начал говорить про класс чтение книжек, в котором не должен лежать дебаггер или логгер это вообще про нарушение SRP.
Может сначала переведёшь слово encapsulate в переводчике? Инкапсуляция к сокрытию сама по себе отношения не имеет. Инкапсуляция - про изоляцию данных, а не про сокрытие данных.
Кбанутся что такое замыкание?
не ожидал
что такой бородачь такое будет говорить(
Парень красавчик, но все это походит на один большой холивар.
чего такие пресные, интервьюеры?
1:43:09 господи вы МНОГОСТРОЧНУЮ анонимную функцию написали в ОДНУ строку, какой же говнокод вы пишете на своих проектах я представить не могу...
Понятно то что ниче не понятно
+
Чушь от автора про семантику
Слишком много воды льёт )
чел в рубашке токсик
фрэймвёрк 🤮