Architectural task for interview for Go and Java

Architectural Interview Challenge: Testing Developer Design Thinking

This task assesses understanding of SOLID principles, SRP, and system flexibility. Candidates are asked to extend an existing employee salary calculation structure (or class) that also generates a PDF report to accommodate managers. Key constraints: same KPI and bonus percentages relative to base pay, but managers have higher base salaries. The system must support future changes with minimal disruption.

For Go, this means creating a struct; for class-based languages, a class. Though simple on the surface, the task tests the ability to spot design violations and build scalable architecture.

Common Mistakes & AI-Driven Solution

Most candidates overlook SRP violations: the original structure mixes salary calculation and report generation. The correct approach is to separate responsibilities.

The AI solution uses composition and interfaces:

• A base Employee struct with shared fields (rate, KPI %, bonus %) and methods (CalculateBase, CalculateKPI, CalculateBonus).
• An interface SalaryCalculator with a CalculateSalary() *Report method.
• Manager composes Employee and applies a multiplier to increase base pay.
• A dedicated ReportGenerator accepts any SalaryCalculator.
• Constructors NewEmployee and NewManager handle initialization.

Issue: One report generator can't account for future differences (e.g., number of direct reports, varying KPI schedules). This forces conditional logic or rewriting—violating OCP.

Hidden Challenges in the Problem Statement

The prompt intentionally includes traps:

• SRP violation: "a class that calculates salary... and creates a report." Candidates should propose separation.
• False generalization: "same KPI and bonus percentages." Formulas may evolve independently per role.
• Role oversimplification: "only base salary differs." Managers are distinct business entities with unique KPIs and accountability zones.

Strong candidates ask clarifying questions: How do formulas change? What data goes into the report? Are new roles planned?

Candidate Evaluation Criteria

Assessment focuses on thinking, not code:

• Questions asked: Clarifies requirements, uncovers hidden assumptions.
• Justification: Explains design choices (SOLID, composition vs inheritance).
• Flexibility: Plans for system evolution (adding roles, report formats).
• Pros/cons analysis: Self-critique of proposed solution.
• Testability: Components designed for isolation and unit testing.

Recommended Architecture

A viable solution (Go-style, adaptable to class-based languages):

• Interfaces:

- SalaryCalculator: methods for calculating base, KPI, bonus, total.

- ReportDataProvider: provides data for the report (salary, extra fields).

- ReportTemplate: Generate(ReportDataProvider) PDF.

• Implementations:

- EmployeeSalary and ManagerSalary implement SalaryCalculator.

- EmployeeReport and ManagerReport implement ReportTemplate, each holding a reference to its corresponding SalaryCalculator.

• Factory: NewReport(templateType string, calc SalaryCalculator) ReportTemplate.

Benefits:

• Easy to add new roles (e.g., DirectorSalary + DirectorReport).
• No conditional logic in the report generator.
• Composition enables reuse across components.

Key Takeaways

• SRP enforcement: Calculation and reporting are separate concerns.
• OCP compliance: New roles added without modifying existing code.
• Composition over inheritance: Enables long-term system adaptability.
• Factories for encapsulation: Hide creation complexity.
• Candidate’s questions: Signal deep, thoughtful analysis.

— Editorial Team