Опыт разработки тестового задания на React для Aviasales

Привет, я хотел поделиться опытом разработки тестового задания для Aviasales.


Я недавно наткнулся на вакансию React разработчика в компанию Aviasales. Отправил заявку, после чего на следующий день мне ответил HR и сообщил, что я должен буду сделать тестовое задание. Я крайне не люблю делать тестовые задания, так как я должен потратить довольно много времени на их выполнение, а в случае неудачи это станет впустую. Но я согласился...


Само тестовое задание вы можете найти тут по ссылке.


Вот тут ссылка на мой репозиторий выполненного задания.


Я ограничил себя в выполнении задания в один день (правда небольшие доработки я все же делал уже после публикации: дорисовывал эскиз, так сказать).


Что я выбрал для разработки:


  1. Я выбрал NextJS как основу, так как возиться с настройкой среды под Webpack мне не хотелось, да и задеплоить сам проект можно парой кликов.
  2. Я хотел писать быстро и выбрал пакет React-IOC в связке с MobX, вместо Redux. Это пакет, позволяющий писать приложения через сервисы, напоминающие сервисы angular.
  3. Я использовал Web Worker, чтобы не было лагов в интерфейсе во время сортировки большого объема данных.
  4. Я не использовал Typescript с целью не писать дополнительный код с бесполезной растратой времени на тестовое задание.
  5. Исходя из пункта 4 я так же не писал тестов.
  6. Я добавил в проект два дополнительных пакета: debounce, RxJS. Первый нужен для создания простых callback, например смену состояния загрузки, чтобы не показывать спиннер загрузки, если загрузка занимает крайне мало времени. Второй пакет я всегда использую для создания сценария действий, например, для обработки состояний в случае ошибки при отправке запроса на сервер.

Порядок действий первой стадии разработки:


  1. Проинициализировал репозиторий.
  2. Проинициализировал проект NextJS.
  3. Добавил базовую страницу index с сообщением Hello World.
  4. Создал сервис ticket.provider, который взаимодействует с api сервером.
  5. Создал сервис ticket.service, который инжектирует ticket.provider и заполняет обсервер с массивом отображаемых билетов
  6. Создал ticket.filter.service, который хранит в себе отфильтрованные данные, инжектирующиеся из ticket.service через @computed

Вторая стадия разработки:


  1. Создал компоненты и расписал стили к ним, используя макет, предоставленный в репозиторий задании.
  2. Сделал спиннер загузки и проставил его значение из сервисов.
  3. Подсоединил всю сервисную логику с компонентами.
  4. Добавил утилиты с форматированием данных, таких как время и деньги.

Тут я решил попробовать интерфейс «на ощупь» и нашёл недоработки при использовании приложения:


  1. Имеются подтормаживания интерфейса при изменении фильтра и сортировке, поэтому я перенёс хранение, получение и фильтрацию данных в Web Worker, после чего лаги полностью пропали.
  2. Спиннер не исправлял прыгающей анимации строк, вследствие чего я заменил его на визуальное отображение строк с анимацией мерцания.
  3. Для простоты рендеринга данных я перенёс вызовы форматирования данных в Web Worker, это уменьшает нагрузку на рендеринг компонента

Тут я закончил свою работу и под конец дня отправил задание на проверку.


Так как я ограничил себя во времени, я не стал оптимизировать приложение далее, а именно я не стал использовать React.memo(...). Я так же не стал заменять window и router на инжекторы в сервисах. За это простите меня, это недоработка.


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


Я ждал ответа от них 7 дней, они не отвечали ни на одно мое сообщение. Это был неприятный опыт, так сказать. Но все же ответили, и ответ был крайне огорчающий к прочтению. Сообщение можно увидеть ниже.


Давайте разберём замечания по пунктам:


[1]. «Работа выполнена очень не аккуратно»


Не вижу где, не аргумент, так как нет примеров.


[2]. «Кажется, при разработке преследовались цели «оно же работает», и игнорировалось «как это работает»»


Не аргумент, нет примеров.


[3]. «Если исходить из наших требований к уровням кандидатов, то реализованное задание едва дотягивает до middle.»


Какие требования? Где они?


[4]. «Мы ожидаем, что фильтры не будут захардкожены и будут подстраиваться под данные. Если зайти на aviasales, то можно увидеть, что билеты показываются сразу как появляется первая партия, а не дожидаемся загрузки всех.»


