Сообщество - Лига программистов
Добавить пост

Лига программистов

1 533 поста 11 431 подписчик

Популярные теги в сообществе:

Архитектура фронтенда на основе вертикальных слайсов

Архитектура фронтенда на основе вертикальных слайсов Кросспостинг, Pikabu Publish Bot, Frontend, Архитектура, Текст, Архитектура по, Программирование, Длиннопост

Сегодня порекомендую статью о структуре фронтенд проектов на основе вертикальных слайсов.

Автор начинает рассказ с описания структур первых проектов, где использовался подход “Разделения по техническим слоям”, в котором мы группируем файлы по функциональности, а не по доменной области:

- api/services
- components
- stores
- constants
- и т.д.

и затем описывается, как этот подход всё ещё используется внутри “вертикальных слайсов”.

Разделение по техническим слоям

Плюсы подхода

- хорошо работает для маленьких проектов
- у слоев есть однонаправленный поток использования, и нельзя импортировать файлы из слоев, находящихся на уровне выше (например сторы могут использовать api, а страницы могут использовать базовые компоненты, но не наоборот).

Проблемы подхода

- Даже для небольших продуктовых фичей приходится править код по всему проекту, так как он раскидан по разным папкам
- Неявные связи в рамках конкретных слоев: бизнес компоненты (ProductCard, UserProfile) смешиваются c UI компонентами (Link, Button) в components, то же самое касается бизнес логики

«Vertical sliced» подход

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

По сути, мы берём структуру “разделения по техническим слоям” и делаем разрез по фичам. То есть, создаём папку для каждой фичи, внутри которой все файлы относятся только к этой фиче и “разделены по техническим слоям”.

ℹ️ Описание папок

- shared - тут хранятся всё, что можно переиспользовать и не зависит от определённой бизнес фичи. Например в shared/components будут лежать, обычные кнопки, радио кнопки и прочее
- domain - базовый UI для бизнес-сущностей (домена) проекта, например карточка товара. Простая аналогия (но не совсем правильная) - в домене можно хранить все то, что хранится в базе данных на бекенде.
- features - самодостаточные компоненты — большие бизнес сущности приложения, например корзина. Для реализации фичи, скорее всего будет использоваться несколько компонентов из доменной области.
- pages - страницы приложения.

✅ Плюсы подхода

- Когда необходимо внести изменения в фичу — все изменения происходят внутри одного слайса.
- На выходе получаем высокое зацепление (high cohesion) внутри слайса и низкую связанность (low coupling) между разными слайсами
- Сохраняется правило однонапревленного использвания: pages ⇒ features ⇒ domain ⇒ shared
- Фичи не могут напрямую использовать друг друга
- На самом нижнем уровне используется “разделение по техническим слоям”

Чтобы обеспечить однонаправленный поток использования можно взять eslint c плагином import/no-restricted-paths.

https://t.me/cherkashindev/128

Показать полностью

Собеседование SQL Select

Здравствуйте, господа и дамы! Начал изучать SQL. Хочу как все попасть в финтех сектор. (хочу много деньгов и ДМС и чтоб работодатель немного за человека считал).

Вижу себя на позиции аналитика(для разработки-инженера туповат). Ищу человек, у которого есть желание провести тестовое собеседование со мной на знание SQL блок Select. Дать обратную связь и указать куда копать в изучении SQL. Могу ли писать в резюме знание SQL.

Чтоб понимали уровень прочитал: "Изучаем SQL"/"SQL за 5 минут". Решил порядка 50 задач на SQL-EX. Посмотрел Ютуб тематические каналы.

Если знаете другие способы узнать свой уровень, буду признателен.

На реальном собеседовании был, прошел на позицию экономиста с знанием SQL за 45тыс.

Code praying

Code praying

История про опыт работы в компании Кошелёк – мобильное приложение

История про опыт работы в компании Кошелёк – мобильное приложение Истории из жизни, IT, Работа, Профсоюз, Длиннопост

Проработал там около 2 лет. Поначалу всё было круто: были плюшки, в частности, на ланч, была крутая команда. Но это длилось месяцев 7-8, потом же пошла дичь. Плюшки начали убирать: оплаты курсов не стало (как изначально было обещано в вакансии), мерч стал платным, индексация чисто на мороженое и всего 1 раз за 3 года.

