8 липня 2024 20:05
Никита Череватый, Full-stack JS developer в Lendiron ltd
Отримав ТЗ від рекрутера, виконав завдання. Отримав фідбек майже через два тижні, в умовах ринку та стану зі світлом, ну можна зрозуміти. Не можу зрозуміти, як так можна описувати ТЗ, як це робить керівник департаменту розробки цієї компанії. З одним з недоліків з приводу виконаного завдання був згоден, можна було б декомпозувати клас, який включав у себе забагато функціоналу, все ж вирішив зекономити час (котрий раз спотикаюсь вже:))
Але казати що у розробника неправильне форматування даних на виході (правильно 0.90 а не 0.9), вхідні данні не валідуются або змінні потрібно не хардкодити, а по api отримувати і при цьому не зазначати нічого з цього у ТЗ, то я вважаю що це проблема суто того, хто складає то ТЗ. Люди інвестують свій час, виконуючі ваші тестові ще до розмови навіть з HR, безкоштовно. Виділіть дійсно важливі для вас критерії виконання тестовго завдання та винесіть їх до ТЗ. Інакше це не професійною.
Facebook
Twitter
LinkedIn
1. «Неправильне форматування даних на виході» — не розумію до чого тут блок Rounding. Данні округлювались, і ви досі намагаєтесь мене запевнити, що вивід даних у форматі «0.9», а не «0.90», це та помилка, яку потрібно пропрацьовувати.
2. «без валідації вхідних даних зловмисники можуть вставляти...» проговорення вами очевидних фактів не відміняє того, що цього не було зазначено у ТЗ. Для уточнення, у ТЗ не було Жодного слова про валідацію, тобто компанія очікувала від мене, як від спеціаліста, зацікавленість у імплементуванні того, чого навіть не було зазначено у ТЗ. І це заради можливості почати спілкуватись навіть не з технічним спеціалістом, а з Recruiting Specialist.
Ось таке відношення компанії до людей. Робіть висновки, шановні.
Добрий день, Микито.
Дякуємо за Ваш відгук. Дозвольте деталізувати та розкрити повністю топік із технічним завданням та нашим фідбеком.
Під час комунікації із нашим рекрутером Вам одразу повідомили, що тестове завдання є обов’язковою умовою для подальшого проходження на наступні етапи. Проте, виконується ТЗ за власним бажанням, на розсуд кандидата.
Щодо ваших коментарів по тестовому завданню, Ви посилаєтеся на деякі пункти. Розглянемо детальніше:
Неправильне форматування даних на виході: цей пункт не тільки описаний в ТЗ (блок Rounding працює в обидва боки), але також випливає з вказаного в ТЗ результату в блоці Expected Result. Оскільки результат не збігається, ми вважаємо завдання невиконаним.
Вимога до валідації: без валідації вхідних даних зловмисники можуть вставляти шкідливий код, що може скомпрометувати безпеку системи та бази даних. У рамках фронтенд задач і конкретно цього тестового завдання, некоректні та невалідні вхідні дані не повинні впливати на логіку розрахунків комісії і повинні залишити загальний потік розрахунків робочим у будь-якому випадку. Розглядаючи завдання як частину бізнес-логіки фронтенд додатка, валідація вхідних даних повинна запобігти некоректному UI, який буде бачити користувач. Некоректні дані — це перше, що буде перевіряти QA. Також unit-тести повинні охоплювати негативні сценарії використання. В низці галузей, таких як медицина або фінанси, існують суворі вимоги до валідації даних, щоб забезпечити їх точність та безпеку. Дана вакансія — це фінансовий проект, що тягне за собою 100% необхідність валідації навіть для дрібних функцій. Це не основний критерій, за яким ми відхилили тестове завдання, і якби він був лише один, то шанс пройти далі був би значно вищим.
Ми цінуємо Ваш час і зусилля, витрачені на виконання тестового завдання, і сподіваємося, що ці пояснення допоможуть краще зрозуміти фідбек.
З повагою, Анна.
HR-менеджер компанії GroupBWT.
1. «Неправильне форматування даних на виході» — не розумію до чого тут блок Rounding. Данні округлювались, і ви досі намагаєтесь мене запевнити, що вивід даних у форматі «0.9», а не «0.90», це та помилка, яку потрібно пропрацьовувати.
2. «без валідації вхідних даних зловмисники можуть вставляти...» проговорення вами очевидних фактів не відміняє того, що цього не було зазначено у ТЗ. Для уточнення, у ТЗ не було Жодного слова про валідацію, тобто компанія очікувала від мене, як від спеціаліста, зацікавленість у імплементуванні того, чого навіть не було зазначено у ТЗ. І це заради можливості почати спілкуватись навіть не з технічним спеціалістом, а з Recruiting Specialist.
Ось таке відношення компанії до людей. Робіть висновки, шановні.
3 коментарі
Підписатись на коментаріВідписатись від коментарівКоментарі можуть залишати тільки користувачі з підтвердженими акаунтами.