Этого требования не было в приложенном задании. А само приложение Aviasales, на мой взгляд, не обладает эталонным интерфейсом, и прыгающие билеты не являются наилучшим решением.


[5]. «Почему filter.service знает об router и window? Он не должен управлять состоянием приложения и иметь таких зависимостей вообще.»


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


[6]. «Web Workers. В чем профит? В данном кейсе тратится много времени на асинхронные операции, а сэкономленную нагрузку в main thread тратим на serialize/deserialize объектов (и observable объектов). Если речь идет об оптимизациях, то стоило начинать не с выноса в web worker, а исправить проблемы в main thread.»


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


[7]. «Нет смысла добавлять в проект rxjs только для реализации retry и последовательной загрузки.»


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


[8]. «Проект невозможно масштабировать и поддерживать. Конструкции типа (ticket.segments || [{}, {}]).map((ticket) => ...) сильно громоздские.»


Давайте пройдёмся по критериям масштабирования и поддержки: доступность (сервисы решают эту проблему), риски (ticket.segments || [{}, {}] — как раз пример того как обходиться со случаями, если input не содержит данных. Пример плохой, но подход nullable structure как минимум, но я стараюсь соблюдать), чистый код (ну как минимум я знаю что это :), хотя старался писать все как положено). Вроде все схвачено, опять не аргумент.


[9]. «Сложилось впечатление, что абсолютно нет понимания как работает React под капотом. Много критичных ошибок по работе с props у компонентов, которые очень плохо влияют на производительность. Игнорируются механизмы оптимизаций в React.»


Не могу понять где эти описанные проблемы. Какие именно механизмы?


[10]. «Создание функций-обработчиков внутри render.»


У меня вообще нет никаких функций обработчиков в render, кто нибудь понимает о чем тут написано? Даже обработку форматирования я перенёс в Web Worker


[11]. «Создание нового пустого объекта и передача его в билет.ticket-list-loading.jsx:10 или Ticket.tsx:24


Тут нет ничего критического, кроме моей лени выносить отдельно loading-ticket компонент. Передача пустого объекта не нарушает никакой принцип программирования, кроме того что тут нужно было сделать это через ticket = ticket || {}; но это сугубо из-за того что время на разработку было ограничено одним днём и исправлять все незначительные недочеты потребовало бы больше времени.


[12]. «Индексы массива как ключи на списке билетов»


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