Изменения начались, когда компания продалась компании Тинькофф. С этого момента развивались исключительно сервисы Тинькофф. Целью компании стало перелить пользователей приложения в приложение Тинькофф и заставить выпустить кредитку. Сменили инфраструктуру приложения на тиньковскую и мигрировали всех пользователей туда – считай, слили данные. Руководителей стали нанимать по знакомству, и они начали творить хаос.

Конкретно мой руководитель зашёл с фразами «я 25 лет в ИТ, я знаю как надо – на 3 разработчиков 1 тестировщик». И неважно, чем занимается команда и конкретно тестировщик. Неоднократно был пойман на обмане и плёл интриги:

– говорил, что открыл найм, но HR даже не в курсе;

– обещал премии за внедрение большой фичи и нашёл причину, чтобы эти премии не выплачивать;

– тасовал команды, переводил работников в другие команды без предупреждения и обсуждения;

– вынуждал добавлять себя для оценки на перфоманс-ревью;

– оценил работу человека за полгода, сам работая всего 2 месяца;

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

– развёл атмосферу интриг и стресса в своей вертикали.

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

Компания пытается обмануть при увольнении. Менеджер вертикали не выплатил обещанную премию. Из положенной премии в 0.9 оклада пытались дать 0.4, пришлось выбивать через ссоры и разбирательства. Случайно «забыли» компенсировать больничный при увольнении, пока им не напомнили.

Компания позволяет работать по ГПХ из-за границы, но это палка о двух концах. Было немало случаев, когда людей, работавших по ГПХ, ставили перед фактом увольнения, работник никак не защищён!

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

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

Корпоративы крайне тухлые, 80% проходят в офисе с пиццей и вином, вкусовые предпочтения никак не учитываются, иногда заказывают что-то для веганов. В корпоративе на природе даже еды не было, только закуски и вино, за которыми приходилось стоять в очереди, и не всем досталось. На последнем корпоративе, на котором я был, некоторым пришлось 5 часов ждать автобуса обратно. Не было организованности, люди ходили по поляне сами по себе.

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

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

Пришёл в компанию и кайфовал от команды, но после прихода друга СТО в качестве менеджера разочаровался и в итоге ушёл с осадком.

Хочешь рассказать свою историю о работе в ITприсылай нам свою историю в бота обратной связи или на почту ruitunion.org@proton.me, и мы её опубликуем.

Показать полностью 1

Как запустить новую программу на заводе за 10 дней

Дело было в 2010 году. В октябре месяце к нам в компанию позвонил ИТ-директор другого завода и пригласил в гости. Пообщаться на тему внедрения 1С. Я тут же сел в машину и поехал, всего-то 200 километров до заказчика. «Десяточка» моя пролетела их за два часа.

Когда я вошел в кабинет начальника АСУ, и мы проговорили буквально 10 минут, я понял, что Василий Иванович – наш человек. Специалист с большим опытом автоматизации, который всю свою жизнь проработал на заводе. Знает и его боль, и всех своих пользователей как облупленных. Решает поставленные задачи теми средствами, которые ему доступны. И весьма неплохо справляется, несмотря на ограничения бюджета. В общении с такими людьми у меня возникает ощущение, что мы понимаем друг друга с полуслова, и сразу устанавливается доверие.

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

Ну, надо – так надо. Я попросил посмотреть структуру завода. Василий Иванович посетовал, что она часто меняется и действующий вариант никто не знает. Точно известно только одно, что реальная структура не совпадает с официально утвержденной. Но после пары звонков он все же распечатал мне огромную портянку формата A1.

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

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

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

После этого мы с Василием Ивановичем решили, что «1C:Управление производственным предприятием» им вполне подойдет, так как следующим этапом предусматривалась автоматизация производственного планирования и учета.

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

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

