Comments 41
Такая базовая операция как фильтрация по имеющимся данным может и должна делаться на фронте. Сервер должен вступать в игру только тогда, когда
а) на фронте нет всех данных для фильтрации
б) время обработки данных на фронте больше чем суммарное время передачи запроса к серверу, обработки им запроса и приёма ответа от него
а) на фронте нет всех данных для фильтрации
б) время обработки данных на фронте больше чем суммарное время передачи запроса к серверу, обработки им запроса и приёма ответа от него
Это чё, щас модно так?Обычный клиентский рендеринг, ничего необычного.
А зачем сервер тогда вообще нужен?Как зачем? Чтобы сформировать это «огромное полотенце всех данных».
Обычный клиентский рендеринг — это сортировка данных. А фильтрация на клиенте — очень необычно. Оно конечно допустимо, если контекст использования предполагает отправку небольшой выборки (т.е. основная фильтрация происходит на сервере), но не в общем случае.
Основная проблема такого подхода в том что мы не можем отправить запрос на получение всех данных параллельно, мы должны последовательно отправлять запрос за запросом и тратим время на отправку и прием, что выливается в довольно таки большую задержку.
Я бы предпочел получать последние 5 билетов по определенным фильтрам. Да, переключение фильтров будет дольше, но зато я буду уверен что информация актуальна и мне не придется обновлять всю страницу вручную.
Да и в конце концов можно открыть три страницы с разными фильтрами и на каждой подписаться на новые билеты, удовлетворяющие условиям фильтра.
Я бы предпочел получать последние 5 билетов по определенным фильтрам. Да, переключение фильтров будет дольше, но зато я буду уверен что информация актуальна и мне не придется обновлять всю страницу вручную.
Да и в конце концов можно открыть три страницы с разными фильтрами и на каждой подписаться на новые билеты, удовлетворяющие условиям фильтра.
страница занята тем что скачивает огромный кусок, а вовсе не ищет что-то.
Естественно, страница ничего не ищет, ищет бэкенд, а страница батчами подгружает то что бэкенд нашел.
Ну-ну, расскажите мне как все работает у этих :)
Вот мой linked-in если что www.linkedin.com/in/david-klassen
Вот мой linked-in если что www.linkedin.com/in/david-klassen
Исходя из пункта 4 я так же не писал тестов
Для тестового задания лучше все же с тестами
Это не к этому работодателю а ыцелом если делать тестовые задания.
В требованиях к заданию, этого нет. Да и HR сказал что не надо.
И заходя наперёд, да я понимаю что работать по TDD может быть выгодно, но начитавшись книжек для бэка и десктопных приложений и тд, это слабо применимо к фронтенду, когда нужно что то сверстать и выкинуть, так как настройка среды для тестирования фронт проектов обычно занимает достаточно много времени. Если не согласны, взгляните сколько способов и сколько сред для тестирования всего лишь ангуляр приложений. Я практикую это для основных проектов, но опять же, тестовые проекты должны хотяб оплачиваться так же. И чаще всего тесты начинаются уже после утверждённого десятого, а то и двадцатого прототипа.
Открыл репу. Организация кода какая-то непонятная.
Функции-обработчики — у вас функции создаются при каждом рендере. Например, тут 23 строка: github.com/makamekm/aviasales-demo/blob/master/components/filter.jsx
На выходе html из одних дивов…
Функции-обработчики — у вас функции создаются при каждом рендере. Например, тут 23 строка: github.com/makamekm/aviasales-demo/blob/master/components/filter.jsx
На выходе html из одних дивов…
Скажите спасибо, что не из одних [i]-шек. Встречалась мне и такая практика.
А как надо? Через bind? Через bind тестируемость будет проблематична.
Вынести обработчик в константу-переменную выше, желательно и вовсе передавать в компонет как проперти. И лишнего создания объекта не будет и тестирование, модификация, поддержка будет лучше.
Передавать как property тут не подходит. Появляется колбаса из пропертей, для этого и есть react-ioc. Но пропертя не решит проблему сменившегося контекста вызова на компонент, вместо сервиса. Так как сделать иначе?
Явное лучше, чем неявное. Я твой коллега, хочу взять твой готовый компонент для своей задачи, почему я должен разбираться что он там берёт из ioc. Ожидаю что-то вроде простого, даже в автокомплитом, чтобы не надо было лезть внутрь компонента.
import Filter from 'Filter';
А у вас в компоненте каша, стили, ioс, mobx и стили и т.д.
import Filter from 'Filter';
А у вас в компоненте каша, стили, ioс, mobx и стили и т.д.
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 работает из коробки.
Вы нашли пример костыля, если вы работали с NextJS, то если не предоставить фреймворку функцию getInitialProps, то ssr вообще не распарсит query. Приходится всегда вставлять такую ерунду. Можете найти тикет в репозитории фрейма, там их много.
Второе замечание по сути ничего не даёт, опять же все упирается в баг ssr. К сожалению фрейм не без недостатков.
Typescript так же работает из под коробки только с чистым проектом, а как добавляешь изображения, стили, и тд и тд (я имею ввиду плагины), то проект не компилируется. Лучше ради тестового проекта сидеть на JS.
Не забывайте, что я сделал этот проект за день, учитывая, что я делал основную работу и вечером сидел с ребёнком. Мне, как и большинству таких как я очень дорого время, а написал статью я скорее для таких же как я, чтобы мы такие компании с завышенными чсв сотрудниками обходили стороной.
А попадись такой «ревьювер» начинающему программисту, руки отобьёт и заставит его уйти в другую область. Слава богу, что мне когда то попались отличные ребята.
Второе замечание по сути ничего не даёт, опять же все упирается в баг ssr. К сожалению фрейм не без недостатков.
Typescript так же работает из под коробки только с чистым проектом, а как добавляешь изображения, стили, и тд и тд (я имею ввиду плагины), то проект не компилируется. Лучше ради тестового проекта сидеть на JS.
Не забывайте, что я сделал этот проект за день, учитывая, что я делал основную работу и вечером сидел с ребёнком. Мне, как и большинству таких как я очень дорого время, а написал статью я скорее для таких же как я, чтобы мы такие компании с завышенными чсв сотрудниками обходили стороной.
А попадись такой «ревьювер» начинающему программисту, руки отобьёт и заставит его уйти в другую область. Слава богу, что мне когда то попались отличные ребята.
Так вы сделали getInitialProps — только совсем пустой и ничего не делающий (это не недостаток фреймворка — это его фича хендлить что-то на сервере до рендера). В чистом реакте такого нет. Эта штука работает только на страницах.
Далее вы сделали обертку над страницей (HOC) — этого можно избежать создав файлы _document и _app в каталоге страниц. Советую прочитать про этот функционал.
Со стилями на next лучше работать через `https://cssinjs.org/?v=v10.0.0` — подключается очень просто.
Про изображения — ложите их в папку static.
И еще философски react как бы хочет, чтобы вы все делали на функциях (у них прям секта). Мотивация у вас хорошая, что вы попытались всунуть IOC в фронтенд. Но эти ребята из facebook придумали такую хрень как jest — в котором можно легко в unit test-e замокать целый файл в 1 строку:
А вот если вы будете делать backend на nodejs — то туда IOC уже надо (хотя тоже спорный вопрос — есть инструменты как разрулить эту проблему). Проблем с моканьем в react нет — так как фреймворк для тестирования react — это jest.
По поводу «ревьювера» — эх вы еще с Немцами видать не работали. У меня ~15 лет опыта разработки в ИТ — я просто пытаюсь показать/помочь/поделиться информацией в том, что можно улучшить — я не пытаюсь вас загнобить. Лучше используйте в следующий раз `create-react-app` или `gatsby` — там все как вам хочется и из коробки работает и попроще.
PPS: И еще у вас нигде нет PropTypes — многие думают, что оно устарело и не пишут их — но поверьте — это помогает. В TypeScript можно сделать InferProps и получить тип для props без дупликации описания типа и проптайпсов.
Далее вы сделали обертку над страницей (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 без дупликации описания типа и проптайпсов.
Абсолютно с вами не согласен.
Про getInitialProps попробуйте стянуть мой проект и удалить эту функцию то поймёте о чем я.
Использование document и app глючили и не собирались в момент инициализации после добавления react-ioc. Но под конец разработки я не проверял.
Со стилями предпочитаю работать из под коробки. Добавление ещё одного типа добавит жалоб что слишком сложный проект.
Если они хотят, то в функционале реакт не было бы бы context.
Если ложить обычные svg в папку static то они будут при загрузке пропадать до момента полной загрузки. Увы, это не панацея.
Мокать это хорошо, но мокать таким образом как вы показали так же не нравится многим клиентам и разработчикам, те тоже спорное решение. Лучше через dependency injection.
Я полностью за контроль состояния приложения через сервисы. Redux уж слишком заставляет много писать кода. Не говоря уже о других проблемах при написании бизнес логики между моделями, об этом как нибудь я напишу статью.
Я не использую PropTypes тут только потому что планировал переименовать все эти файлы в tsx и добавить типов. Но по времени не уложился.
Кто где сколько работал не является показателем знаний и реальных способностей. Извиняюсь, если грубо, но я бы с вами пообщался по Скайпу. Может что нить сделаем вместе, если у вас есть свободное время?
У меня небольшой опыт в реакте, поэтому вопрос, наверное, глупый. В чем смысл компонента Panel? Это же просто обёртка div с классом. У вас в index.jsx под этим самым panel еще один div с классом, но его же не вынесли в компонент.
И еще, зачем у вас в layout все children оборачиваются в div?
Сразу оговорюсь — без обид.
После прочтения тестового задания и просмотра твоего кода. Я бы отвергнул твою кандидатуру.
Рекомендую автору умерить свое негодование. Да, у каждого из нас огромное самомнение и все мы любим, что бы нас хвалили и говорили какие мы крутые. Но жизнь с#$@ злая и бьет разводным ключом по голове. Поэтому стоит успокоится и провести анализ ошибок.
Лучше всего, поставить себя на место работодателя. Представь что тебе нужен человек в команду и с которым ты будешь работать не один год. Как бы ты спрашивал, на что бы смотрел итд?
Я сам проходил через такое. Писал тестовые задания, получал негативный фидбек. Расстраивался. Но, я делал работу над ошибками, развивался.
Удачи! Я думаю, в следующий раз у тебя получится.
PS я никакого отношения к компании Aviasales не имею, и слышу о них впервые :) и данный коммент я написал и собственного опыта, сначала как соискателя, а сейчас как собеседующего кандидатов.
После прочтения тестового задания и просмотра твоего кода. Я бы отвергнул твою кандидатуру.
- Задание довольно простое. А вот лишнего когда очень много.
- Использование кучи сторонних либ, хотя можно обойтись и без них.
- Использование стартер китов вместо ручной конфигурации. Для меня это показатель, что человек разбирается, как и что конфигурить.
- Использование Typescript (да, в ТЗ указано, что можно и JS), но я бы отдал предпочтение тому кандидату, который бы прислал выполненное задание на TS
- Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.
- Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.
Рекомендую автору умерить свое негодование. Да, у каждого из нас огромное самомнение и все мы любим, что бы нас хвалили и говорили какие мы крутые. Но жизнь с#$@ злая и бьет разводным ключом по голове. Поэтому стоит успокоится и провести анализ ошибок.
Лучше всего, поставить себя на место работодателя. Представь что тебе нужен человек в команду и с которым ты будешь работать не один год. Как бы ты спрашивал, на что бы смотрел итд?
Я сам проходил через такое. Писал тестовые задания, получал негативный фидбек. Расстраивался. Но, я делал работу над ошибками, развивался.
Удачи! Я думаю, в следующий раз у тебя получится.
PS я никакого отношения к компании Aviasales не имею, и слышу о них впервые :) и данный коммент я написал и собственного опыта, сначала как соискателя, а сейчас как собеседующего кандидатов.
1. «А вот лишнего когда очень много»
Прошу показать где.
2. «Использование кучи сторонних либ, хотя можно обойтись и без них»
Какие сторонние? Их всего 3 (mobx, rxjs, react-ioc).
3. «Использование стартер китов вместо ручной конфигурации»
Я сгенерировал проект через next init. Этого не достаточно?
4. «Использование Typescript»
Я написал почему я не использовал Typescript — прошу перечитать. Но даже если переименовать файлы в ts и tsx, и добавить типов то это ничего ровным счетом не изменит.
5. «Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.»
В задании нет, мне сообщили что не надо. Надо тесты — пусть оплачивают время на разработку.
6. «Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.»
Это не дипломная и не работа на заказчика, не придумывайте. Это просто бесплатное тестовое задание. Писание документации это абсолютное иного рода деятельность, которая так же должна быть оговорена и оплачена.
7. «Поэтому стоит успокоится и провести анализ ошибок»
Какие ошибки из этого можно подчеркнуть? Можете привести «реальный пример»? Я ничего кроме чсв ревьювера не вижу. Задание сделано идеально за оговоренный промежуток времени, при этом работает быстрее и лучше приложения от самих Aviasales за счет использования Web Worker, после чего мне заявляют что нет смысла их использовать и в отзыве мне дают рейт Juniora и заявляют что я не знаю React. А само ревью написано абсолютно субъективным стилем. Обидно как то…
Задание сделано за день, как и было оговорено с HR. Я не собирался делать ничего, что заняло бы больше времени. Прошу это учесть.
Прошу показать где.
2. «Использование кучи сторонних либ, хотя можно обойтись и без них»
Какие сторонние? Их всего 3 (mobx, rxjs, react-ioc).
3. «Использование стартер китов вместо ручной конфигурации»
Я сгенерировал проект через next init. Этого не достаточно?
4. «Использование Typescript»
Я написал почему я не использовал Typescript — прошу перечитать. Но даже если переименовать файлы в ts и tsx, и добавить типов то это ничего ровным счетом не изменит.
5. «Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.»
В задании нет, мне сообщили что не надо. Надо тесты — пусть оплачивают время на разработку.
6. «Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.»
Это не дипломная и не работа на заказчика, не придумывайте. Это просто бесплатное тестовое задание. Писание документации это абсолютное иного рода деятельность, которая так же должна быть оговорена и оплачена.
7. «Поэтому стоит успокоится и провести анализ ошибок»
Какие ошибки из этого можно подчеркнуть? Можете привести «реальный пример»? Я ничего кроме чсв ревьювера не вижу. Задание сделано идеально за оговоренный промежуток времени, при этом работает быстрее и лучше приложения от самих Aviasales за счет использования Web Worker, после чего мне заявляют что нет смысла их использовать и в отзыве мне дают рейт Juniora и заявляют что я не знаю React. А само ревью написано абсолютно субъективным стилем. Обидно как то…
Задание сделано за день, как и было оговорено с HR. Я не собирался делать ничего, что заняло бы больше времени. Прошу это учесть.
Боюсь вы слышите только себя. Повторюсь — поставьте себя на место работодателя.
1. Посмотрите на mock-up и посмотрите сколько у вас компонентов, тулзов итд.
Кстати, вы могли съекономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла. Обычно, я на такие вещи просто не обращаю внимания. Верстку и джуны могут сделать. А вот структура, подходы к разработке, понимание что зачем и как, документация, тесты — вот на это всегда упор.
2. Вот именно! Все можно сделать без этих зависимостей. Вы даже не представляете тот ужас, когда бездумно вставляют зависимости, а потом билд на несколько мегабайт для одной формы с двумя кнопками.
3. Лично для меня недостаточно. Кстати, когда-то получил два отказа по хорошим позициям именно из-за генерилок. Хотя в ТЗ это не оговаривалось. Сюрприз!
4. Это ваше видение. С моей колокольни это бы показало, что человек знает как курить TS и для него нет проблем работать с React + TS.
5. Тесты должны быть и точка. Даже если о них не просили.
6. Описание должно быть. Если вы что-то разрабатываете, а тем более если планируете работать в команде и занимать должность Senior. Вы ее должны уметь писать. Грамотно, кратко и по делу. Если не умеете — вы не Senior, так, хороший мидл.
7. Жаль, что вы не видите ошибок. Но это дело наживное. Со временем, вы пересмотрите свои взгляды, ну или смените род деятельности. Так тоже бывает.
Пока обида застилает вам глаза. Стоит успокоиться, и через пару недель вы будете видеть все в другом цвете.
Что касается рейти джуна — мне кажется вы не правы. Поймите, люди ищут в команду человека. И бывает, проще взять мидла чем сеньора. Потому что, иногда вырастить из мидла сеньора значительно проще и быстрее, чем переделать сеньора. Потому что сеньор так видит, а все остальные тупые и только он прав и есть только два мнения в мире — его и неправильное. И сейчас вы именно напоминаете мне такого человека. И поверьте, работать с такими очень тяжело и непродуктивно. Проще уволить.
В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общатся. Тогда такому влиться в команду будет очень легко.
1. Посмотрите на mock-up и посмотрите сколько у вас компонентов, тулзов итд.
Кстати, вы могли съекономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла. Обычно, я на такие вещи просто не обращаю внимания. Верстку и джуны могут сделать. А вот структура, подходы к разработке, понимание что зачем и как, документация, тесты — вот на это всегда упор.
2. Вот именно! Все можно сделать без этих зависимостей. Вы даже не представляете тот ужас, когда бездумно вставляют зависимости, а потом билд на несколько мегабайт для одной формы с двумя кнопками.
3. Лично для меня недостаточно. Кстати, когда-то получил два отказа по хорошим позициям именно из-за генерилок. Хотя в ТЗ это не оговаривалось. Сюрприз!
4. Это ваше видение. С моей колокольни это бы показало, что человек знает как курить TS и для него нет проблем работать с React + TS.
5. Тесты должны быть и точка. Даже если о них не просили.
6. Описание должно быть. Если вы что-то разрабатываете, а тем более если планируете работать в команде и занимать должность Senior. Вы ее должны уметь писать. Грамотно, кратко и по делу. Если не умеете — вы не Senior, так, хороший мидл.
7. Жаль, что вы не видите ошибок. Но это дело наживное. Со временем, вы пересмотрите свои взгляды, ну или смените род деятельности. Так тоже бывает.
Пока обида застилает вам глаза. Стоит успокоиться, и через пару недель вы будете видеть все в другом цвете.
Что касается рейти джуна — мне кажется вы не правы. Поймите, люди ищут в команду человека. И бывает, проще взять мидла чем сеньора. Потому что, иногда вырастить из мидла сеньора значительно проще и быстрее, чем переделать сеньора. Потому что сеньор так видит, а все остальные тупые и только он прав и есть только два мнения в мире — его и неправильное. И сейчас вы именно напоминаете мне такого человека. И поверьте, работать с такими очень тяжело и непродуктивно. Проще уволить.
В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общатся. Тогда такому влиться в команду будет очень легко.
1. «Посмотрите на mock-up и посмотрите сколько у вас компонентов, тулзов итд.»
И что тут не так? Зато все читаемо на ура
2. «Кстати, вы могли сэкономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла.»
Вот именно!
3. «Вот именно! Все можно сделать без этих зависимостей»
Тогда появятся новые файлы с новыми функциями, которые придется покрыть тестами.
Вы явно противоречите самому себе. Извините, но вы явно видите мир не так, как и я, и это нормально. И диктовать всем, что ты работаешь не так, ты не сениор и тд, когда никто даже не может нормально ответить кто такой сениор, как то не корректно. Может это вы смените род деятельности, чтобы понять что вы не правы?
«Жаль, что вы не видите ошибок»
Проблема что вы тоже тут не видите ошибок, а сами заявляете что они есть.
«В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общаться. Тогда такому влиться в команду будет очень легко.» — работать с таким ревьювером я не пожелаю никому. Но вы переводите косяк на меня, спасибо.
И что тут не так? Зато все читаемо на ура
2. «Кстати, вы могли сэкономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла.»
Вот именно!
3. «Вот именно! Все можно сделать без этих зависимостей»
Тогда появятся новые файлы с новыми функциями, которые придется покрыть тестами.
Вы явно противоречите самому себе. Извините, но вы явно видите мир не так, как и я, и это нормально. И диктовать всем, что ты работаешь не так, ты не сениор и тд, когда никто даже не может нормально ответить кто такой сениор, как то не корректно. Может это вы смените род деятельности, чтобы понять что вы не правы?
«Жаль, что вы не видите ошибок»
Проблема что вы тоже тут не видите ошибок, а сами заявляете что они есть.
«В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общаться. Тогда такому влиться в команду будет очень легко.» — работать с таким ревьювером я не пожелаю никому. Но вы переводите косяк на меня, спасибо.
Не переживай. По факту, за день ты сделал довольно большой кусок функционала и писать вещи в стиле «В общем, в React не получилось :(» в таких случаях позволяют себе только ЧСВ-шники 81 лвл-а (которых в front-end каждый второй). Вопрос, надо ли тебе работать в такой команде? Твой затраченный день стоит, как минимум, вежливости со стороны этих js гуру.
У наших HR нет аккаунта на Хабре (shame!), поэтому, просили передать.
Максим, привет!
Спасибо за пост, наверняка он будет кому-то полезен.
Для нас в Aviasales важно, как кандидаты подходят к выполнению нашего тестового задания, ведь оно максимально приближено к боевым задачам, с которыми будущему разработчику предстоит столкнуться. Твоя реализация нас не устроила и мы написали почему. Возможно, мы были резки в некоторых формулировках, за что приносим извинения, но мы ни в коем случае не хотели тебя обидеть.
Мы всегда стараемся давать подробную обратную связь, чтобы у кандидата была возможность проанализировать свою работу, учесть замечания. Или наоборот, сделать вывод, что кандидат умнее ревьюеров, которые не умеют в программирование и слава б_гу не сложилось. Это как проверка на совместимость: подход команды VS подход кандидата, и ничего личного.
Желаем найти работу на достойном уровне!
P.S. Мы по-прежнему в поиске, вакансия еще открыта :wink:
Максим, привет!
Спасибо за пост, наверняка он будет кому-то полезен.
Для нас в Aviasales важно, как кандидаты подходят к выполнению нашего тестового задания, ведь оно максимально приближено к боевым задачам, с которыми будущему разработчику предстоит столкнуться. Твоя реализация нас не устроила и мы написали почему. Возможно, мы были резки в некоторых формулировках, за что приносим извинения, но мы ни в коем случае не хотели тебя обидеть.
Мы всегда стараемся давать подробную обратную связь, чтобы у кандидата была возможность проанализировать свою работу, учесть замечания. Или наоборот, сделать вывод, что кандидат умнее ревьюеров, которые не умеют в программирование и слава б_гу не сложилось. Это как проверка на совместимость: подход команды VS подход кандидата, и ничего личного.
Желаем найти работу на достойном уровне!
P.S. Мы по-прежнему в поиске, вакансия еще открыта :wink:
Когда хабр успел из технического «журнала» превратиться в площадку, где можно поныть о заваленном тестовом? Извините за мою прямоту, но кажется это не подходящий контент для хабра.
Максим, привет!
Спасибо за пост, наверняка он будет кому-то полезен.
Для нас в Aviasales важно, как кандидаты подходят к выполнению нашего тестового задания, ведь оно максимально приближено к боевым задачам, с которыми будущему разработчику предстоит столкнуться. Твоя реализация нас не устроила и мы написали почему. Возможно, мы были резки в некоторых формулировках, за что приносим извинения, но мы ни в коем случае не хотели тебя обидеть.
Мы всегда стараемся давать подробную обратную связь, чтобы у кандидата была возможность проанализировать свою работу, учесть замечания. Или наоборот, сделать вывод, что кандидат умнее ревьюеров, которые не умеют в программирование и слава б_гу не сложилось. Это как проверка на совместимость: подход команды VS подход кандидата, и ничего личного.
Желаем найти работу на достойном уровне!
P.S. Мы по-прежнему в поиске, вакансия еще открыта ;)
Спасибо за пост, наверняка он будет кому-то полезен.
Для нас в Aviasales важно, как кандидаты подходят к выполнению нашего тестового задания, ведь оно максимально приближено к боевым задачам, с которыми будущему разработчику предстоит столкнуться. Твоя реализация нас не устроила и мы написали почему. Возможно, мы были резки в некоторых формулировках, за что приносим извинения, но мы ни в коем случае не хотели тебя обидеть.
Мы всегда стараемся давать подробную обратную связь, чтобы у кандидата была возможность проанализировать свою работу, учесть замечания. Или наоборот, сделать вывод, что кандидат умнее ревьюеров, которые не умеют в программирование и слава б_гу не сложилось. Это как проверка на совместимость: подход команды VS подход кандидата, и ничего личного.
Желаем найти работу на достойном уровне!
P.S. Мы по-прежнему в поиске, вакансия еще открыта ;)
Так и можно было ответить с вашей стороны. А не грубо в той форме который вы написали. Я не думаю что много кто либо напишет прототип так быстро с представленным качеством, от чего было и неприятно вдвойне, когда мы заранее все обговорили.
Связи с общественностью (СО или PR) — это искусство и наука достижения гармонии посредством взаимопонимания, основанного на правде и полной информированности.
Sign up to leave a comment.
Опыт разработки тестового задания на React для Aviasales