Искали статеечку с жалобами джуна о несправедливости IT? Так вот же она!
В чём суть истории
Подал резюме в Lesta Studio. HR связалась, рассказала о командах. Назначили технический собес. Задавали вопросы по C++, на всё ответил. На вопросы по ОС показал себя плохо. В итоге сошлись на том, что нужно дать мне тестовое задание на многопоточку. До свиданья, до свиданья, вам HR пришлёт задание.
В итоге HR сообщает, что тестовое изменили, и теперь ты будешь делать на Qt редактор списка объектов. Срок неделя. Классика.
Ну ОК, установил Qt на комп (это заняло больше суток, ибо установщик работает лишь через VPN, а все бесплатные жесть какие медленные).
Само задание, если коротко: программа редактор списка игровых объектов. В ней должна быть возможность создавать файлы списков, сохранять их на комп, открывать внутри себя ранее созданные, чтобы просматривать или редактировать. Должна быть формочка для создания нового игрового объекта, чтобы было чем наполнять список, плюс нужно предусмотреть несколько базовых типов, которые уже есть при старте приложения, таких как "игрок" или "стена". Во время редактирования прога должна показывать, что есть несохраненные изменения, а также должны быть кнопочки undo\redo, если успете.
Разработка
Qt наконец-то установился. В начале зачем-то начал искать в базовых объектах какую-то логику, чтобы можно было через фабрику или абстрактную фабрику наполнять объект различными свойствами. Я это видел примерно как в Unreal Engine с их системой добавления переменных. Вот если сделал переменную типа float, то появилась GUI, чтобы двигать ползунок или вписать точное float значение, или если это строка, вместо этого открывался TextEdit, а если нужен объект, который работает по принципу union, выпадал список для выбора одного конкретного значения.
В общем, это только Core программы, а я прям застрял и часто переписывал код. Всё же пришёл к тому, что я слишком усложняю задачу, это ведь всего лишь тестовое задание, люди на том конце просто хотят увидеть, как чел пишет код, а значит мои переусложнения бесполезны. Сделанная работа лучше идеальной, сказал себе, тем более всего неделя дана.
Остановился на том, чтобы считать все свойства объектов строками. Написал небольшой парсер, дабы писать созданные файлы в специальном формате и при чтении потом на их токены можно было в дальнейшем накручивать дополнительную логику. Чтобы и имя объекта, и свойство, и описание свойства или объекта можно было легко отделить.
Это позволило выделить базовые типы объектов, о которых было сказано в тестовом, в отдельный файл и сделать из него нечто вроде БД, а в будущем это позволило бы легко изменить этот файл и в прогу загружались бы совершенно другие базовые типы. Вроде как достаточно гибко.
Примерно на этом этапе понял, что осталось 3 дня до сдачи, а у меня даже GUI не готово толком.
Я окончательно перешёл в режим кранча, формочку для создания объектов урезал лишь до возможности добавления объекту максимум до 2-х свойств, ибо о полноценной расширяемости не сказано в тексте задачи, а если обратят внимание, то легко докручу. Да и вообще, это ведь не главное. Главное – чтобы код был хороший (Да-да, наивный я, из прошлого).
Последним штрихом стало разграничение всех состояний основного окна приложения, чтобы я мог просто позвать одну функцию, передать ей аргумент из enum-а, а она мне все нужные кнопки делала активными, а другие прятала, какие-то scrollArea чистила и т.д. С таблицей состояний стало значительно удобнее.
Последние 2 ночи я просто не спал и сбил свой режим с намерением успеть допилить код. Добавил два стека для нормальной реализации undo\redo функций, которые были в тестовом не обязательны, а как задание со звёздочкой. Залил всё на Git, сделал ReadMe файл, оформил описание сценариев работы приложения с картинками, почти как настоящая документация, хе-хе.
Отдал всё HR. Через неделю приходит ответ и начинается самое интересное.
Результат
«К сожалению, показанный уровень выполнения тестового задания недостаточен для рассмотрению на позицию junior»
Штааа? 😯
«Если смотреть на инструментарий, для нас очень важно, чтобы при разработке задавались вопросы типа «для чего мы это делаем?», «как это будет использоваться?» и т.д.»
Для чего делаем? Чтобы увидеть мои навыки программиста. Как будет использоваться? Никак. Это тестовое задание. Или я чего-то не знаю?..
Дальше идёт список того, чего в моём приложении нет. Об этом не было написано в тестовом, и поэтому сначала подумал, что мне стоило догадаться добавить это самому.
Один интересный пункт был «Рефлексия отсутствует (можно было хотя бы попробовать использовать рефлексию из Qt)». Стал искать инфу о рефлексии в C++. Оказывается, в сам язык хотят добавить её лишь в 2026 году… А в Qt она да, действительно есть. Я о ней никогда не слышал, ибо Qt всё же не основной мой инструмент, да и планировалось изначально вообще дать тестовое на многопоточку. Мне удалось решить задачу и без рефлексии ведь, почему это плохо?
«Несмотря на недочёты выше не могу не отметить довольно чистый код, и наличие Undo/redo как бонуса. Будем рады рассмотреть вас вновь в следующем году, при условии «работы над ошибками»».
Рефлексия результата
Долго пытался понять, что сделал не так. Ведь я просто взял и выполнил тестовое задание. Ну да, не добавил того, что не было сказано добавить, но они похвалили за чистый код. Спасибо, значит чтения одноимённой книги и разных других стандартов не прошли даром.
А потом понял в чём основная причина. Я не задавал вопросы. Оказывается, это было экспресс моделирование за одну неделю, как будущий сотрудник будет вести себя на работе. А раз он не задал ни одного вопроса, значит и на работе он будет вести себя так же – не собирать обратную связь, не уточнять детали после получения задачи. Ну-да ну-да, это хреновый программист. Сразу видно – слабые soft skills. Логично.
Проблема лишь в том, что у меня уже была работа, и я вёл себя на ней не так. Для всех своих приложений на Qt собирал полно инфы, чтобы обеспечить удобный user experience.
Я не задавал вопросы по другой причине. Скажем так, делать тестовое и быть на работе – совершенно 2 разных процесса. Одно дело, когда ты можешь написать коллеге в чат, или подойти и спросить его в соседнем кабинете, а другое, когда перед вами буфер в форме HR. А HR, если ты задашь вопрос по тестовому в четверг, даст ответ лишь в понедельник. А сдавать задачу в среду. И разве это так должно работать? Кандидат должен либо ждать, либо писать неправильно, пока ждёт ответ, чтобы потом переписывать всё за 2-3 дня? Мне кажется это абсурд. Поэтому и не вижу смысла задавать таким образом вопросы. Я уже общался в таком формате при выполнении других тестовых, и получал ответы именно с такой задержкой.
Как по мне, логичнее оценивать человека по тому:
Какую архитектуру он сделал;
Как произвёл декомпозицию на отдельные классы;
Соблюдает ли правило 5;
Насколько безопасны его функции;
Перехватывает ли он исключения и создаёт ли собственные;
Использует ли библиотеку <algorithm> вместо того, чтобы писать велосипед;
Использует ли STL вместе с constexpr и концептами для обобщения кода;
Грамотно ли он применяет паттерны;
Насколько читабелен в целом его код (а то может он налепил магических чисел с непонятными литералами);
Пользуется ли динамическим полиморфизмом;
Написал ли unit-тесты для программы;
Насколько в целом его решение соответствует SOLID, то есть открыт ли его код для расширения и закрыт ли для изменений.
Нет, ты не задаёшь вопросы. Значит ты даже не junior. Приходи через год, может поумнеешь. Для меня это так выглядит :-\
Итог
В завершение, скажу парадоксальную вещь. Это был хороший урок. Это был очень болезненный урок, потому что у меня была надежда, что бессонные ночи, пропущенные пары и сбитый режим — это не зря. Что в этот то раз ведь должно повезти. Но нет… Эта попытка учит, что нужно ещё больше задавать вопросов собеседующим по поводу тестового задания. А что оно проверяет? А будет ли там дана полная информация? А есть ли более оперативный способ связи, чем через HR? А что для вас приоритетнее при выполнении задачи? Вот если я не успею сделать его до конца за неделю, это не будет минус, если при этом у меня будет качественный код? А как будет оцениваться качество кода? А что вы хотите увидеть? и т.д.
Тот факт, что я делюсь этой историей не делает меня хорошим человеком, не создаёт мне положительной репутации, а скорее наоборот. Но я лишь надеюсь, что для кого-то такой опыт окажется полезным. Вот вам, дети, урок: задавайте вопросы, ибо по законам тестовых заданий, там всё описано не полностью. Да и вообще, как часто говорят в интернатах – "код не важен, а важно ваше умение работать с людьми и с требованиями".
Иначе получается такая ситуация:
Да и вообще, посмотрите на этого дядю, дети. Его продолжают не брать на работу ведь не просто так. Сразу по статье видно – конфликтный, не знает программирование, коммерческого опыта лишь 1 год. Да и 100% там было что-то сказано разумное в ответе, просто он умолчал. Ну да, это правда. Они сказали, что список свойств объекта должен быть расширяемым, а не ограничиваться 2-мя. Да и вообще, почему можно создать 2 объекта с одинаковым именем? :)
Согласны\не согласны? Что думаете?