Коммерческое предложение и договор были готовы за три дня. Ну а дальше началось то, что всегда происходит в серьезных конторах. Согласование проекта со стейкхолдерами. Не прошло и двух месяцев (друзья, согласитесь, в нашей предпроектной жизни – это просто миг), как мы уже подписали договор. Естественно, в редакции, подготовленной еще в октябре, и только слегка скорректированной под реалии декабря. С остановкой старых программ 31 декабря и запуском всей системы с 1 января.

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

– Как вы вообще это представляете? – спросил меня руководитель проекта Азат. – Контрольный пример не проведен, пользователи не обучены, остатков нет. Ну, остановим мы старую программу. А новая-то как заработает?

– Давай вместе подумаем. Представим нашу будущую систему в динамике, начиная прямо с 1 января. Точнее, с 10 января. Какие документы нам понадобятся в первую очередь?

– Так. Отгрузка продукции должна происходить. И оприходование материалов. Банк и касса должны обрабатываться.

– Правильно. Это человек 10–20 складских работников, бухгалтеров и финансистов. И четыре-пять видов документов. Стандартных, которые всем подходят. Если мы сделаем инструкции и попросим пользователей выйти на работу не десятого января, а, скажем, восьмого, успеем мы их обучить? Успеем. А еще мы организуем техподдержку на месте прямо с 10 января, и они смогут получить ответ на любой вопрос сразу.

– Но у них должны быть реальные остатки, иначе как они отгрузят продукцию?

– Согласен, значит, надо остатки перенести из старой системы в новогодние каникулы. Успеем?

– Успеем, только они декабрь будут закрывать до 20 января. Остатки съедут. Раньше двадцатого переносить нельзя.

– Можно, если переносить их два раза. Поэтому программу переноса нужно написать правильную. Такую, что прежде чем что-то перенести повторно, она поищет это в новой системе, исправит и допишет, но ничего не удалит.

– Ну ладно. Оперативный учет с грехом пополам мы запустим. А что делать с бухгалтерским? Мы в январе точно не автоматизируем всю бухгалтерию. А им в начале февраля сдавать отчетность за месяц.

– Не переживай. Я поговорю с главным бухгалтером.

И я поговорил. Специально для этого съездил на завод.

– Знаете, Анна Петровна, должен вас предупредить – мы не сможем сделать вам полноценный отчет за январь в новой системе.

– Ладно, я получу его из старой.

– Не получите. Мы остановим ее 31 декабря на ввод новых данных. Иначе мы не сможем запустить новую систему с 1 января. Народ просто не будет работать с новой системой, если все, что он делал раньше, он сможет делать в старой. Я уже договорился с Василием Ивановичем. Он перепишет код в старой программе и запретит ввод документов с датой старше 31 декабря. Помните, как Александр Македонский сжег корабли, когда его войско высадилось в Персии? Он не оставил своим бойцам другого шанса, кроме как разбить врага на его территории. Так и мы – сожжем мосты. То есть корабли. То есть старую программу.

– Вы что, думаете, что отчетность завода в контролирующие органы – это шутка? Как, по-вашему, я ее должна сделать и сдать?

– Не знаю даже, что сказать. Ситуация, и правда, необычная. У вас будут данные по отгрузке, приходу материалов, банку и кассе. НДС в отгрузке и к зачету тоже посчитаем. Это все.

– Понятно. Ладно, придумаем что-то, используем доступные данные и статистику за прошлые периоды. Да, придется сделать корректировки позже. Ну ладно, все равно мы их делаем регулярно. В этот раз объясним, что внедрялась новая система, и в ней произошел сбой. Но когда я смогу получить реальную отчетность?

– Вы получите ее в середине апреля. Сразу за весь первый квартал.

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

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

• выявление пользователей, работу которых нельзя остановить;

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

• написание кратких технологических инструкций по работе с нужными объектами;

• обучение задействованных в запуске пользователей;

• программирование обработок по переносу данных;

• перенос и сверку перенесенных данных;

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

10 января 2011 года завод работал уже как обычно. Но в новой программе. Это был самый быстрый запуск УПП в промышленную эксплуатацию в моей жизни.

История из моей книжки "Франчайзи на грани нервного срыва". Еще больше историй в одноименной серии, подписывайтесь

Показать полностью

