и будет ли использовать kan 😂

Я на прошлой неделе тестовое задание делал для одного британского стартапа. Задача - написать парсер файла с логами. Каждая строчка лога содержит путь  и ip. Результатом парсинга должна быть сводная таблица с количеством уникальных посещений и количеством просмотров страниц с сортировкой по убыванию.
Мне кажется по тому как она реализована можно судить об уровне разработчика и обсудить то или иное решение которые было принято в процессе развработки.
Так вот с первого взгляда задачка простая, и можно было бы просто запилить один файл, но куда же без тестов, валидации, обработки ошибок  и гибкой структуры которая позволит в дальнейшем легко облуживать приложение, легко изменять представление отчета, конфигурировать формат входящих логов. Еще смотрят чтобы код читый был, DRY и SOLID и тп.

Если интересно, могу сбросить ссылку на гитхаб, напиши в личку

вот я бы считал добавление гибкой структуры, которая позволяет конфигурировать все, ошибкой, тебе дали задачу одноразовую, а ты ушел и пришел с фреймворком

смотря кто там собеседует.

Известная же проблема что каждый свой огород разводит - чем выше должность тем шире полномочия без обязательной отчетности по внутренним решениям.

Так и появляется очень много вещей бизнесу вредящих в виде "полезной экосисистемы" или "хорошей культуры" разработки.

Много можно песен петь о культурах - победит та, которая просто седит сейчас в голове ключевого отвественного перед бизнесом.

Это я к том что обсуждать качество и хорошесть заданий - ну вот совсем бессмысленная история. Вкусовщина полнейшая.

ну и сколько уже было "смен культур", и переписок при новом C-level-e с карт бланшем даже на персонал, то можно закопать эту стюардессу рядом с ruby.

лучшее решение то которое работает на готовых компонентах?
сдал ёлку разернутую на aws - победил?

безусловно, это же потом обсуждается, если уж совсем не наговнокодил.

решение влоб - успех?

парсер логов задача без общего решения, не понятно как оценивать результат

и не для руби кмк

кто придумал такое ТЗ - очень странный человек

Парсер логов и я запилю со своим нулевым знанием рельс )

ну тут и идет три решения которые ты можешь не угадать - или надо не тащить фреймворки и сделать в лоб на баше чтобы работало четко.

Или надо показать что ты "не повторяешься" и засыпать все на модули и притащить решения.

Или сшить из сервисов на aws мышкой и тд.

Что в голове у собеседующего сейчас модно и важно - никто не знает. А ты не узнаешь когда проиграешь собеседование потому что не угадал стратегию.

Поэтому я и говорю что вкусовщина - на собеседованиях надо давать напраления ожидаемого результата, а не в угадайки играть.

тот самый любимый вопрос "зачем" или "для чего" очень помогает друг друга понимать без необходимости вскрывать детали

а так по мне - это очень показывает уровень собеседующего, и значит там будет уже сразу не очень

с порога будешь угадывать что хотели и быть виновным не за плохие решения, а за неугаданные пути

требования будут пост фактум в приемке рассказывать - вот такое управление сразу видно

верно, в задании было сделать запуск из cli, не тащить никаких фреимворков кроме тестов.