Это мнение автора. Публикация описывает личный опыт и не является установленным редакцией или судом фактом. Компания может опубликовать ответ.
- Автор
- Иван
- Дата
- Место работы
- Великий Новгород
Вкратце:
- Отсутствие деловой этики и культуры делового общения.
- Документ с тестовым заданием оформлен небрежно и допускает двусмысленную трактовку.
- Неадекватный метод оценки выполнения заданий: проверяющий ожидает реализацию функционала, который не заявлен в ТЗ.
Теперь подробно.
ТЗ не запрещает использовать STL, в некоторых заданиях даже поощрает явно это указывая.
На использование STL наложено только одно ограничение - нельзя использовать те средства библиотеки, которые являются прямым решением задачи. Скажем, если требуется реализовать сортировку пузырьком, то, естественно, нельзя брать готовую функцию типа bubble_sort, это понятно.
Одно из заданий - перевод числа из десятичной системы счисления в двоичную. Для решения задачи был выбрал контейнер map из STL, который, очевидно, не является прямым решением, и был использован как вспомогательное средство - в нем просто хранились промежуточные и итоговые данные.
Но в ответном письме я получил раздраженный комментарий (дословно): "Алгоритм-то рабочий, но сказано же не использовать STL. Ну и сразу вопрос - зачем оно так?" На что я сделал отсылку к ТЗ (еще раз напомню, что ТЗ не накладывает абсолютного запрета на STL) и дал комментарий по своей реализации.
Далее. В другом задании необходимо было реализовать столкновение движущихся кругов. Кроме базовой формулировки задачи была дана рекомендация по фреймворку для отрисовки - SFML.
В ответном письме получаю сообщение "минус балл" за то, что не была реализована фильтрация коллизий, о которой в ТЗ не было сказано абсолютно ничего. Причем, очевидно, что фильтрация коллизий - средство оптимизации и не является необходимым условием для корректной реализации коллизий в принципе.
То есть, человек получает минус балл не потому что он не справился и задача оказалась ему не по силам и ему не хватило компетенций, а потому что он просто напросто не знал, что проверяющий хочет, чтобы была реализована фильтрация коллизий.
Два замечания были по делу и в одном задании действительно была небольшая ошибка.
Но в целом, желание работать с такими людьми пропало уже после первого сообщения.
Дальнейших комментариев на свои ответы я уже не получил, единственная ошибка во всем тестовом, о которой мне сообщили, мной была исправлена сразу же.
Спустя время HR написала, что решили искать более опытного человека. Надеюсь, что она имела ввиду тех. лида, который будет более внимателен и адекватен.
Что было отмечено положительно:
Интересное тестовое задание.
- Отсутствие деловой этики и культуры делового общения.
- Документ с тестовым заданием оформлен небрежно и допускает двусмысленную трактовку.
- Неадекватный метод оценки выполнения заданий: проверяющий ожидает реализацию функционала, который не заявлен в ТЗ.
Теперь подробно.
ТЗ не запрещает использовать STL, в некоторых заданиях даже поощрает явно это указывая.
На использование STL наложено только одно ограничение - нельзя использовать те средства библиотеки, которые являются прямым решением задачи. Скажем, если требуется реализовать сортировку пузырьком, то, естественно, нельзя брать готовую функцию типа bubble_sort, это понятно.
Одно из заданий - перевод числа из десятичной системы счисления в двоичную. Для решения задачи был выбрал контейнер map из STL, который, очевидно, не является прямым решением, и был использован как вспомогательное средство - в нем просто хранились промежуточные и итоговые данные.
Но в ответном письме я получил раздраженный комментарий (дословно): "Алгоритм-то рабочий, но сказано же не использовать STL. Ну и сразу вопрос - зачем оно так?" На что я сделал отсылку к ТЗ (еще раз напомню, что ТЗ не накладывает абсолютного запрета на STL) и дал комментарий по своей реализации.
Далее. В другом задании необходимо было реализовать столкновение движущихся кругов. Кроме базовой формулировки задачи была дана рекомендация по фреймворку для отрисовки - SFML.
В ответном письме получаю сообщение "минус балл" за то, что не была реализована фильтрация коллизий, о которой в ТЗ не было сказано абсолютно ничего. Причем, очевидно, что фильтрация коллизий - средство оптимизации и не является необходимым условием для корректной реализации коллизий в принципе.
То есть, человек получает минус балл не потому что он не справился и задача оказалась ему не по силам и ему не хватило компетенций, а потому что он просто напросто не знал, что проверяющий хочет, чтобы была реализована фильтрация коллизий.
Два замечания были по делу и в одном задании действительно была небольшая ошибка.
Но в целом, желание работать с такими людьми пропало уже после первого сообщения.
Дальнейших комментариев на свои ответы я уже не получил, единственная ошибка во всем тестовом, о которой мне сообщили, мной была исправлена сразу же.
Спустя время HR написала, что решили искать более опытного человека. Надеюсь, что она имела ввиду тех. лида, который будет более внимателен и адекватен.
Что было отмечено положительно:
Интересное тестовое задание.