Как тестировать internal методы и классы в C# — InternalsVisibleToAttribute

Как тестировать internal методы и классы в C# — InternalsVisibleToAttribute Кросспостинг, Pikabu Publish Bot, Dotnet, Текст, Тестирование, Csharp

[assembly: InternalsVisibleToAttribute("YourProject.UnitTests")]

Представьте, что вы разрабатываете библиотеку, которой будут пользоваться тысячи людей 😮. Чтобы убедиться в стабильности — нужно всё хорошенько покрыть тестами. Все мы любим инкапсуляцию, верно (я надеюсь)? Поэтому мы не разрешаем использовать всё подряд из нашей сборки, а с умом используем модификаторы доступа и позволяем использовать только public классы и методы.

В C#, есть 7 модификаторов доступа, основные:

- private — доступ только внутри текущего класса
- protected — доступ внутри текущего и дочерних классов
- public — классы и методы доступны где угодно, также из сборок, использующих текущую
- internal — публичный API, внутри текущей сборки. Как public, но нет доступа из сборок использующих текущую
- остальные можно посмотреть тут

Но, C# — не JavaScript, и для тестов создаётся отдельная сборка, а internal методы в ней не доступны.

Чтобы тестировать internal функциональность, нужно использовать атрибут InternalsVisibleToAttribute, и в качестве параметра указать имя тестовой сборки. Тогда все internal методы и классы будут доступны для тестирования.

[assembly: InternalsVisibleToAttribute("YourProject.UnitTests")]

https://t.me/cherkashindev/127

Показать полностью

Проблемы чисел с плавающей точкой

Всем привет, работаю java разработчиком уже 10 лет, в этом посте хотел бы привести пример, почему нужно с опаской подходить к использованию чисел с плавающей точкой. Проблемы возникают из-за двух ограничений:

  • невозможности представить некоторые дробные числа в конечном виде в двоичной кодировке;

  • ограниченного объема памяти, выделенного для хранения значения.

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

double little1 = 0.0000000000000000000000000000000000000001;
double little2 = 0.0000000000000000000000000000000000000002;
print(little1 == little2); //false

Далее попробуем сложить эти два числа с большим, и проверим, совпадают ли суммы:

double big = 10000000000000000000000000000000000000.0;

print(big + little1 == big + little2); //true

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

Тем кто вынужден работать с нецелыми числами, рекомендую присмотреться к BigDecimal. Всем удачи!

Поиграем в бизнесменов?

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

СДЕЛАТЬ ВЫБОР

Особенности найма в Амазоне или никаких собеседований с HR

Особенности найма в Амазоне или никаких собеседований с HR Собеседование, IT, Программирование, Длиннопост

Так как БигТех начал открываться после сокращений и заморозки то я решил поучаствовать в найме программистов и сейчас расскажу об особенностях этого процесса в компании Амазон.

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


BASIC QUALIFICATIONS

- 3+ years of non-internship professional software development experience
- 2+ years of non-internship design or architecture (design patterns, reliability and scaling) of new and existing systems experience
- Experience programming with at least one software programming language

PREFERRED QUALIFICATIONS

- 3+ years of full software development life cycle, including coding standards, code reviews, source control management, build processes, testing, and operations experience
- Bachelor's degree in computer science or equivalent

2. Как только проверка пройдена вам присылают приглашение на онлайн задание, где у вас скорее всего будут алгоритмические задачи и несколько вопросов по техническому дизайну.
Решения проверяются автоматические
3. Если вы проходите онлайн тест то приходит приглашение на Phone screen интервью, где вы будете 1 час решать алгоритмические задачи и отвечать на поведенческие вопросы сотруднику Амазона работающего на соответствующей позиции или выше.
4. Если PhoneScreen пройден то вас пригласят на так называется Loop где вы на протяжении 4 часов с 4 разными людьми по часу будете решать задачи по Problem Solving, Data structures and algorithms, Logical and maintainable, System design и отвечать на поведенческие вопросы. время обычно разделяется следующий образом: 5 минут приветствие, 20 минут поведенческие вопросы, 30 минут coding, 5 минут вопросы кандидата.
В Амазоне есть правило 2&5 которое призывает обьявлять результат кандидату в течение 2 дней после Phone Screen и в течение 5 дней после Loop.
5. И вот только после того как вы успешно прошли все этапы у вас будет звонок с hr для обсуждения оффера. До этого момента никакого общения с HR у вас не будет.

