назовите все примитивные типы в Java, какие методы класса Object
перечислить что-то - только кажется простым вопросом от того, что не взято в расчёт, что у людей ассоциативная память. На самом деле подобные вопросы, если их не вызубрить перед интервью, могут застать врасплох любого сеньора. Если же вместо этого дать список методов и предложить рассказать их назначение, то на вопрос в таком формате ответит намного больше кандидатов.
Такой роли у меня не было. Бывало пару раз, что на масштабный рефакторинг выделяли месяц-два.
Архитектурные навыки я неплохо прокачал другим способом. И итак нарефачился за свою жизнь) В одном проекте кто-то ключевой функционал сделал одной функцией на 800+ строк, плюс хватало проблем и в других местах. В другом - реакт с ангуляром вместе использовался и потом это переписывали на es6 и попутно избавлялись от angular. В третьем - с jquery на react переписывали.
Спасибо за совет! Вот некий редактор и был единственным интересным веб проектом. Жаль, что там был слишком плохой код и я не стал там задерживаться. А так, больше половины моих проектов - админки.
Тут еще момент, что с React почти везде используется Redux (в 2gis тоже) со своим зоопарком технологий, а мне он никогда не нравился. Не горю желанием тратить время на технологию, которая мне не интересна, диктует мне свою архитектуру, и без которой получается делать проще и быстрее.
Мои проекты чаще всего очень сложные и такие люди без основ будут отнимать у меня много времени.
Мне было бы интересно услышать о ваших проектах и/или в чем их сложность? Как и где искать такие проекты и как туда попасть?) Я понимаю, что есть сложные проекты, но я за почти 10 лет работы веб-разработчиком только один свой проект могу назвать сложным. В других если и была сложность, то только по причине большего количества спагетти кода на момент моего прихода. Собеседования были гораздо сложнее, чем сами проекты.
Мне присылали решения, где человек руками писал EventEmmiter и строил вокруг него свой микро-фреймворк. Не трудно догадаться, что к такому кандидату особо пристальный интерес.
Я когда-то писал стейт-менеджер и успешно использовал его в парочке проектов, да и другие вещи писал. Но вот в тестовом не стал бы использовать (хотя сейчас и на тестовое не стал бы тратить время). В мире, в котором я живу, использование самописных решений вместо популярных готовых считается признаком неопытности.
И предыдущая команда в сторах хранила не только данные а и всю бизнес логику. Приложение было очень связанным и в итоге сторы уже включали часть логики других сторов.
Почему-то не получилось добавить коммент к вашему видео. В общем, если интересно, можете взглянуть на пару последних моих статей на хабре. Использую небольшие сторы только для данных и работой с этими данными (чтение/запись). Поток данных как в redux, но нет этих избыточных actions и dispatch. Пришел к такой архитектуре до того, как стал использовать Mobx, но она хорошо применима к нему и не только.
Ну а так, согласен, что из-за отсутствия best practices у большинства получаются раздутые сторы с хаотичными связями и потоком данных.
Ребята из команды начали активно продвигать идею использовать активно подписки, чтобы реагировать на все. В итоге, опять вышла потеря контроля, над тем в каком порядке код выполняется. И зачастую выполняется лишний код, который в такой ситуации не нужно реагировать.
Не понял про идею, но по-моему, сейчас это стандартная ситуация практически на любом проекте с хуками) Обязательно в проекте присутствуют компоненты с несколькими хуками, у которых по несколько переменных в массиве зависимостей. И получается, что компонент зависит от нескольких десятков переменных. Ну и обычное дело, когда при вводе в input обновляется вся форма.
Ну, если не говорить про реакт и пойти, например, в сторону игр (я их когда-то разрабатывал), то многие большие игровые проекты успешно пишутся на классах. Как бы, проблема, которая недавно решена с помощью функциональных компонентов с хуками, уже лет 20-30 как решена на классах в геймдеве.
В случае классов можно не городить кучу оберток с помощью декораторов (HOC), а выносить логику из компонента в другие классы/объекты или функции, а также воспользоваться другими паттернами композиции, например стратегией. Если интересно, можете почитать о различных подходах в моей статье: https://habr.com/ru/post/545368/
Вы, как и я, фронтенд разработчик. Можете привести пример, что бы вы ответили на этот вопрос? Я не работал в каких-либо крутых компаниях. В обычных средненьких компаниях над обычными проектами. За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутые, отфильтровать их по крутости и сформулировать, что и как я там делал несколько лет назад. Да и язык у меня не подвешен. Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам. А ведь потом еще надо решить простую задачу, и ответить на вопросы по теории, что опять же не сделаю без подготовки.
Я тоже к ним хотел, пока не побывал на собеседовании. Из примерно 15 компаний, где я проходил собеседования, у них были самые сложные задачи на алгоритмическом интервью. А первый же этап целиком состоял из решения задач. На мой взгляд, такой формат подходит, чтобы нанимать потенциально хороших разрабов среди студентов и джунов, т.к. большинство хороших и опытных фронтендеров не пройдут, т.к. слишком редко подобным занимаются. А тек кто пройдут, получат от других предложения с большей ставкой. Когда в компании был другой формат найма, они может и наняли хороших спецов, но боюсь, что если бы устроился к ним, то у меня был бы лид где-то с 3-мя годами опыта, которого мне бы пришлось учить писать простой и понятный код, а не сложный и супероптимальный с горой велосипедов.
Провайдер контекста должен размещаться максимально близко к компонентам, потребляющим контекст. Это называется коллокацией (collocation) или размещением совместного состояния.
На первый взгляд кажется правильный утверждением. Но данные одной страницы со временем понадобятся в другой. То есть при усложнении приложения потребуется либо переносить провайдер контекста выше, либо передавать данные в контекст, который не меняется при переходе на другую страницу. Мой опыт показывает мне, что обычно контекст лучше располагать до компонента, отвечающего за роутинг.
Если "разнести" сеттеры, геттеры и экшены по отдельным файлам.
Не советую так делать, так как нарушается High Cohesion. В wiki хорошо написано, к каким проблемам это ведет. Как я уже неоднократно писал, в первую очередь стоит рассматривать разделение по функционалу, а только потом по типам. Если стараться применять это с принципом SRP, то со временем увидите, что:
функционал фильтрации примерно одинаков у всех сторов и его можно вынести отдельно, написав только одну реализация
Во многих случаях сторы отличаются в основном только данными, а большая часть их функций одинаковая. То есть общую часть можно вынести и добавлять при создании экземпляра стора.
То есть в простых случаях создание стора может быть таким:
Они все 12 за 4 часа успевали сделать или только обязательные 3?)
gwg605 верно написал. Вашим сеньорам уже понятно, что от них ожидают и им не надо тратить время на раздумье над этим и на улучшение качества решения.
Второй момент, ваши сеньоры возможно набили руки именно на таких задачах. Дать им не привычные для них задачи и сроки сильно увеличатся. Как однажды сказал мой знакомый: "Если пишут 3-4 часа, это значит, что сделать второй раз такое-же задание займет у тебя 3-4 часа. А вот первый раз можно делать неделю :)"
Хотя толковый сениор решает все задачи этого тестового за 4 часа, не больше.
Толковый сеньор в большинстве случаев не будет тратить время на тестовые задания, а будет выбирать среди тех компаний, где процесс найма не предполагает большой траты его личного времени. Ибо хороших предложений много и ему не выгодно тратить много времени на каждую компанию.
Не верится про 4 часа. Но я сужу с позиции программиста. Среди программистов подобные оценки - это показатель неопытности. Специалисты с небольшим опытом не учитывают многие нюансы, не видят подводных камней и часто переоценивает свои силы. Специалисты же, набившие немало шишек, уже более осторожны в оценке.
Поэтому частенько мне начинающие ГД жалуются, что задание отнимает у них очень много времени.
Думаю, те из них, кто жалуется до начала работы над заданием и отказываются от него, это как раз опытные ГД. А начинающие фигачат день и ночь, а потом, чтобы показать себя с лучшей стороны, говорят, что делали это всего несколько вечеров, уделяя по паре часов.
Поучительная статья для тех, кто оценивает в несколько часов или дней задания, которые на самом деле делать недели, а то и месяц-два - https://habr.com/ru/post/567014/
Я не говорю что он плох. Но он известней любого, гораздо более опытного фронтенд разработчика. Тогда он явно не был разработчиком, к которому стоило прислушиваться всему react сообществу, особенно в плане архитектуры. Я не работал с ним и не слежу за ним, поэтому не знаю в чем и насколько он хорош, но думаю, когда его нанимали, он был на уровне обычного миддла. Ну и поработав несколько лет в Фейсбук, он конечно стал гораздо более хорошим разработчиком, чем раньше.
А почему доля того же blazor намного меньше, чем react+redux? Может всё же они немного для других задач? Может потому что они хорошо решают СВОИ задачи?
Учитесь и не спешите с выводами.
Ну, на мой взгляд, вывод автор сделал правильный)
Точно не потому что хорошо решают) JS тоже самый популярный язык, но это не делает его лучшим. Он популярен из-за того, что веб-разработка очень распространена, а браузеры не поддерживают другие языки.
Возвращаясь к react+redux. Помню, как в тем времена одновременно появилось много новых технологий. ES6, webpack, react + менеджеры состояний к нему и прочее. Народ не успевал во всем этом разобраться и большинство выбирали технологии по количеству лайков в github. В это время Абрамов показал зрелищный доклад на конференции, на которой были разработчики из facebook, которые и наняли его. Из-за этого события он обрел популярность и начали ошибочно полагать, что он очень сильный разработчик и сделал крутую вещь.
Я 3 месяца назад искал работу. К сожалению, вакансий c react + redux было гораздо больше чем с react + все остальное. Смотришь, хорошая вакансия, но redux все портит и нет особого желания всерьёз рассматривать позицию в проекте с ним. Да и на курсах штампуют новых поклонников Абрамова и redux-а. Эх, испортил Абрамов реакт основательно и надолго.
Для веб проектов я чаще всего беру pixi.js, three.js, playcanvas и react. Что в этом списке забыл реакт? Это длинная история для другой статьи, если кому-то это интересно.
Мне интересно было бы почитать) Еще было бы интересно увидеть статью от разработчика игр о том, как с его точки зрения разрабатывать игру на современных веб-технологиях. Когда веб-разработчики сталкиваются с необходимостью написать браузерную игру, берут привычные им технологии, а потом пишут статью, то обычно получается статья о том, как делать не надо.
перечислить что-то - только кажется простым вопросом от того, что не взято в расчёт, что у людей ассоциативная память. На самом деле подобные вопросы, если их не вызубрить перед интервью, могут застать врасплох любого сеньора. Если же вместо этого дать список методов и предложить рассказать их назначение, то на вопрос в таком формате ответит намного больше кандидатов.
Мда, скоро код на JS будет выглядеть как обфусцированный)
Такой роли у меня не было. Бывало пару раз, что на масштабный рефакторинг выделяли месяц-два.
Архитектурные навыки я неплохо прокачал другим способом. И итак нарефачился за свою жизнь) В одном проекте кто-то ключевой функционал сделал одной функцией на 800+ строк, плюс хватало проблем и в других местах. В другом - реакт с ангуляром вместе использовался и потом это переписывали на es6 и попутно избавлялись от angular. В третьем - с jquery на react переписывали.
Спасибо за совет! Вот некий редактор и был единственным интересным веб проектом. Жаль, что там был слишком плохой код и я не стал там задерживаться. А так, больше половины моих проектов - админки.
Тут еще момент, что с React почти везде используется Redux (в 2gis тоже) со своим зоопарком технологий, а мне он никогда не нравился. Не горю желанием тратить время на технологию, которая мне не интересна, диктует мне свою архитектуру, и без которой получается делать проще и быстрее.
Спасибо!
Месседжер - довольно интересно.
А вот с lerna не знаком, поэтому сложно представить. Конструктор для этого - имеется ввиду на формах сделанный?
Мне было бы интересно услышать о ваших проектах и/или в чем их сложность? Как и где искать такие проекты и как туда попасть?) Я понимаю, что есть сложные проекты, но я за почти 10 лет работы веб-разработчиком только один свой проект могу назвать сложным. В других если и была сложность, то только по причине большего количества спагетти кода на момент моего прихода. Собеседования были гораздо сложнее, чем сами проекты.
Я когда-то писал стейт-менеджер и успешно использовал его в парочке проектов, да и другие вещи писал. Но вот в тестовом не стал бы использовать (хотя сейчас и на тестовое не стал бы тратить время). В мире, в котором я живу, использование самописных решений вместо популярных готовых считается признаком неопытности.
Почему-то не получилось добавить коммент к вашему видео. В общем, если интересно, можете взглянуть на пару последних моих статей на хабре. Использую небольшие сторы только для данных и работой с этими данными (чтение/запись). Поток данных как в redux, но нет этих избыточных actions и dispatch. Пришел к такой архитектуре до того, как стал использовать Mobx, но она хорошо применима к нему и не только.
Ну а так, согласен, что из-за отсутствия best practices у большинства получаются раздутые сторы с хаотичными связями и потоком данных.
Не понял про идею, но по-моему, сейчас это стандартная ситуация практически на любом проекте с хуками) Обязательно в проекте присутствуют компоненты с несколькими хуками, у которых по несколько переменных в массиве зависимостей. И получается, что компонент зависит от нескольких десятков переменных. Ну и обычное дело, когда при вводе в input обновляется вся форма.
Ок, мне было не понятно. Хотел сказать, что проблема не в самих классах, а в реализации компонентов на классах. Можно было сделать лучше.
Ну, если не говорить про реакт и пойти, например, в сторону игр (я их когда-то разрабатывал), то многие большие игровые проекты успешно пишутся на классах. Как бы, проблема, которая недавно решена с помощью функциональных компонентов с хуками, уже лет 20-30 как решена на классах в геймдеве.
В случае классов можно не городить кучу оберток с помощью декораторов (HOC), а выносить логику из компонента в другие классы/объекты или функции, а также воспользоваться другими паттернами композиции, например стратегией. Если интересно, можете почитать о различных подходах в моей статье: https://habr.com/ru/post/545368/
Спасибо за подробный ответ!
В последнее время так и делаю. Это в прошлом пару собесов с самого начала пошли не так, т.к. не был готов к этому вопросу.
Вы, как и я, фронтенд разработчик. Можете привести пример, что бы вы ответили на этот вопрос? Я не работал в каких-либо крутых компаниях. В обычных средненьких компаниях над обычными проектами. За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутые, отфильтровать их по крутости и сформулировать, что и как я там делал несколько лет назад. Да и язык у меня не подвешен. Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам. А ведь потом еще надо решить простую задачу, и ответить на вопросы по теории, что опять же не сделаю без подготовки.
Я тоже к ним хотел, пока не побывал на собеседовании. Из примерно 15 компаний, где я проходил собеседования, у них были самые сложные задачи на алгоритмическом интервью. А первый же этап целиком состоял из решения задач. На мой взгляд, такой формат подходит, чтобы нанимать потенциально хороших разрабов среди студентов и джунов, т.к. большинство хороших и опытных фронтендеров не пройдут, т.к. слишком редко подобным занимаются. А тек кто пройдут, получат от других предложения с большей ставкой. Когда в компании был другой формат найма, они может и наняли хороших спецов, но боюсь, что если бы устроился к ним, то у меня был бы лид где-то с 3-мя годами опыта, которого мне бы пришлось учить писать простой и понятный код, а не сложный и супероптимальный с горой велосипедов.
На первый взгляд кажется правильный утверждением. Но данные одной страницы со временем понадобятся в другой. То есть при усложнении приложения потребуется либо переносить провайдер контекста выше, либо передавать данные в контекст, который не меняется при переходе на другую страницу. Мой опыт показывает мне, что обычно контекст лучше располагать до компонента, отвечающего за роутинг.
Не советую так делать, так как нарушается High Cohesion. В wiki хорошо написано, к каким проблемам это ведет. Как я уже неоднократно писал, в первую очередь стоит рассматривать разделение по функционалу, а только потом по типам. Если стараться применять это с принципом SRP, то со временем увидите, что:
функционал фильтрации примерно одинаков у всех сторов и его можно вынести отдельно, написав только одну реализация
Во многих случаях сторы отличаются в основном только данными, а большая часть их функций одинаковая. То есть общую часть можно вынести и добавлять при создании экземпляра стора.
То есть в простых случаях создание стора может быть таким:
const todosStore = createStore<ITodosState>();
а в более сложных таким:
либо для средних проектов (но не для больших, т.к. смешивания приводит к багам из-за конфликтов имен):
Они все 12 за 4 часа успевали сделать или только обязательные 3?)
gwg605 верно написал. Вашим сеньорам уже понятно, что от них ожидают и им не надо тратить время на раздумье над этим и на улучшение качества решения.
Второй момент, ваши сеньоры возможно набили руки именно на таких задачах. Дать им не привычные для них задачи и сроки сильно увеличатся. Как однажды сказал мой знакомый: "Если пишут 3-4 часа, это значит, что сделать второй раз такое-же задание займет у тебя 3-4 часа. А вот первый раз можно делать неделю :)"
Толковый сеньор в большинстве случаев не будет тратить время на тестовые задания, а будет выбирать среди тех компаний, где процесс найма не предполагает большой траты его личного времени. Ибо хороших предложений много и ему не выгодно тратить много времени на каждую компанию.
Не верится про 4 часа. Но я сужу с позиции программиста. Среди программистов подобные оценки - это показатель неопытности. Специалисты с небольшим опытом не учитывают многие нюансы, не видят подводных камней и часто переоценивает свои силы. Специалисты же, набившие немало шишек, уже более осторожны в оценке.
Думаю, те из них, кто жалуется до начала работы над заданием и отказываются от него, это как раз опытные ГД. А начинающие фигачат день и ночь, а потом, чтобы показать себя с лучшей стороны, говорят, что делали это всего несколько вечеров, уделяя по паре часов.
Поучительная статья для тех, кто оценивает в несколько часов или дней задания, которые на самом деле делать недели, а то и месяц-два - https://habr.com/ru/post/567014/
Я не говорю что он плох. Но он известней любого, гораздо более опытного фронтенд разработчика. Тогда он явно не был разработчиком, к которому стоило прислушиваться всему react сообществу, особенно в плане архитектуры. Я не работал с ним и не слежу за ним, поэтому не знаю в чем и насколько он хорош, но думаю, когда его нанимали, он был на уровне обычного миддла. Ну и поработав несколько лет в Фейсбук, он конечно стал гораздо более хорошим разработчиком, чем раньше.
Ну, на мой взгляд, вывод автор сделал правильный)
Точно не потому что хорошо решают) JS тоже самый популярный язык, но это не делает его лучшим. Он популярен из-за того, что веб-разработка очень распространена, а браузеры не поддерживают другие языки.
Возвращаясь к react+redux. Помню, как в тем времена одновременно появилось много новых технологий. ES6, webpack, react + менеджеры состояний к нему и прочее. Народ не успевал во всем этом разобраться и большинство выбирали технологии по количеству лайков в github. В это время Абрамов показал зрелищный доклад на конференции, на которой были разработчики из facebook, которые и наняли его. Из-за этого события он обрел популярность и начали ошибочно полагать, что он очень сильный разработчик и сделал крутую вещь.
Я 3 месяца назад искал работу. К сожалению, вакансий c react + redux было гораздо больше чем с react + все остальное. Смотришь, хорошая вакансия, но redux все портит и нет особого желания всерьёз рассматривать позицию в проекте с ним. Да и на курсах штампуют новых поклонников Абрамова и redux-а. Эх, испортил Абрамов реакт основательно и надолго.
Мне интересно было бы почитать) Еще было бы интересно увидеть статью от разработчика игр о том, как с его точки зрения разрабатывать игру на современных веб-технологиях. Когда веб-разработчики сталкиваются с необходимостью написать браузерную игру, берут привычные им технологии, а потом пишут статью, то обычно получается статья о том, как делать не надо.