Всем привет!
Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода.
Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделиться ею с вами.
Надеюсь, она будет вам полезна!
Задача
Для Go
Представь, у тебя есть структура, которая считает зарплату сотрудника: его KPI, премии и т. п., и создает PDF-отчет. Тебе нужно создать структуру для подсчета зарплаты и генерации отчета по менеджеру.
Учти, что премия и KPI у них одинаковый процент от зарплаты. Отличие лишь в том, что менеджер получает больше.Также, учти, что система будет жить долго и в нее должно быть легко вносить изменения
Как ты это реализуешь?
Для языков где есть классы
Представь, у тебя есть класс, который считает зарплату сотрудника: его KPI, премии и т. п., и создает PDF-отчет. Тебе нужно создать класс для подсчета зарплаты и генерации отчета по менеджеру. Учти, что премия и KPI у них одинаковый процент от зарплаты. Отличие лишь в том, что менеджер получает больше.
Также, учти, что система будет жить долго и в нее должно быть легко вносить изменения
Как ты это реализуешь?
Задача звучит просто, но в этом и ее коварность.
Можете написать свое решение и ваш уровень в комментариях)
Как ИИ решил задачу
Скрытый текст
Представь, у тебя есть структура, которая считает зарплату сотрудника: его KPI, премии и т. п., и создает PDF-отчет. Тебе нужно создать структуру для подсчета зарплаты и генерации отчета по менеджеру. Учти, что премия и KPI у них одинаковый процент от зарплаты. Отличие лишь в том, что менеджер получает больше. Как ты это реализуешь? Это архитектурная задача для Go, не пиши код, просто объясни словами, как бы ты реализовал это. Пиши кратко и опиши каждый шаг для создания правильной архитектуры.
Для реализации этой архитектуры в Go я бы использовал композицию и интерфейсы, следуя принципам SOLID.
1. Выделение базовой сущности
Создал бы общую структуру Employee (или BaseSalaryCalculator), содержащую общие поля: базовую ставку, процент KPI, процент премии. В ней реализовал бы общие методы расчета — например, CalculateBase(), CalculateKPI(), CalculateBonus().
2. Определение интерфейса
Ввел бы интерфейс SalaryCalculator с методом CalculateSalary() *Report. Это позволит легко добавлять новые типы сотрудников, не меняя существующий код генерации отчетов.
3. Композиция для менеджера
Создал бы структуру Manager, которая встраивает Employee (композиция, а не наследование). Это дает все базовые поля и методы. Отличие менеджера (большая зарплата) реализовал бы через:
Либо переопределение метода
CalculateSalary(), где вызывается родительский расчет, а затем применяется повышающий коэффициент.Либо через отдельный параметр
coefficientв структуреManager, который учитывается при финальном расчете.
4. Отделение генерации отчета
Создал бы отдельный пакет или структуру ReportGenerator, который принимает интерфейс SalaryCalculator. Это разделяет ответственность: расчет зарплаты не зависит от формата вывода (PDF). Генератор получает готовые числовые данные и формирует PDF.
5. Фабрика или конструкторы
Для удобства добавил бы функции-конструкторы (NewEmployee, NewManager), чтобы гарантировать корректную инициализацию и скрыть внутреннюю логику расчета от клиентского кода.
6. Тестируемость
Такая архитектура позволяет легко тестировать каждый компонент изолированно:
базовый расчет, логику менеджера и генерацию отчета отдельно, подставляя моки.
Учитывая, что ИИ не может задавать вопросов, его решение имеет место быть, но оно недостаточно гибкое, и вот почему:
На первый взгляд решение выглядит добротно: есть интерфейс SalaryCalculator, есть отдельный ReportGenerator, композиция вместо наследования. Но есть одна ошибка.
ИИ создал один генератор отчетов для всех. Он принял как данность, что отчет для сотрудника и менеджера одинаковый, и заложил это в архитектуру.
А что будет, когда завтра бизнес скажет:
«В отчете менеджера нужно показывать количество подчиненных»
«У сотрудника добавить график выполнения KPI по месяцам»
При текущей архитектуре у нас два пути:
Напихать
if employee.Type == "manager"внутрьReportGeneratorПереписывать архитектуру с нуля
Ни один из них не подходит для поддерживаемой системы.
Более гибко было бы:
Добавить интерфейс, который реализуют классы-шаблоны для отчетов, и еще один, который реализуют классы расчета ЗП.
Каждый шаблон сам знает свой класс. В нем хранится ссылка на класс расчета ЗП для этого типа сотрудника.
Фабрика отчетов принимает интерфейс и не знает, кто именно пришел — сотрудник или менеджер.
Проблемы которые заложены в условии задачи
Эти проблемы, нужны для того, чтобы кандидат обратил на них внимание, и исправил или начал задавать вопросы и с учетом ответов выдавать свое решение.
класс, который считает ЗП сотрудника ... и создает отчет
Большинство кандидатов даже не замечают нарушения SRP. Они берут условие как данность и начинают наследоваться от этого класса. А правильно — сначала сказать: «Этот класс делает две вещи, давайте разделим».
Учти, что премия и KPI у них одинаковый процент от ЗП
Кандидат слышит «одинаковые» и думает: «Ну раз одинаковые, можно обобщить». У сотрудника и менеджера разные причины для изменения формулы расчёта. Сегодня они одинаковы, а завтра — нет. Вероятность изменения расчета премии для менеджера или сотрудника низкая, но может меняться каждый месяц. Также мы можем добавлять новые сущности. Поэтому важно их разделять
Отличается только оклад
Фраза «отличается только оклад» создаёт иллюзию, что менеджер — это просто сотрудник с большей цифрой. Менеджер — другая бизнес-сущность с другими KPI, другими зонами ответственности и другими причинами для изменения системы мотивации.
Критерии оценки задачи
В этой задачи важно:
Какие вопросы задает кандидат. Как он на них основывает свои решения.
Какие плюсы и минусы он видит в своем решении
Как он планирует действовать при внесении изменений в систему
Одно из возможных решений
Я привел одно из возможных решений. Но кандидат может предложить другое — я буду оценивать аргументацию, а не совпадение с моим вариантом.
Разделить расчет ЗП и создание отчета на разные модули.
Разделить расчет ЗП и создание отчета на разные классы/структуры для работника и менеджера.
Создать фабрику для генерации PDF-отчетов, чтобы она принимала на вход структуры/классы, которые реализуют определенный интерфейс, который будет гарантировать, что они имеют нужные методы.
Также структуры для расчета ЗП должны реализовывать свой интерфейс, который будет гарантировать, что они имеют все методы, нужные для создания отчета. А в шаблоне отчета сохранять ссылку на класс расчета ЗП для этого типа сотрудников.
Заключение
Надеюсь, эта задача будет для вас полезна и вы возьмете ее на вооружение :-)
Комментарии (84)
VitaminND
26.03.2026 06:25куда то мы свернули не туда.
Менеджер - не сотрудник? Сотрудник. Наследуем менеджера от сотрудника и переписываем у менеджера только те методы, которые для него работают не так.
Иначе для сотрудника - один класс, для менеджера - другой. Для менеджера менеджера - третий, для бабы Клавы из проходной - четвертый, и понеслось...
neoclar
26.03.2026 06:25баба Клава из проходной - не сотрудник! Создаём класс Человек...
ой, не туда свернули
ncix
26.03.2026 06:25Иначе для сотрудника - один класс, для менеджера - другой. Для менеджера менеджера - третий
А вы когда наследуетесь, классы-наследники в таком же количестве не создадите?
BobovorTheCommentBeast
26.03.2026 06:25Учти, что премия и KPI у них одинаковый процент от ЗП
Нарушение SRP тут же, а в первом случае это просто раздутый класс и понапиханно.
MountainGoat
26.03.2026 06:25А если завтра начальство скажет отчёты делать не в PDF, а в ODT? Почему вы не предусмотрели, чтобы сначала данные для отчёта складывались в универсальную структуру, из которой уже класс генератора отчётов будет генерировать отчёт.
А если начальство скажет добавлять к отчёту графики? Нужно было предусмотреть, чтобы в структуре с данными для отчёта можно в будущем добавлять поля новых типов, для этого каждое поле должно быть объектом класса, реализующим общий интерфейс.
А если начальство скажет, что отчёт – это чувствительная информация, почему не предусмотрели возможность шифрования?
Менеджер — другая бизнес-сущность с другими KPI
Это у вас другая, а у меня - не другая. В задании об этом ни слова.
Так и пишите: требуются прорицатели, шар свой.
simple-mortal
26.03.2026 06:25А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
А если начальство скажет добавлять к отчёту графики?
А если начальство скажет, что отчёт – это чувствительная информация
Всё так! Эти вопросы не столько, наверное, из области архитектуры, сколько из области бизнес/системного анализа, в который программисты последнее время умеют всё меньше и меньше, потому что нет времени. Нужно литкот задротить.
Ну и опыта в разработке систем для людей, а не программ в вакууме тоже многим не хватает. Это то, что сейчас называют "софт скилами" — навык выяснить требования. Видно, что у вас есть опыт работы с заказчиком.
Romatio
26.03.2026 06:25Вот когда скажет, тогда и начнем. Иначе месяц потратим на красивую структуру, которая может чуть больше, чем ничего.
ivashka138 Автор
26.03.2026 06:25А если завтра начальство скажет отчёты делать не в PDF, а в ODT?
Класс для генерации отчета хранит данные и ссылки на другие классы для получения данных. А класс для генерации pdf реализует только логику генерации, значит, если начальство скажет перевести в ODT, мы сможет легко изменить метод генерации, без изменения остальных данных, или добавить новый класс для генерации в ODT
А если начальство скажет добавлять к отчёту графики?
Тогда можно расширить существующие классы данными + добавить класс реализующий отрисовку графиков
почему не предусмотрели возможность шифрования
Можно расширить класс для генерации отчета функцией шифрования
Это у вас другая, а у меня - не другая
У них разные задачи и цели, во всех структурах это разные бизнес сущности.
требуются прорицатели, шар свой.
А как же без этого?)
verticalacid
26.03.2026 06:25А можно текст вакансии и статистику успеха найма ясновидящих? Я тоже таких хочу.
Реально ведь жесть. Самодурством это политкорректно называется.
Alex-Freeman
26.03.2026 06:25Tech Lead в команде автоматизации Yandex Cloud
Становится понятно, почему такой дурдом у них при найме
thethee
26.03.2026 06:25Именно поэтому задача делается быстро, здесь и сейчас, строго по требованиям. Не факт что понадобится все вышеперечисленное.
Если задача ежегодно делать простенький отчёт на компанию в 50 человек это одно ТЗ и результат один и сроки выполнения одни (короткие, т.к. других задач хватает в компании из 50 человек). Задача рядового программиста в такой компании - усидеть на нескольких стульях, а не заниматься овер-инжирингом. Легче потом переписать с нуля подобный скриптик.
А когда у вас мега-корпорация на 10к сотрудников и больше, там и ТЗ с проработкой соответствующее, и берется не программист одиночка, а архитектор который все и предусматривает. Задача рядового программиста в такой компании - сделать точно как просят, а не заниматься овер-инжирингом. За доработкой и развитием тут следят другие люди, есть роадмапы и техлид сообщит где лучше углубиться и сделать побольше абстракций.
Myclass
26.03.2026 06:25Но это ловушка! У сотрудника и менеджера разные причины для изменения формулы расчёта. Сегодня они одинаковы, а завтра — нет.
Считаю неправильным здесь и сейчас всевозможные изменения в будущем учитывать в моделе или архитектуре. Да, какие-то из личного опыта вещи должны присутствовать. Но вариации в будущем? А если не будут эти изменения в будущем. Зазря нагородили этих доп. вещей без причины. А если менеджеры будут разных типов? Мне что каждому менеджеру свой класс в коде иметь. Это должно в моделе и биз.логике учитываться.
А если фирма сольётся с другой фирмой, а если будет перекуплена, а если изменится структура управления итд. Обо всём в будущем невозможно продумать...
Разные причины для изменения формулы говорите...так в этом-то и суть, всё это свести в единую модель и в единую формулу расчёта, а не создавать 10 разных формул, только потому что есть сейчас 10 разных уровней работников. По крайней мере так делаю я вот уже 35 лет. Наверное у вас тест не прошёл-бы..
VanKrock
26.03.2026 06:25Я вообще не понимаю зачем генерировать класс менеджер, если менеджер это по сути роль в команде, любой сотрудник может стать менеджером в какой то момент, и не просто менеджером, а менеджером какого-то подразделения, но тут уже у самого подразделения просто должно быть поле менеджер, и кто там проставлен тот и менеджер. А то как вы реализуете ИО Менеджер и тому подобные вещи
pankraty
26.03.2026 06:25Плюсую. Непонятно вообще, почему класс сотрудника или менеджера должен заниматься расчетом зарплаты. Есть стратегия начисления ЗП, и если для разных сотрудников она одинаковая - то пусть они и используют одну и ту же стратегию. Когда (и если) появится новая стратегия - создадим новую и поменяем у части сотрудников ссылку на то, какую стратегию использовать для них. В конце концов, в реально мире то, что сотрудник стал руководителем не означает, что он автоматически переводится на другую систему мотивации - могут быть ситуации, когда у сотрудника уже есть подчинённые (и в каких-то разрезах он фигурирует как менеджер), но перевод на менеджерскую систему мотивации не выполнен. Или наоборот.
diderevyagin
26.03.2026 06:25Задача на самом деле интересная. Однако есть и возражения ...
А что будет, когда завтра бизнес скажет:
Преждевременная оптимизация - одна из самых страшных ошибок и корней зла, которые приводят к большому количеству проблем. Предусмотреть все вводные заранее нельзя, а вот пере усложнить с ходу - много ума не надо. А кто будет завтра отвечать за x10 времени и цены на внесение специфических переделок которые не укладываются в начальные допущения ?
На сейчас XXX не надо, более того непонятно надо ли будет в будущем, но решили что некий вариант будет обязательно и под него надо делать архитектуру. А почему не другой ? третий ?
Извините пожалуйста за резкость - несмотря на общий интерес задачи, лично Вам нужен пророк, чьи пророчества совпали с Вашими.
ivashka138 Автор
26.03.2026 06:25Да, я понимаю, что задача не имеет единого решения. Но я и не надеюсь, что мнение кандидата на 100% совпадет с моим
В этой задаче важно то, как именно кандидат обосновывает те или другие решения. И как именно думает, какие аргументы за и против приводит, какие видит слабые места в его решении
Конкретно в своем примере, я старался привести пример расширяемой архитектуры, в которую можно легко вносить изменения. Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
kalombo
26.03.2026 06:25Всё-таки вам уже 3 комментария написали про преждевременную оптимизацию и овернижениринг, я напишу четвертым. Советую порефлексировать.
Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
А если бизнес требований больше не будет? А вы вместо 3х строчек кода навертели фабрики, интерфейсы и прочее? Архитектура создается исходя из задачи, более того, она эволюционирует с течением времени в зависимости от требований. Невозможно создать универсальную гибкую и масштабируемую архитектуру, иначе бы она была одна и все бы ей пользовались.
Резюмирую: код всегда пишется под текущие требования самым простым и читабельным способом, если будущие требования неизвестны. Без всяких фабрик и интерфейсов на случай "а вдруг прилетят инопланетяне". В процессе появляниях новых требований архитектура пересматривается, что-то рефакторится, фабрики и интерефейсы добавляются тогда, когда они нужны и приносят пользу, а не на будущее.
ivashka138 Автор
26.03.2026 06:25В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
А если бизнес-требований больше не будет?
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
kalombo
26.03.2026 06:25В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Сколько же вы навыдумывали, будет API, высока вероятность изменения мотивации. Система оплаты часто изменяется и расширяется. И кандидат должен угадать, что у вас в голове. И вот хуже всего то, что весь свой выдуманный мир вы берете за истину и пишите под него код. Я кстати на ревью встречал такое ни раз и ни два. И примерно такие же аргументы. Как итог человек пишет этот "фундамент" 3 дня вместо 3х строк, сам в нём тонет, потом еще помощи просит.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
Тратите значительно больше времени чем могли, а хуже всего то, что вы очень сильно увеличиваете когнитивную нагрузку своими абстракциями как для себя так и для других. Как итог доработки потом идут значительно дольше. Оверинжениринг в чистом виде. А потом еще и бизнес приходит с real world требованием, которому ваш фундамент по барабану и его приходится переделывать.
KEugene
26.03.2026 06:25Большинство кандидатов даже не замечают нарушения SRP. Они берут условие как данность и начинают наследоваться от этого класса. А правильно — сначала сказать: «Этот класс делает две вещи, давайте разделим».
Большинство кандидатов помнят анекдот про "люминий". Если хочешь получить работу, то "люминий". Хотя, может в душе и посмеются над составителем задачи.
kmatveev
26.03.2026 06:25Лютая каша в формулировках.
Представь, у тебя есть класс, который считает зарплату сотрудника: его KPI, премии и т. п., и создает PDF-отчет. Тебе нужно создать класс для подсчета зарплаты и генерации отчета по менеджеру. Учти, что премия и KPI у них одинаковый процент от зарплаты. Отличие лишь в том, что менеджер получает больше.
В первом предложении в зарплату входят KPI и премии, двоеточие в языке это подразумевает. В третьем предложении премия и KPI уже процент от зарплаты. Видимо, подразумевается от базы зарплаты. Менеджер - это типа не сотрудник? Класс, который нужно создать, уже есть, он полностью соответствует требованиям. Что выделяет менеджера, и зачем это учитывать отдельно - хз, не указано.
Автор с одной стороны очень расхлябан в формулировках, а с другой - требует душнильных вещей типа SOLID и проч.
petuhov_k
26.03.2026 06:25у тебя есть класс, который считает
Сломался на попытке понять задачу. Как то привык, что считает функция, а не класс. Не понятно, зачем что-то менять, если логика одинаковая.
классы-шаблоны для отчетов
Даже не знаю как дальше работать, а главное, зачем.
Yak52
26.03.2026 06:25Да ладно, класс... Там и структура сама считает ))
petuhov_k
26.03.2026 06:25Точно так. Тут я так понял, в Go что-то специфическое. Мы на своих собеседованиях не привязываемся к языку, и пользуемся терминами из “программирования”, а не из “языка”. Поэтому фраза “структура, которая считает” меня вообще отключила на некоторое время.
Oeaoo
26.03.2026 06:25дада, я тоже сделал ровно что сказали
Представь, у тебя есть структура, которая считает зарплату
и реально до последнего сохранял автору лицо внутри себя, думаю может это гос. структура или отдел в компании и это надо представить.. нуок, рисуем
а потом по тексту все стало ясно, это просто такой уровень мысли
auresio
26.03.2026 06:25Оверинжиниринг в чистом виде.
Пара наследников отEmployeeсо своими перегруженными методами/интерфейсами для калькуляции зп хватит за глаза. Приведение результата к одинаковому контракту и засылание в интерфейс/сервис который из класса сделает PDF. Расчетные листки у всех одинаковые, поэтому задача проще чем кажется. Надо помогать бизнесу решать его задачи, а не холиварить у кого интерфейсы интерфейсней, а абстракции абстрактнее.
ZamirHa
26.03.2026 06:25Выше уже сказали, могу лишь повторить: программер должен решать ту задачу, которая ему поставлена. Написано "одинаково", в то время как на самом деле надо было написать "на данный момент одинаково, но в дальнейшем может разъехаться, и это нужно учесть" - какую задачу тут нужно решать: ту, что поставлена или ту, что подразумевается?
Так-то понятно, что задание нужно читать внимательно и последовательно убирать все такого рода ловушки, но тут все упирается в вопрос - нам уровень человека как программиста надо выяснить, или... что?
iprs
26.03.2026 06:25Даже в википедию залез.
Рабо́тник, или сотру́дник — субъект трудового права, физическое лицо, работающее по трудовому договору у работодателя и получающее за это заработную плату.
Нет, все правильно. С чего вдруг менеджер не сотрудник? Я бы отпал на этапе понять задачу
ivashka138 Автор
26.03.2026 06:25В этой задачи мы читаем их премии, но показатели и их функциональность в рамках бизнеса разная. Поэтому, у них разные причины для изменения.
Именно поэтому, их нужно разделить, это позволит в будущем избежать такой ошибки:Бизнес решил пересмотреть премирование менеджера, программист залез в код, не разобрался что этот класс отвечает за 2 сущности и исправил его. И создал скрытую ошибку, что премия сотрудника считается по формуле менеджера
iprs
26.03.2026 06:25Менеджер - это подмножество сотрудников. Я не знаю, как понятнее то еще написать. Нет такой профессии - сотрудник. Есть разные там секретари, уборщики, начальники отдела, и т.д. и т.п.
Akon32
26.03.2026 06:25Нет такой профессии - сотрудник.
Мне в каких-то медицинских бумагах когда-то написали то ли профессию "сотрудник", то ли должность "сотрудник".
iv2500
26.03.2026 06:25А почему нельзя было сделать сотрудника, у которого разные встроенные модели расчета зп? Класс сотрудник будет один, а вот расчет зп будет зависеть от типа сотрудника и объект, который считает зп для нужного типа, будет добавлен при инстанциировании сотрудника
werevolff
26.03.2026 06:25Тогда, возможно, имеет смысл показать человеку уже реализованный класс расчёта премии и попросить его сделать так, чтобы для менеджера он считал премию по-другому? Серьёзно: ваша задача - это оверинжинеринг. С вашим первичным условием она решается даже не классом, а функцией в одну строчку. А вот когда условия меняются, и бизнес просит разделить расчёты для линейного специалиста и менеджера, вот в этой точке и с этим условием вы и проверяете кандидата: будет он вводить в свою функцию условие if, либо выделит интерфейс и наследует от него две имплементации. Ещё, кстати, можно решить проблему классом-фасадом, если у нас ограниченный набор ролей на предприятии. И там будет условный оператор. А можно пойти от обратного, и сделать набор различных функций для расчёта премии. Пусть у нас будут группы сотрудников. Условно, linear и management. Допустим, у них будут идентификаторы 0 и 1. Делаем функцию, которая смотрит на идентификатор роли сотрудника и, скажем, по хэш-мапе находит либо специфичную функцию для получения премии, либо дефолтную. Так мы избавляемся от лишних классов, и это тоже хорошо. Вообще не понимаю зачем решать проблему классом, если можно решить одной функцией?
iprs
26.03.2026 06:25А вообще, лучше купить лицензию на 1С зарплата и кадры и не мучать мозг. Дешевле для бизнеса выйдет. Я бы на месте собеседуемого так предложил
JBFW
26.03.2026 06:25Класс-мласс...
У вас работа с данными: сотрудники, их типы, свойства типов, данные по сотрудникам, и наконец отчёты.
Сотрудники относятся к определенным типам, у этих типов свои наборы kpi, у сотрудников своя зарплата - с этим работает блок начисления.
Отчёты генерирует блок отчётности, на основании данных расчетов. Сегодня это pdf такого вида, завтра другого (т.е. шаблоны), послезавтра шифрованный на госключе файл в какой-то налоговой программе - это не должно никак быть связано с расчетами kpi.
А вот на чем это потом написать - да хоть на Бейсике с хранением данных в текстовых файлах, это уже вопрос доступного стека и умений разработчика.
Ну, или вот как предложили вариант - взять "пакет обычной еды", т.е. 1С, и "жричодали", подстраивать свои бизнес-процессы под возможности и ограничения стандартного ПО.
QxRapt
26.03.2026 06:25Извините, это все вводные которые вы даете собеседуемому? Если так, полагаю, что человек который без дополнительных вопросов начинает предлагать реализацию сразу отмечается вами как неподходящий кандидат?
Эта задача напоминает задачи в духе "продолжи последовательность" или "исключи лишнее", где не указывается критерий по которому необходимо это сделать. Успешным решением считается не то, которое формально точно может соответствовать условию задачи по критерию выбранному испытуемым, а то - которое "загадал" интервьюер.
Если это так, выглядит как отбор по принципу - "Угадай, какую архитектуру я сюда придумал".ivashka138 Автор
26.03.2026 06:25Да, это все вводные. В этой задаче я стараюсь оценить, как мыслит кандидат, какие решения предлагает. Если кандидат не задает вопросы, то я стараюсь его подталкивать к этому: «Как ты поступишь, если у менеджера изменится формула расчета KPI?», «Нам нужно переделать отчет на другой формат, как ты это реализуешь?».
Нет, тут не нужно угадать архитектуру интервьюера, а наоборот, нужно привести аргументы в пользу своей архитектуры, масштабируемость, гибкость и так далее. Если кандидат предложит достаточно гибкую архитектуру, чтобы изменения были бы дешевыми, а сопровождение легким, я его возьму. Вне зависимости от того, похоже ли его видение на мое.
n0dwis
26.03.2026 06:25В последнее время очень скептически отношусь к вот этим "а если" на этапе проектирования или первичной реализации. Как правило, по закону подлости, изменения происходят не там и не такие, которые были заложены.
n0dwis
26.03.2026 06:25Судя по постановке - делать ничего не надо, т.к. "...у тебя есть структура, которая считает..." и менеджер отличается только окладом (что структура уже отражает). Работает - не трогай. Не вижу смысла пытаться учесть всю возможную блажь начальства сразу и создавать десятки интерфейсов, фабрик и обёрток.
xortator
26.03.2026 06:25Меня одного смущает, что в предложенном овермайнд решении связь между классами и расчётчиками зарплаты/KPI этих классов осуществляется через, прости господи, фабрику pdf? И что при добавлении новых сущностей в "..." придётся синхронно менять 2 никак не связанных куска системы друг с другом, видимо соединяя их потом на уровне фабрики? :D
SolidSnack
26.03.2026 06:25Стрелочки есть, квадратики есть, что вам ещё надо? Логику происходящего? Пффф...
xortator
26.03.2026 06:25А если серьёзно, то абстрагировавшись как от самой задачи, так и от предложенного решения (на мой вкус -- крайне кривого, я бы такое точно не принял из-за отсутствия связей между очевидно взаимосвязанными сущностями), то автор хочет сказать, что ему от кандидата важно:
Умеет/не умеет ли он задавать уточняющие вопросы, в т.ч. к неясной постановке самой задачи;
Умение думать о возможности расширять систему в будущем;
Само по себе и первое, и второе -- отлично. Эти две вещи правда нужно выяснять как можно раньше, и круто, если человек это умеет. Удачно или неудачно иллюстрирует эти идеи конкретный пример с конкретной задачей -- мне кажется, не слишком важно. Даже если этот пример неудачный, вряд ли кто-то будет спорить, что существуют вполне удачные примеры задач, которые позволяют выяснить то же самое.
Я только не понял, как именно эта штука помогает отсеять 90% кандидатов. В самом деле 90% человек, приходящих на интервью, не пытаются уточнить формулировку задачи? Не задают вопросов? Это странно, ведь формулировка задачи такая, что по ней сложно написать хоть что-то, потому что по ней непонятно, что должно получиться-то в результате в этом отчёте.
Если это просто был риторический приём, который на самом деле означает "йоу, смотрите, какая у меня крутая задача и сколько в ней подводных камней", тогда ОК. Если правда 90% людей на ней отваливаются -- то почему? Потому что не задают вопросы? Потому что не считают нужным городить фабрики на фабриках, пока в них не возникло нужды? Или потому что вообще не могут решить задачу в том виде, как она сформулирована (тут возможный прилёт инопланетян в будущем не рассматривается)? Или просто потому что они другой религии, все эти слова типа SMART, SOLID, SRP и прочую фиготу знать не знают или в неё не верят, и у вас с ними на этой почве идеологический конфликт? Интересно было бы узнать это.
Oeaoo
26.03.2026 06:25Я только не понял, как именно эта штука помогает отсеять 90% кандидатов.
Приведу в пример себя. Я, когда трачу время на собесах, продираясь через чью-то незрелость, внутри себя думаю "а мне туда вообще надо?" и просто пропускаю таких работодателей. Могу даже специально запороть интервью, чисто из уважения к обоим сторонам чтобы не тратить время. И так я войду в 90% отсеянных. Это ведь цель, правда? Ну, собсна я только за.
Zifix
26.03.2026 06:25Я просто оставлю тут ссылку на легендарную статью про то, как два программиста хлеб пекли.
KoIIIeY
26.03.2026 06:25Какая фабрика?!
Берем кафку
...
dopusteam
26.03.2026 06:25Какая кафка? Абстрактная фабрика, а там под капотом уже либо кафка, либо рэббит, либо еще чего спрячем
werevolff
26.03.2026 06:25Нужно сделать ансамбль LLM для расчёта премии. Пусть они обучаются и сами вычисляют: менеджер этот сотрудник или нет? Так мы сможем в конце года отчитаться о внедрении ИИ, который нам же за это посчитает щедрую премию.
coodi
26.03.2026 06:25Ничего не понял, почему они не просто в бд лежат?
Kahelman
26.03.2026 06:25Я бы тоже предложил: загоняем данные в БД. Отчёт генерирую простым sql запросом. Нормальный отчёт должен быть в табличном виде.
Далее экспортируем в текстовый файл, если надо pdf (кстати зачем) куда его девать то, то посылаем текстовый файл на принтер и выбираем формат пдф.
Расчёт премии можно на триггер повесить.
Вообще-то ваша задача без классов решается табличкой в excel :)
coodi
26.03.2026 06:25Да, и получается если надо будет должности менять, это необходимо кучу кода написать для приведения типов в обе стороны?
ncix
26.03.2026 06:25Вообще-то ваша задача без классов решается табличкой в excel :)
А ведь все CnB-шники кого я знавал, именно в экселе и работают. Потому как даже в больших ИТ-корпорациях не могут родить действительно рабочую систему подсчета выплат, которая учитывает всё, даже кейсы типа "я формально был в отпуске но вообще-то работал, плотите бонус".
RobertVladlenovi4
26.03.2026 06:25Огонь!
Я попросил решить одну задачу, а ожидаю решение другой задачи...
Я бы вас уволил )
TruthTeller
26.03.2026 06:25Ох ты ж Господи...
Я был одним из первых, оставивших саркастический коммент под статьей. Но тут парню прямо полную панамку напихали, да еще и эту вашу "карму" срезали.
Да, статья спорная (с ложными выводами, имхо). Да, подана категорично, с позиции "я знаю как правильно". Скорее всего, парень достаточно молодой и не то чтобы супер опытный (хоть трижды техлидом будь), поэтому склонен к максимализму и "за деревьями не видит леса".
Но подвергать чела остракизму за то, что он написал статью - это какая-то хрень.
Stackoverflow славился тошнотворно токсичным коммьюнити. Хабр такой же.
Оба ресурса канут в лету в скором будущем, совершенно заслужено притом.
SOLID, кстати, штука хорошая. Software architecture тоже. Хотя ни то, ни то, не так важно, как может показаться на заре карьеры в IT на позиции программиста (трижды техлидом).
Vydra77
26.03.2026 06:25Остракизм как явление не на пустом месте возник, и притом ещё тысячелетия назад... Конкретно тут многие, как потенциальные кандидаты, негодуют распространению вот такого ясновидящего подхода. Это же не просто рандомный текст в интернете, это статья техлида из очень крупной компании, на которого могут равняться другие техлиды
а лучше бы равнялись на здравый смысл.Если убрать (совершенно заслуженное) минусование и карму, то получится тот же беззубый пикабу, который превратился в помойку для рекламы тг-каналов.
FixicusMaximus
26.03.2026 06:25Одного SOLID для проектирования маловато, нужен хотя бы DDD, что позволит вам лучше понять предметную область и эффективно прогнозировать хотелки заказчиков, а не пытаться их предугадать. Это если вы архитектор, техлид, тимлид и т.п. Если вы простая рабочая лошадка, то вам должны поставить загончик (заглушки) в рамках конкретно описанной задачи, в котором вы должны пастись и делать свою работу. Если, в силу своей упоротости или криво описанной задачи, вы что-то не так сделали - на ревью скажут как надо. Обычно так это в нормальных конторах работает.
sargas
26.03.2026 06:25ооп головного мозга
пиши функцию которая агрегирует всю инфу на сотрудника какую надо, и функцию которая это конвертит в csv
тоже самое для менеджера
всё, гибкость хоть ноги в жопу пихай и никакой мозгосральни с вашими наследованиями
Vsevolod_888
26.03.2026 06:25Нашли, в итоге то? У вас уже есть хотя бы три класса? Или функции? Структура развивается?
Denimss
26.03.2026 06:25Учитывая, что ИИ не может задавать вопросов,
Как это не может? Про режим plan в Claude Code, Codex, OpenCode слышали? Или просто простые промты - "Подумай и задай мне вопросы о том, что может директор еще вдруг потребовать поменять в проекте", "Будь оракулом - предскажи что еще директор может поменять в условиях проекта".
ncix
26.03.2026 06:25Я бы для начала попросил дать контакты заказчика от бизнеса и CnB, т.к. получать бизнес-задачу от тимлида - испорченный телефон
TruthTeller
Вот поэтому вайбкодинг появился и менеджеры так им интересуются. Программисты часами готовы обсуждать как поделить классы чтобы избежать одного if, а через 5-7 лет система все равно "legacy, не полезу, надо переписывать".