Теперь расскажу все что происходит со стороны интервьюеров.

Для интервьюера все начинается с тренинга. На тренинге обучают этапам процесса, тому как вести себя на интервью и тому как вести себя не надо.
Очень запомнились следующие моменты:
1. Амазон уделяет огромное внимание тому чтоб кандидат имел положительное впечатление даже если не прошел отбор.
2. Очень важно бороться с так называемыми bias. Кандидат должен оцениваться только с функциональной точки зрения. Есть очевидные вещи типо того что нельзя оценивать человека по полу, цвету кожи и тп. Есть не очевидные - на ваше решение не должны влиять такие факторы, как то что вы учились в одном месте, родились в одном месте. Так же не должно влиять на выбор то где учился человек - в Гарварде или на курсах программирования, это ничего не говорит о том насколько этот человек будет успешен в Амазоне.
3. Строго запрещено давать feedback во время или после интервью.

После тренинга вы можете начинать учавствовать в интервью в роли помощника.

Процесс каждого интервью строится следующим образом.
1. Pre-brief.
Recruiter, Hiring manager и другие интервьюеры собираются вместе и начинают обсуждать кто какие поведенческие вопросы будет обсуждать. В Амазоне существует список компетенций вокруг которых крутятся все поведенческие вопросы. Каждому интервьюеру выделяется по 2 компетенции. Также интервьюер получает один из Problem Solving, Data structures and algorithms, Logical and maintainable, System design.
2. Интервью.
Перед интервью вы прописываете план - выбираете поведенческие вопросы из банка вопросов, которые соответствуют заданной вам компетенции. Примером может служить:
Например ваша компетенция - Have a backbone;Disagree and commit.
Одним из вопросов по этой компетенции может быть - "Расскажите о случае когда вы послали хорошую идею своему менеджеру и он не сделал ничего по этому поводу? Что вы сделали? Какой был результат.
Также вы выбираете или придумываете задачу для coding.
Пример: Logical and maintainable
Напишите set где каждый элемент имеет дату экспирации и удаляется.

На самом интервью в течение 20 минут для поведенческих вопросов вы должны копнуть кандидата по поводу наличия компетенции. Задача не просто задать вопрос но и наводящими вопросами выцепить все необходимые данные подтверждающие данную компетенцию. Как и во всех статьях о подготовке к FAANG мы действительно стараемся выстроить из ответа так называемую цепочку STAR (Situation/Task, Actions, Results). Если кандидат изначально об этом знает и рассказывает в такой последовательности то он точно будет намного ближе к цели чем кандидат который к этому не готов и будет плавать.

В течение 30 минут кодинга можно ожидать следующего. Например по задаче

Напишите set где каждый элемент имеет дату экспирации и удаляется.

от вас будут ожидать придумать решения с max/min heap или concurrent hash map,
придумать простейший garbage collector который время от времени будет удалять значения после экспирации, написать корректные public/private методы, предложить вариант для многопоточности, на senior позицию возможно придется придумать non-blocking решение с потоком выполняющим удаление элементов. От вас будут ожидать "правильных" вопросов типа "нужно ли пользователю давать доступ к методу удаления элементов после экспирации", неплохо будет написать тесты.
Совет - никогда не пишите в резюме знание языков на которых вы не сможете решить задачу. От вас могут потребовать решать на языке указанном в cv. Был свидетелем того, как кандидат не знал std::map хотя пол резюме у него было в с++. Большую часть времени он потратил вспоминая и в итоге пришел к std::HashMap
3. De-brief
Перед de brief вы заполняете feedback и голосуете - за/против. Для положительного ответа минимум трое рекрутеров должны проголосовать за. На debrief обсуждается решение. При равном счете кандидату будет отказ. Амазону дешевле не взять хорошего специалиста, чем нанять плохого.

Из советов

Показать полностью 1
Отличная работа, все прочитано!