Comments 72
А всё же был Александр, или Alexander, Alex?
Вопрос, а можно ли вот так выкладывать тексты тестовых. Я обычно спрашиваю "можно ли ваше тестовое выложить". И да, бывает, отказывают. Хотя юридической стороны дела не знаю.
У вас сразу две картинки с тестом про картриджи, и текст про zip-архив, да ещё с решением.
Замечу для минусующих, что речь о компании, за внятное упоминание себя способной при случае начать преследование. Об этом в статье написано.
Говоря шире, просто западная компания, которой есть дело до репутации.
Вопрос, почему вы (как минимум, 8 людей, уже поставивших минусы под моим каментом) уверены, что раскрытие их интеллектуальной собственности (а тесты для новичков составили сотрудники этой компании в своё рабочее, т.е., платное время) - это ок?
Неоплачиваемые - даже нужно. Вы потратили свое время - теперь выполненные задания работают на вас, в виде репозитория на github и ссылки в резюме на примеры кода.
Так а что они хотели в итоге?
Почтовый клиент хотели? На практике, наличие результата тестового задания - это лишь врашумительный повод отказать непонравившемуся кандидату
Пришлось раза 3 перечитать задание и описание решения, чтобы понять, что же надо сделать. Не показан пример распаковки. Может, требовалось создавать директории для каждого уровня вложенности?
Английский язык у составителя задания конкретно хромает. У автора статьи он хромает совсем сильно.
Из статьи неясно, что же именно не понравилось Александру.
Живя за рубежом, ежедневно получаю кучу имейлов с вакансиями с сайтов по работам. Некоторые пишут лично (насчёт ситуации в РФ не в курсе).
Ну рад за вас, но у меня ситуация аналогичная описанной автором.
У автора статьи он хромает совсем сильно.
Однако понять мысль и того, и другого труда не составило. Огрехи есть, но с учетом того, что язык не родной, я автом не метит в копирайтеры - не могу сказать, что полагаю это критичный. Путсть и неприятно
Касательно #4
Я смежник (ИБ с уклоном в бумажную её часть). Вакансии на линкедине действительно стали приходить заметно реже, но стоило открыть резюме на hh и обозначить как «рассматриваю входящие предложения» и за неделю пассивного висения там с тремя ручными апами пришло четверо работодателей (ритейл, банк, производство, производство), ещё один позвонил лично.
Последний из производственников пришёл через линкедин (что странно - вакансия эта висит на hh и зачем они пошли длинной дорогой мне не ясно).
Из радостного, процесс сейчас: 5 минут с HR, дальше руководитель, руководитель руководителя, оффер. Тот же найм год, три и 6 лет назад состоял и семи этапов и растягивался на месяцы.
Из радостного, процесс сейчас: 5 минут с HR, дальше руководитель, руководитель руководителя, оффер. Тот же найм год, три и 6 лет назад состоял и семи этапов и растягивался на месяцы.
Это в РФ? Ну хоть что-то приятное за последнее время.
Хх, наверное, денег много хочет за контакт, вот и оптимизировали через л'д'ин
У меня ни одного предложения в LinkedIn с 24 февраля, на hh вяло, раз в три-четыре меяца набегает 3-4 входящих сообщения и затухает.
Так его же не берут писать очерки в newyorktimes в стихотворной форме, а написать public static void main и с таким уровнем можно
Тоже сел решать задачу (на C, за незнанием Java), но у меня почему-то другая формула в решении:
return cartridges - ceil(double(cartridges * perksCost - dollars) / (recycleReward + perksCost));
По теме тестового про разбор мейла, "сказав А, говори Б", раз вы уж высказались против бесплатного тестового, то и слали бы их подальше с дальнейшим разговором на эту тему. Очень уж специфичное задание, в других условиях я бы сказал, что вы для них похоже что делали реальную таску под видом тестового.
но у меня почему-то другая формула в решении
У меня получилась такая же. Если по заданию для каждого перка надо по картриджу, то число перков ограничено сверху числом картриджей. У автора в решении в числителе доллары со знаком +, и ответ потенциально не ограничен.
cartridges - (cartridges * perksCost - dollars) / (recycleReward + perksCost) =
= (cartridges * (recycleReward + perksCost) - cartridges * perksCost + dollars) / (recycleReward + perksCost) =
= (cartridges * recycleReward + cartridges * perksCost - cartridges * perksCost + dollars) / (recycleReward + perksCost) =
= (cartridges * recycleReward + dollars) / (recycleReward + perksCost)
Джекмен - он Хью.
Я не программирую на Java, но если отойти от условий задачи, мне ваш код кажется не очень удачным даже по структуре и компановке. Тем не менее, давайте пройдемся по условиям задачи, как я их понял, и почему я считаю что вы им неудовлетворили.
1.
You need to write a CLI program that extracts files from the provided file based on the provided format. See sample output for the sample above. You must not guess input file format and the program should allow the user to specify input format in some way, as a command line argument for example.
На вход подается eml или zip файл, требуется распаковать вложенные в него файлы. Мне недоступен упомянутый пример, поэтому не знаю хотят ли они сразу распаковать все файлы рекурсивно, или только те что непосредственно вложены в указанный файл. Но не имея вводных, придерживаюсь правила: если что-то не обговорено в условиях задачи, то оно реализуется на усмотрение разработчика. Чтобы снизить уровень неопределенности тут, я бы ввел параметр -R,--recursive. Но вне зависимости от этого,
мы имеем дело, по сути, с древом архивов. Мне кажется логичным распаковать его в древо папок, чтобы как минимум можно было собрать все обратно без потерь, но это так же не обговорено, поэтому пусть еще будет параметр --flat, при указании которого все распаковывается в одну папку (теоретически они могли и собирать все из одной папки).
Вы решили всегда все распаковывать в одну папку, при этом:
Вы распаковываете только eml файлы вложенные в eml файлы;
Файлы вложенные в zip вы всегда пишете во временный
payload.eml. Zip файлы вложенные в eml вы всегда пишете во временныйpayload.zip, при чем учитывая что вы идете рекурсивно сразу на максимальную глубину вложенности, вы рано или поздно начнете перезаписывать временный файл, для которого уже открытFileInputStreamвыше по рекурсии, и вы не закончили - фатальная логическая ошибка.Если eml вложенный в eml не имеет имени, то будет назван
filename_collision_{N}.eml, не смотря на то что коллизии нет.Если eml вложенный в eml имеет имя, но файл с ним уже есть, то тоже
filename_collision_{N}.eml- теряем исходное имя.
2.
Let’s assume that someone could execute the following operations for arbitrary number of times in a random order:
- Attach EML or ZIP file to the email
- Archive list of emails to the root folder of ZIP archive So the sequence of operations is a storing format for the original set of files.
So the sequence of operations is a storing format for the original set of files.
Они говорят указали что конечный файл формируется двумя операциями выполненными в произвольной последовательности и произвольном количестве:
Добавить .eml или .zip в .eml;
Архивировать список .eml в корневую папку .zip;
соответственно формат файла отражает последовательность действий пользователя, (что не совсем правда) но как минимум это намекает на то что сначала нужно распаковать все файлы из .zip, и уже потом углубляться дальше в eml. Идти по уровням вложенности в принципе эффективнее, чем рекурсия до максимальной вложенности и обратно (у вас и это не работает), потому что так мы потенциально могли бы распараллелить обработку файлов. Если организовать распаковку файлов как список задач, расширяемый на каждом последующем уровне вложенности (если --recursive), то в минимальной реализации мы можем их обрабатывать последовательно, но у нас уже есть задел как для последующего распараллеливания, так и для возможности диалога с пользователем для каждого из файлов, например если надо перезаписать.
3.
Solution should have quite good quality, ... be able to work with real-life emails (as this one) and quite large ZIP archives.
Программа должна быть качественной и готовой к использованию (large files - это всегда про потоковую обработку, тут у вас проблемы нет). В моем понимании это значит что обработаны основные логические ошибки, но ваша кидает исключения на каждый чих. При чем, половина вашего кода - это попытка избежать логических исключений типа FileNotFoundException кидая вместо них критические, неловимые. Чаще всего IllegalArgumentException, который по вашему коду может означать и что на вход некорректный файл подали, и что на каком-то уровне вложенности файл некорректный. К примеру, вы проверяете является ли файл zip архивом или нет, и потом (в зависимости от функции) кидаете InvalidArgumentException - зачем? Если формат неверный, вызовы конструкторов FileInputStream, ZipInputStream, и MimeMessage выкинули бы как минимум более разборчивые исключения, которые можно было обработать выше. А в идеале обработать и их внутри метода, обернув в ваши логические исключения, по которым вы будете строить обработку ошибок выше.
Ощущение что вы воспринимаете нотацию исключений в Java скорее как раздражитель, и боретесь с ним.
4.
it should be covered by tests
От вас просили покрытый тестами код, но тесты ваши я даже смотреть не стал, так как сам код изначально непригоден для юнит тестов. У вас практически каждый метод работает с файлами, а единственная выведенная в программе абстрактция, - CLIParameters, почему-то прокинута везде где только можно. Даже если отбросить то что методы FileUtils.getOutputDirectory и FileUtils.getSourceFile вовсе не нужны, зачем требовать всю сущность CLIParameters на вход, вы же работаете с единственным параметром, его и требуйте - вам же еще тесты писать, если успеете.
Абстракций, имхо, действительно не хватает, а в методе processMimeMessage слишком много уровней вложенности, дядюшка Боб вряд ли был бы доволен. Мне кажется, код можно было сперва написать и так, но запастись минутами 15-30 и перед отправкой порефакторить.
Склонен согласиться со многими вашими выводами, код не идеален — но вот эти выводы не очевидны. И да, код плохо тестируется. Но я три раза писал на практике ровно такой код, и сказал бы, что эта задача не на 4.5 часа, а на 4.5 дня, если вас особо никто не гонит. Это тестовое задание, в нормальной работе после такого проводим ревью, и уже там кандидат вполне может сам рассказать, что ему в коде не нравится, и что он будет улучшать. И вот это вот ревью мне, если я нанимаю, даже интереснее кода, написанного в стрессовой ситуации. А его не было. Так что я бы оценил результат как положительный, и не знаю, чего работодатель тут выпендривается.
У СКБ Контур есть задачи на тематику "sequence of operations". Общая суть такова - программа принимает от пользователя последовательность операций, интерпретирует их и выдаëт результат. Здесь задача, грубо говоря, по отправленному файлу и последовательностью операций получить распаковку.
Конечно, из статьи и в самом деле не понято, что именно их не устроило в тестовом задании, явно не процитированы несколько сообщений из переписки, но это ещё понятно.
Интересно другое — почему выполенное «не так, как ожидалось» задание считается достаточной причиной для мгновенного отказа и прекращения разговора?
Если мы рассматриваем тестовое задание как «работу понарошку», то в реальной работе такая ситуация (несоответствие ожиданиям) встречается сплошь и рядом, и не приводит к мгновенному автоматическому увольнению разработчика. Более того, как раз с этого момента обычно и начинается реальная работа, с уточнениями, правками, расстановкой приоритетов и пр.
То есть вполне нормально, когда разработчику пишут примерное ТЗ (полстраницы, а не три тома выдуманной документации), разработчик выполняет примерное решение, а дальше уже по сделанному обоим будет легко и просто обсудить, что нужно, чтобы доделать работу.
Конечно, чем дольше разработчик работает в компании, тем меньше правок становится нужно, и со временем он начинает понимать всё с полуслова, читать между строк и сам додумывать недосказанное, но ожидать такого уровня синергии с незнакомым кандидатом вряд ли разумно.
Куда важнее было бы протестировать, как кандидат отреагирует на запросы о правках, с какой скоростью будет вносить, будет ли стремиться сотрудничать или ругаться. А там уже и самому кандидату будет виднее, складываются у них рабочие отношения или нет.
И я как интервьювер с отпытом на это реагировал как "кандидат отреагирует на запросы о правках" и что упражнение про работу стребованиями "читать между строк и сам додумывать недосказанное".
Но такие вещи я обычно устно проговаривал с кандидатами на модельной задаче в вакууме и слушал какие вопросы он задает, как рассуждает. Тут не бывает идеальных случаев, смотришь как рассуждает: garbage in -> garbage out или уточнения.
У нас этот диалог был осложнен тем, что это была переписка в почте а не чате и не личное общение. И разница в часовых поясах в 10 часов, он в GMT-5 я в GMT+5. К тому же он отвечал с приличной задержкой - работал видимо в это время.
Кстати, про что и речь, что в Apache Arrow код ревью серьезное и иногда изначальный пул реквест в итоге может измениться до неузнаваемости из за решения более общей задачи или не так как планировал сначала. По мне так мои PR в Spring framework/Boot, SchemaSpy, H2, Apache Arrow и т.п. хорошо это показывают. Навскидку как пример или этот
Мне кажется (обход всех элементов разных, но четко определенных типов) можно сделать с помощью шаблона Visitor, тогда код убудет намного лаконичнее. Такой код, на мой взгляд был бы неподдерживаемым. Как то нужно было сделать все локаничнее, ввести абстракции, разделить отвественности на интерфейсы. Но решение для такого задания, даже если оно специфическое и они его куда-то там хотят себе прикрутить, я бы никуда не прикручивал.
По-моему с тестовыми заданиями все просто - выполнять за деньги. В чем проблема тогда? Выполнили - получили приятный бонус. И работодатель не будет относиться халатно к этому и жлобов отсеете сразу. Если просто отказываетесь - то почему? Боитесь прослыть мелочным? Но день потратить - это не мелочь, лучше провести с семьей или заняться любимым делом.
Притом серьезнее отнесется к оценке. Можно договориться сразу - если решение не устроит - то 50% от стоимости + обоснование.
Вам предлагают тестовое - вы ОК, но это платно. Вы не хотите платить? Почему? Я ценю свой труд.
Имхо для европейского рынка: в данный момент не такое время, когда можно просить деньги за решение тестовых. Просто возьмут другого хорошего кандидата. Их на рынке достаточно много. Месяца 2 назад у нас был поиск staff'a и за месяц было около 80 резюме. Это больше чем достаточно. И это всё люди с очень большим опытом и очень хорошими резюме. (у нас конечно нет тестовых, но в текущих условиях ни кто бы не стал у нас платить за их выполнение, если бы были)
Месяца 2 назад у нас был поиск staff'a и за месяц было около 80 резюме.
А качество кандидатов и реальная способность выполнять работу, а не скиллы по прохождению собеседования?
Сейчас вот какое время - модные курсы наплодили тьму желающих легких денег и прокачанных в плане прохождения собеседования. КПД у них отрицательный, т.е. работу делать не смогут - только будете их обучать.
Цените себя. На самом деле хорошего спеца по прежнему найти не так просто.
Ситуация примерно как с юристами в начале 00-х. Мамы поняли что это престижно и дорого, начали всеми правдами-неправдами отдавать своих чад. Наплодили кучу юристов, однако же спецы цениться не перестали, просто более обдуманно начали подходить к системе оценки квалификации - просто диплом не показатель.
Какой-то странный у них IQ тест с цитатами
Менее странным его это не делает. Обычно задачи на неполную информацию состоят или из фигур с несколькими характеристиками, либо из чисел. То бишь чтобы было абстрактно и универсально. Лишние слова иногда бывают в психологических тестах дабы проверить какую-нибудь диссоциацию или деменцию/шизофрению, но врядли работодатель занимается таким.
Результат IQ-теста на неродном языке будет заведомо хуже. Разве что из любопытства делать.
Тест от платформы Indeed.com? Тоже приходил мне. Я даже не уверен, это работодатель его послал или сама платформа решила меня протестировать.
Задания там типа Найдите повторения и Сколько отдельных ингредиентов будет использовано для списка продуктов, где каждому дан рецепт
Тоже офигевал от этого. Вот пример вопроса.
Джекман - Хью, а не Майкл.
Относительно моего опыта по активности рекрутинга.
3 года опыта. Добавил недавно теги в резюме на HH (ну, изучил же я что-то за год, надо обновить резюме). Больше ничего не делал. За неделю 4 предложения пройти собес.
По ощущениям, было +- так же.
Жалко что автор не указал желаемую зп, или хотя бы её уровень- выше рынка, или рыночную. Потому что я бы мог понять такие тестовые при зп выше рынка, когда ищут суперзвезду. И когда соискатель хочет нормально заработать. Но когда надо гонять жсоны на обычном ентерпрайзе, такое вызывает недоумение.
Или я уже от жизни совсем отстал, и сейчас везде так, на любую позицию, на любой уровень зп?
От метода processMimeMessage у меня глаза слезиться начали. Не надо так.
какое-то нытье сплошное, я такой зайка а они не оценили. Вы решаете куда пойти работать, компания решает как организовать интервью процесс, силой никто не заставляет. Как хайринг менеджер добавлю из собственного опыта - в одной локации давали литкод, в другой тэйк хоум. Перформанс и качество кода у ребят кто прошел через литкод в разы выше, выборка порядка 100 человек, есть с чем сравнивать
Задачки на литкоде и аналогах заточены в том числе и на анализ производительности - так что может этому научить (скорее "заставить").
А вот "качество" кода там никак не отслеживается и научиться хорошему через них не выйдет.
Скорее всего дело не в том что "разработчик после литкода становится лучше", а в том что "литкодом готовы заниматься более хорошие разработчики" - "после не значит в следствии".
У нас там были разные условия, непрозрачные для кандидата — определённый список тем, шкала баллов, коэффициэнты разные, обязательность присутствия людей из других офисов (у нас были офисы в 4 локациях).
Но при этом он давал устраивающий нас результат — помогал отсеивать людей. Да, весьма вероятно, что мы отсеяли кого-то, кто мог успешно потом у нас работать. Но мы добились поставленной цели — на работу ни разу не попали люди, с неустраивающим нас уровнем технических знаний.
Некоторые кандидаты тоже давали фидбек, что наше интервью — говно. Ну окей, может быть, но для нас оно полностью рабочее и даёт нужный результат.
У нас как стандарт при поиске — созвон с hr на 10-15 мин., затем тех интервью на 1-1.5 часа и если не совсем имбецил, то оффер на ±$5к в кармане в зависимости от того как пройдешь и сколько попросишь.
«мы верим в наши процессы отбора.. .» — видимо кандидатов слишком много, иначе эта необоснованная вера быстро бы закончилась, поток индусов неиссякаем пока.
Если не секрет сколько по деньгам то можно было ожидать в случае успеха?
Тоже последнее время искал работу и сейчас витает вопрос в воздухе: Имеется N кандидатов и M вакансий. Это создаёт квадратичную сложность. Как можно её уменьшить?
Ещё бы предложил, чтобы и кандидат, и ревьюер задавали задачки друг другу, не более, чем на час. Если кандидат решает задачу первым, то можно брать. Но кто на такое согласится...
Кстати, на том же Linkedin есть беджи по хард-скиллам. Каждый из 15 вопросов. Свои профессиональные я получил, но, вот, например Python после прохождения Яндех.Практикума получить не удалось. Результат 9/10, но там есть определённый процент для прохождения. Думаю этого должно быть достаточно для уверенности интервьюера в заннии языка кандидатом.
Не могли бы вы пример файла пошарить? Посидеть вечерком, поковыряться.
Они есть в тестах в репе с реализацией
Попробуй пройди за 4 часа тестовое задание в канадскую компанию