Глава отдела разработки Ecwid Василий Васильков написал о том, как кандидаты делают тестовые задания и что из этого выходит. Получилось забавно. Публикуем заметку слово в слово.
***
Я расскажу историю одного тестового задания. Немного длинную, но, надеюсь, интересную.
У нас в Ecwid все тестовые задания для инженеров выложены открыто на GitHub вот тут — github.com/Ecwid/new-job. Можно просто начать делать любую понравившуюся задачу, никого не предупреждая, а потом, когда сами будете довольны результатом, поделиться им со мной.
Одно из первых заданий, что я придумал, был консольный качальщик файлов по HTTP. Оно очень простое и придумывал я его именно с такой мыслью. Пусть, рассуждал я, пока такое простое повисит, а потом-то я, конечно, добавлю крутые задания. Потом-то я ого-го что выдумаю! Такие крутые тестовые выложу, что все ахнут и немедленно побегут их делать, а этот примитивный качальщик я куда-нибудь запрячу и никому больше не буду показывать. Как-то так я тогда думал.
Качальщик нужно сделать действительно очень примитивный. Судите сами — ты ему список ссылок в текстовом файле, а он скачивает эти файлы и кладет в указанную папку на локальном диске. Должен уметь качать несколько файлов одновременно (в несколько потоков, например, 3 потока) и выдерживать указанное ограничение на скорость загрузки, например, 500 килобайт в секунду. Всё.
Для работы с HTTP не нужно ничего изобретать, можно взять любую библиотеку. Для ограничения скорости — библиотеку. Для загрузки в нескольких потоков даже библиотеку не надо — все есть в стандартной библиотеке Java. Можно, конечно, все это изобрести и написать самостоятельно на коленке, но не обязательно. Фактически, надо взять несколько «кубиков» и аккуратно сложить их в правильную фигуру, применив немного программизма.
Этому заданию скоро три года. За эти годы я стал обладателем бесценной коллекции качальщиков всех цветов и размеров. Если жизнь заставит меня скачать что-нибудь в несколько потоков по HTTP — я спокоен как удав, у меня больше сотни решений на любой вкус.
Неудивительно, что это задание, самое простое и понятное, делает большинство кандидатов. За прошедшие годы это тестовое настолько обогатило меня новым опытом, что я уже не смогу списать его в архив, заменив на более крутые и модные задания.
Если сейчас мне пришлют еще 100 консольных качальщиков, я с уверенностью могу сказать что именно там не будет работать:
— Часть присланных работ просто не будет компилироваться. Да, работы будут на компилируемых языках Java/Kotlin, но компилироваться не будут. Локальная IT-разновидность корпускулярно-волнового дуализма, я так понимаю этот феномен. Я, конечно, немного знаком с языками на которых прошу сделать тестовое и безо всякой гордыни лично дописываю те куски, что кандидат имел в виду, но не написал, оставив мне возможность для творчества. Обычно это самые интересные работы. Приятно, что кандидат серьезно относится к будущему месту работы и не только дает возможность вам проверить его знания, но и, в свою очередь, проверяет ваши.
— Часть присланных работ будет выдерживать скорость скачки с очень широким разбросом от желаемого. Например, вы хотите скачивать со скоростью 300KB/s, а программа скачивает около 2MB/s. Разница всего в шесть раз, но зато строго 2 мегабайта в секунду и не больше. Как сказал один кандидат — «скорость выдерживается в некотором интервале туда-сюда». Мне очень понравилось и про «некоторый интервал» и про «туда-сюда». Теперь и сам стараюсь использовать этот оборот как можно чаще — «Мы сделаем эту фичу за двадцать дней, пять дней туда-сюда».
— Параллельная закачка. С одной стороны, я часто думаю убрать это требование, потому что по нему можно угадывать возраст кандидата, а я этого делать не люблю. Если вам приходит письмо с вопросом «В несколько потоков это как ReGet?», то ты сразу понимаешь, что кандидат вряд ли сильно моложе тебя и помнит времена модемов. Я вот тоже помню все эти бесконечные ReGet, FlashGet, Download Master и остальные милые сердцу интернет-приблуды конца девяностых-начала двухтысячных. Нет, качать надо не один файл в несколько потоков, а тупо несколько файлов одновременно.
Однако, с другой стороны, это требование дает неиссякаемый источник удовольствия при проверке заданий:
* Например, я хочу качать в 3 потока, а программа качает в 4. Я задаю 5 потоков — программа качает в 6. WTF? Как тут можно сделать баг? Иду в исходники и нахожу комментарий «Увеличим запрошенное пользователем количество потоков на один, чтобы качалось ещё быстрее». Хрен поспоришь.
* Другой пример — кандидат пишет «Программа умеет скачивать файлы в N потоков, однако случаи N больше одного пока не поддерживаются». Фраза прекрасна вся до последней точки. Читая утирал пот ушанкой, дивился человеческой ловкости, вспоминал анекдот про математика и камерный оркестр.
Бесконечное количество просто интересных решений от неординарных людей:
* Как вам, например, такое решение — задание просто выясняло файлы какого размера с какой скоростью надо скачать, делило размер на скорость и засыпало на полученное количество секунд. Я даже, где-то глубоко в душе, нахожу это решение логичным — программа должна работать NN секунд, она и работает, что вы докопались?! Видимо, кандидат не ожидал, что проверяющий просто возьмет и посмотрит (какое коварство!), что же программа по факту накачала. Очень хитрое решение, очень.
* А вот ещё, видимо, очень неглупый человек, который прислал один класс с пустой main-функцией (и больше ничего) и пояснил «Вот как-то в таком стиле я планирую делать это задание. Надеюсь, моя мысль уже ясна?».
Я приложил серьезные усилия рассматривая этот файл на пять строк, но, так и не добившись от файла ясности, попросил кандидата развернуть мысль пошире. Жду второй год, не теряя, однако, надежды.
* Помню прекрасного человека, который написал, что скачивание файлов по HTTP это совершенно простое задание и можно ли ему его не делать? Я ответил в том духе, что, конечно, можно не делать и мы расстались друзьями. Больше я его не слышал и не видел. Человек просто спросил меня письмом, можно ли ему чего-то не делать, я, со своей стороны, не нашел в себе сил запретить ему этого. Всё. Надеюсь, мой ответ помог человеку достичь нирваны и он ничего не делает до сих пор.
* Замечательный кандидат, сказавший, что Java он не знает и можно ли сделать задание на Go? Я сказал в том смысле что «хрен с ним, давайте на Go», на что получил ответ — «отлично, Go я тоже не знаю, вот выучу и сделаю»! Скажу честно — я горжусь знакомством (пусть и шапочным) с таким упорным человеком.
Самый интересный случай произошел со мной в Пензе (SECON, привет!) ночью на улице после after-party. Ночь, улица, людей почти нет, я стою и жду такси, чтобы уехать в гостиницу. Внезапно откуда-то из темноты ко мне подходит человек и говорит: «Василий, я пытался устроиться в Ecwid, вы мне отказали и с тех пор я очень хочу с вами встретиться лично!!».
Затрудняюсь пересказать, какие мысли пронеслись у меня в голове за эти секунды. Чувак, если ты читаешь эти строки — спасибо за опыт, ко мне никто ещё не подбегал в ночи с такими двусмысленными формулировками.
Я, собственно, хотел сказать этой несерьезной историей две серьезные вещи:
1) Уважаемые кандидаты. Вас губит нежелание выбросить сделанную работу и начать сначала. Например, вы начали делать задание, а в конце вдруг выяснили, что забыли прикрутить многопоточность. Вы в панике начинаете вставлять concurrency-костыли в ваш код, не предназначенный для этого. Не надо так делать. Самый правильный способ — выбросить все написанное и написать с нуля с учетом пропущенных требований. Серьезно. Это не production-код, здесь не место костылям.
2) Могло сложиться впечатление, что я как-то несерьезно отношусь к кандидатам и их тестовым заданиям. Это совершенно не так. Я с огромным любопытством и удовольствием проверяю каждую присланную работу. Практически каждое просмотренное задание дает новый опыт, я узнаю что-то, чего не знал раньше. Делайте тестовые таски больше, делайте чаще и присылайте мне.
Ecwid всегда в поиске разработчиков. Прямо сейчас тоже. У нас большой НЕ-legacy проект, географически распределенные кластера, серьезные нагрузки, умная команда и высокая ответственность. В общем, непросто, но интересно. Основной стек — Java/Kotlin, но так же очень нужны специалисты по ReactNative.
Ищем разработчиков практически любого уровня от junior и выше (Ульяновск, Самара). Не надо стесняться, не надо думать «подойду ли я?», надо просто делать тестовое задание или если хочется, сначала поговорить со мной, а уже потом делать тестовое. А может делать тестовое и не придется, это смотря как поговорить.
Наш стек в виде непонятных слов и аббревиатур — Java, Kotlin, PostgreSQL, Cassandra, Redis, AWS, Consul, Docker, microservices. Ну и еще полно всякого.
По всем вопросам пишите в комментариях или на join@ecwid.com
Автор: Ecwid