Ну и напоследок вывод: «В общем, в React не получилось (
Итого: для middle уровня мы ожидаем, что с react не будет критичных проблем, но в выполненной работе их довольно много.»


Тут уже без комментариев...


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


Полный текст сообщения:


Работа выполнена очень не аккуратно. Кажется, при разработке преследовались цели «оно же работает», и игнорировалось «как это работает». Если исходить из наших требований к уровням кандидатов, то реализованное задание едва дотягивает до middle.


Работоспособность и структура:
Мы ожидаем, что фильтры не будут захардкожены и будут подстраиваться под данные. Если зайти на aviasales, то можно увидеть, что билеты показываются сразу как появляется первая партия, а не дожидаемся загрузки всех.


Далее, более технические моменты.


  1. Почему filter.service знает об router и window? Он не должен управлять состоянием приложения и иметь таких зависимостей вообще.
  2. Web Workers. В чем профит? В данном кейсе тратится много времени на асинхронные операции, а сэкономленную нагрузку в main thread тратим на serialize/deserialize объектов (и observable объектов). Если речь идет об оптимизациях, то стоило начинать не с выноса в web worker, а исправить проблемы в main thread.
  3. Нет смысла добавлять в проект rxjs только для реализации retry и последовательной загрузки.
  4. Проект невозможно масштабировать и поддерживать. Конструкции типа (ticket.segments || [{}, {}]).map((ticket) => ticket) сильно громоздские.
    React:
    Сложилось впечатление, что абсолютно нет понимания как работает React под капотом. Много критичных ошибок по работе с props у компонентов, которые очень плохо влияют на производительность. Игнорируются механизмы оптимизаций в React. Тезисно о проблемах:
  5. Создание функций-обработчиков внутри render.
  6. Создание нового пустого объекта и передача его в билет. ticket-list-loading.jsx:10 или Ticket.tsx:24.
  7. Индексы массива как ключи на списке билетов.
    В общем, в React не получилось :(

Итого: для middle уровня мы ожидаем, что с react не будет критичных проблем, но в выполненной работе их довольно много.

Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 39

    –1
    Я конечно всё понимаю, реакты там всякие, синтаксический сахар, пробелы вместо табов и т.п.

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

    Это чё, щас модно так?
    А зачем сервер тогда вообще нужен?
    Можно же просто текстовый файлик с жсоном положить в одну папочку и всё.
      –6
      Такая базовая операция как фильтрация по имеющимся данным может и должна делаться на фронте. Сервер должен вступать в игру только тогда, когда
      а) на фронте нет всех данных для фильтрации
      б) время обработки данных на фронте больше чем суммарное время передачи запроса к серверу, обработки им запроса и приёма ответа от него
        +2
        у этих на фронтенде, другие за подобный подход выгонят поганой метлой.
        Заранее не угадаешь.
        0
        Это чё, щас модно так?
        Обычный клиентский рендеринг, ничего необычного.

        А зачем сервер тогда вообще нужен?
        Как зачем? Чтобы сформировать это «огромное полотенце всех данных».
          +1
          Обычный клиентский рендеринг — это сортировка данных. А фильтрация на клиенте — очень необычно. Оно конечно допустимо, если контекст использования предполагает отправку небольшой выборки (т.е. основная фильтрация происходит на сервере), но не в общем случае.
            –1
            На самом сайте авиасейлс хотя б не весь объём скачивают, а по пункту отправки-назначения (т.е. все рейсы Москва / Санкт-Петербург, например).

            И при нажатии Поиск посетитель видит полосу прокрутки для отвлечения внимания, страница занята тем что скачивает огромный кусок, а вовсе не ищет что-то.

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

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

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

                Естественно, страница ничего не ищет, ищет бэкенд, а страница батчами подгружает то что бэкенд нашел.
                  0
                  у этих ищет.

                  Скачивает огромный кусок всех рейсов Москва/Санкт-Петербург, а потом фильрует для показа пользователю.
                    0
                    Ну-ну, расскажите мне как все работает у этих :)
                    Вот мой linked-in если что www.linkedin.com/in/david-klassen
                      0
                      бог подаст. Любой может открыть в хроме инструменты разработчика и лично посмотреть чего и сколько скачивается.
                        0
                        Любой может открыть в хроме инструменты разработчика и лично посмотреть чего и сколько скачивается.

                        Но некоторые сделают из увиденного абсолютно неверные выводы :)
          +1
          Исходя из пункта 4 я так же не писал тестов

          Для тестового задания лучше все же с тестами


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

            0

            В требованиях к заданию, этого нет. Да и HR сказал что не надо.

              +1
              И заходя наперёд, да я понимаю что работать по TDD может быть выгодно, но начитавшись книжек для бэка и десктопных приложений и тд, это слабо применимо к фронтенду, когда нужно что то сверстать и выкинуть, так как настройка среды для тестирования фронт проектов обычно занимает достаточно много времени. Если не согласны, взгляните сколько способов и сколько сред для тестирования всего лишь ангуляр приложений. Я практикую это для основных проектов, но опять же, тестовые проекты должны хотяб оплачиваться так же. И чаще всего тесты начинаются уже после утверждённого десятого, а то и двадцатого прототипа.
            +1
            Открыл репу. Организация кода какая-то непонятная.
            Функции-обработчики — у вас функции создаются при каждом рендере. Например, тут 23 строка: github.com/makamekm/aviasales-demo/blob/master/components/filter.jsx
            На выходе html из одних дивов…
              0
              Скажите спасибо, что не из одних [i]-шек. Встречалась мне и такая практика.
                0

                А как надо? Через bind? Через bind тестируемость будет проблематична.

                  0
                  Вынести обработчик в константу-переменную выше, желательно и вовсе передавать в компонет как проперти. И лишнего создания объекта не будет и тестирование, модификация, поддержка будет лучше.
                    0

                    Передавать как property тут не подходит. Появляется колбаса из пропертей, для этого и есть react-ioc. Но пропертя не решит проблему сменившегося контекста вызова на компонент, вместо сервиса. Так как сделать иначе?

                      0
                      Явное лучше, чем неявное. Я твой коллега, хочу взять твой готовый компонент для своей задачи, почему я должен разбираться что он там берёт из ioc. Ожидаю что-то вроде простого, даже в автокомплитом, чтобы не надо было лезть внутрь компонента.
                      import Filter from 'Filter';
                      А у вас в компоненте каша, стили, ioс, mobx и стили и т.д.
                        0

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

                          +1
                          А, но вот оно чё. К чему тогда вопросы? Эйчары отработали чётко, похоже проблемы не только в коде.

                          p.s. Уверен, js и react ты знаешь лучше меня, но не похоже чтобы ты когда-то работал в нормальной команде.
                0
                Root.getInitialProps = async /* зачем? */ ({ 
                  req /* зачем? */,
                  query // тут можно получить query параметры
                }) => ({ 
                  query,
                  init: true // зачем?
                });


                
                changeUrl(url) {
                    this.router.push(url, url, { shallow: true });
                    // может проще так?
                    // this.router.push({pathname: "/",  as: "/",  query: {transition: "[1,2]"}});
                    // это будет запускать getInitialProps где ты сможешь парсить свои query 
                    // параметры без велосипеда и сразу пробрасывать это все в пропсы?
                }
                

                Вообщем тут каждую строчку можно долго обсуждать. С моей точки зрения — сильно много намудрил. Мой тебе совет — пиши очень тупой и «чистый» код для прохождения собеседований успешно. И лучше сразу пиши тестируемый код — ты увидишь массу проблем еще на стадии разработки. PS. В последнем next typescript работает из коробки.
                  0
                  Вы нашли пример костыля, если вы работали с NextJS, то если не предоставить фреймворку функцию getInitialProps, то ssr вообще не распарсит query. Приходится всегда вставлять такую ерунду. Можете найти тикет в репозитории фрейма, там их много.

                  Второе замечание по сути ничего не даёт, опять же все упирается в баг ssr. К сожалению фрейм не без недостатков.

                  Typescript так же работает из под коробки только с чистым проектом, а как добавляешь изображения, стили, и тд и тд (я имею ввиду плагины), то проект не компилируется. Лучше ради тестового проекта сидеть на JS.

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

                  А попадись такой «ревьювер» начинающему программисту, руки отобьёт и заставит его уйти в другую область. Слава богу, что мне когда то попались отличные ребята.
                    0
                    Так вы сделали getInitialProps — только совсем пустой и ничего не делающий (это не недостаток фреймворка — это его фича хендлить что-то на сервере до рендера). В чистом реакте такого нет. Эта штука работает только на страницах.

                    Далее вы сделали обертку над страницей (HOC) — этого можно избежать создав файлы _document и _app в каталоге страниц. Советую прочитать про этот функционал.

                    Со стилями на next лучше работать через `https://cssinjs.org/?v=v10.0.0` — подключается очень просто.

                    Про изображения — ложите их в папку static.

                    И еще философски react как бы хочет, чтобы вы все делали на функциях (у них прям секта). Мотивация у вас хорошая, что вы попытались всунуть IOC в фронтенд. Но эти ребята из facebook придумали такую хрень как jest — в котором можно легко в unit test-e замокать целый файл в 1 строку:

                    import myFunc from './my-func';
                    import funcToTest from './func-to-test'; // export default (arg) => myFunc(arg);
                    
                    jest.mock('./my-func', () => jest.fn());
                    
                    // далее в тесте...
                    
                    it('should test', () => {
                      myFunc.mockImplementation(arg => `test${arg}`);
                      const result = funcToTest('bla');
                      expect(myFunc).toHaveBeenCalled...
                      expect(result).toEquals('testbla');
                    });
                    


                    А вот если вы будете делать backend на nodejs — то туда IOC уже надо (хотя тоже спорный вопрос — есть инструменты как разрулить эту проблему). Проблем с моканьем в react нет — так как фреймворк для тестирования react — это jest.

                    По поводу «ревьювера» — эх вы еще с Немцами видать не работали. У меня ~15 лет опыта разработки в ИТ — я просто пытаюсь показать/помочь/поделиться информацией в том, что можно улучшить — я не пытаюсь вас загнобить. Лучше используйте в следующий раз `create-react-app` или `gatsby` — там все как вам хочется и из коробки работает и попроще.

                    PPS: И еще у вас нигде нет PropTypes — многие думают, что оно устарело и не пишут их — но поверьте — это помогает. В TypeScript можно сделать InferProps и получить тип для props без дупликации описания типа и проптайпсов.
                      0

                      Абсолютно с вами не согласен.


                      1. Про getInitialProps попробуйте стянуть мой проект и удалить эту функцию то поймёте о чем я.


                      2. Использование document и app глючили и не собирались в момент инициализации после добавления react-ioc. Но под конец разработки я не проверял.


                      3. Со стилями предпочитаю работать из под коробки. Добавление ещё одного типа добавит жалоб что слишком сложный проект.


                      4. Если они хотят, то в функционале реакт не было бы бы context.


                      5. Если ложить обычные svg в папку static то они будут при загрузке пропадать до момента полной загрузки. Увы, это не панацея.


                      6. Мокать это хорошо, но мокать таким образом как вы показали так же не нравится многим клиентам и разработчикам, те тоже спорное решение. Лучше через dependency injection.


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


                      8. Я не использую PropTypes тут только потому что планировал переименовать все эти файлы в tsx и добавить типов. Но по времени не уложился.



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

                0

                У меня небольшой опыт в реакте, поэтому вопрос, наверное, глупый. В чем смысл компонента Panel? Это же просто обёртка div с классом. У вас в index.jsx под этим самым panel еще один div с классом, но его же не вынесли в компонент.
                И еще, зачем у вас в layout все children оборачиваются в div?

                  0
                  В чем смысл компонента Panel?

                  В данном случае особо смысла нет, но если бы на панели был ещё какой-нибудь стандартный элемент, то было бы ok.
                  все children оборачиваются в div

                  Автор перестраховывается, чтобы не поехала вёрстка, но имхо divы излишни
                  0
                  Сразу оговорюсь — без обид.

                  После прочтения тестового задания и просмотра твоего кода. Я бы отвергнул твою кандидатуру.

                  1. Задание довольно простое. А вот лишнего когда очень много.
                  2. Использование кучи сторонних либ, хотя можно обойтись и без них.
                  3. Использование стартер китов вместо ручной конфигурации. Для меня это показатель, что человек разбирается, как и что конфигурить.
                  4. Использование Typescript (да, в ТЗ указано, что можно и JS), но я бы отдал предпочтение тому кандидату, который бы прислал выполненное задание на TS
                  5. Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.
                  6. Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.


                  Рекомендую автору умерить свое негодование. Да, у каждого из нас огромное самомнение и все мы любим, что бы нас хвалили и говорили какие мы крутые. Но жизнь с#$@ злая и бьет разводным ключом по голове. Поэтому стоит успокоится и провести анализ ошибок.

                  Лучше всего, поставить себя на место работодателя. Представь что тебе нужен человек в команду и с которым ты будешь работать не один год. Как бы ты спрашивал, на что бы смотрел итд?

                  Я сам проходил через такое. Писал тестовые задания, получал негативный фидбек. Расстраивался. Но, я делал работу над ошибками, развивался.

                  Удачи! Я думаю, в следующий раз у тебя получится.

                  PS я никакого отношения к компании Aviasales не имею, и слышу о них впервые :) и данный коммент я написал и собственного опыта, сначала как соискателя, а сейчас как собеседующего кандидатов.
                    0
                    1. «А вот лишнего когда очень много»
                    Прошу показать где.

                    2. «Использование кучи сторонних либ, хотя можно обойтись и без них»
                    Какие сторонние? Их всего 3 (mobx, rxjs, react-ioc).

                    3. «Использование стартер китов вместо ручной конфигурации»
                    Я сгенерировал проект через next init. Этого не достаточно?

                    4. «Использование Typescript»
                    Я написал почему я не использовал Typescript — прошу перечитать. Но даже если переименовать файлы в ts и tsx, и добавить типов то это ничего ровным счетом не изменит.

                    5. «Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.»
                    В задании нет, мне сообщили что не надо. Надо тесты — пусть оплачивают время на разработку.

                    6. «Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.»
                    Это не дипломная и не работа на заказчика, не придумывайте. Это просто бесплатное тестовое задание. Писание документации это абсолютное иного рода деятельность, которая так же должна быть оговорена и оплачена.

                    7. «Поэтому стоит успокоится и провести анализ ошибок»
                    Какие ошибки из этого можно подчеркнуть? Можете привести «реальный пример»? Я ничего кроме чсв ревьювера не вижу. Задание сделано идеально за оговоренный промежуток времени, при этом работает быстрее и лучше приложения от самих Aviasales за счет использования Web Worker, после чего мне заявляют что нет смысла их использовать и в отзыве мне дают рейт Juniora и заявляют что я не знаю React. А само ревью написано абсолютно субъективным стилем. Обидно как то…

                    Задание сделано за день, как и было оговорено с HR. Я не собирался делать ничего, что заняло бы больше времени. Прошу это учесть.
                      0
                      Боюсь вы слышите только себя. Повторюсь — поставьте себя на место работодателя.

                      1. Посмотрите на mock-up и посмотрите сколько у вас компонентов, тулзов итд.
                      Кстати, вы могли съекономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла. Обычно, я на такие вещи просто не обращаю внимания. Верстку и джуны могут сделать. А вот структура, подходы к разработке, понимание что зачем и как, документация, тесты — вот на это всегда упор.

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

                      3. Лично для меня недостаточно. Кстати, когда-то получил два отказа по хорошим позициям именно из-за генерилок. Хотя в ТЗ это не оговаривалось. Сюрприз!

                      4. Это ваше видение. С моей колокольни это бы показало, что человек знает как курить TS и для него нет проблем работать с React + TS.

                      5. Тесты должны быть и точка. Даже если о них не просили.

                      6. Описание должно быть. Если вы что-то разрабатываете, а тем более если планируете работать в команде и занимать должность Senior. Вы ее должны уметь писать. Грамотно, кратко и по делу. Если не умеете — вы не Senior, так, хороший мидл.

                      7. Жаль, что вы не видите ошибок. Но это дело наживное. Со временем, вы пересмотрите свои взгляды, ну или смените род деятельности. Так тоже бывает.

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

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

                      В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общатся. Тогда такому влиться в команду будет очень легко.
                        0
                        1. «Посмотрите на mock-up и посмотрите сколько у вас компонентов, тулзов итд.»
                        И что тут не так? Зато все читаемо на ура

                        2. «Кстати, вы могли сэкономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла.»
                        Вот именно!

                        3. «Вот именно! Все можно сделать без этих зависимостей»
                        Тогда появятся новые файлы с новыми функциями, которые придется покрыть тестами.

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

                        «Жаль, что вы не видите ошибок»
                        Проблема что вы тоже тут не видите ошибок, а сами заявляете что они есть.

                        «В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общаться. Тогда такому влиться в команду будет очень легко.» — работать с таким ревьювером я не пожелаю никому. Но вы переводите косяк на меня, спасибо.
                          0
                          И вам желаю удачи в поиске новой работы. Надеюсь вы найдете себя.
                    0
                    Не переживай. По факту, за день ты сделал довольно большой кусок функционала и писать вещи в стиле «В общем, в React не получилось :(» в таких случаях позволяют себе только ЧСВ-шники 81 лвл-а (которых в front-end каждый второй). Вопрос, надо ли тебе работать в такой команде? Твой затраченный день стоит, как минимум, вежливости со стороны этих js гуру.
                      +2
                      У наших HR нет аккаунта на Хабре (shame!), поэтому, просили передать.

                      Максим, привет!
                      Спасибо за пост, наверняка он будет кому-то полезен.
                      Для нас в Aviasales важно, как кандидаты подходят к выполнению нашего тестового задания, ведь оно максимально приближено к боевым задачам, с которыми будущему разработчику предстоит столкнуться. Твоя реализация нас не устроила и мы написали почему. Возможно, мы были резки в некоторых формулировках, за что приносим извинения, но мы ни в коем случае не хотели тебя обидеть.
                      Мы всегда стараемся давать подробную обратную связь, чтобы у кандидата была возможность проанализировать свою работу, учесть замечания. Или наоборот, сделать вывод, что кандидат умнее ревьюеров, которые не умеют в программирование и слава б_гу не сложилось. Это как проверка на совместимость: подход команды VS подход кандидата, и ничего личного.
                      Желаем найти работу на достойном уровне!
                      P.S. Мы по-прежнему в поиске, вакансия еще открыта :wink:
                        +1
                        Когда хабр успел из технического «журнала» превратиться в площадку, где можно поныть о заваленном тестовом? Извините за мою прямоту, но кажется это не подходящий контент для хабра.
                          –2

                          поражают конторы, которые находятся еще в 15м веке — какие тестовые задания?
                          время — деньги!
                          в 90е существовала куча помоек, которые выдавали такие якобы тестовые задания задачи — не было цели нанять людей — целью было получить на халяву хоть какое-либо рабочее решение, а кандидату писали вежливый отказ :)

                          Only users with full accounts can post comments. Log in, please.