Behavioral: STAR method answers for Java developer interviews

// Think of STAR as a method signature:
public InterviewAnswer buildSTAR(
    String situation,  // 1-2 sentences of context
    String task,       // your personal responsibility
    String action,     // concrete steps (60% of answer)
    String result      // measurable outcome with numbers
) {
    return new InterviewAnswer(situation, task, action, result);
}

// Good Situation example:
// "At National Bank of India, I worked on a monolithic payment system
//  that served 50,000 daily transactions but had grown to a 2-minute
//  response time during peak trading hours."

// Bad Situation (too vague):
// "I worked on a slow system."

// Structure it like a log entry:
public class SituationTemplate {
    String company = "National Bank of India";
    String system = "monolithic payment service";
    String scale = "50,000 daily transactions";
    String problem = "2-minute response during peak hours";
}

// Good Task:
// "My task was to reduce payment latency to under 500 milliseconds
//  without any downtime during the migration."

// Bad Task (team-focused):
// "The team needed to make it faster."

// Think of it as your personal SLA:
public class TaskTemplate {
    String owner = "I"; // not "we" or "the team"
    String target = "reduce p95 latency to under 500ms";
    String constraint = "zero downtime during migration";
}

// Action example (concrete, technical, ordered):
// 1. Profiled the monolith and identified 3 hotspots
// 2. Decomposed into 5 Spring Boot microservices
// 3. Moved notification to Kafka for async processing
// 4. Added Redis cache for balance lookups and idempotency
// 5. Wrapped account service calls in Resilience4j circuit breakers
// 6. Set up Prometheus/Grafana dashboards for latency monitoring

public class ActionTemplate {
    String[] steps = {
        "Profiled with async-profiler, found 3 hotspot queries",
        "Decomposed monolith into 5 Spring Boot services",
        "Moved notifications to Kafka (async)",
        "Added Redis for caching and idempotency",
        "Wrapped downstream calls in Resilience4j circuit breakers",
        "Built Prometheus + Grafana latency dashboards"
    };
}

// Good Result:
// "p95 latency dropped from 2 minutes to 200 milliseconds.
//  Uptime improved from 99.5% to 99.95%.
//  The system now handles 100,000 daily transactions."

// For failure stories, add lesson + process change:
// "The migration locked a production table for 20 minutes.
//  Lesson: always test migrations on production-sized data.
//  Process change: added a pre-deployment migration review checklist
//  that the team now follows for every release."

public class ResultTemplate {
    String metric = "p95 latency: 2 min -> 200ms";
    String availability = "99.5% -> 99.95% uptime";
    String scale = "50K -> 100K daily transactions";
}

// Template:
// "I am a Java developer with [X] years of experience building
//  [domain] applications on [tech stack]. Currently I work on
//  [current project] that processes [scale]. I focus on
//  [your strengths: clean architecture, performance, reliability]."

// Example:
// "I am a Java developer with 5 years of experience building
//  financial applications on Spring Boot, Kafka, and PostgreSQL.
//  Currently I work on a trading platform at National Bank of India
//  that processes 10,000 trades per second. I focus on clean
//  architecture, performance, and production reliability."

// STAR for disagreement:
// S: Team disagreed on REST vs Kafka for service communication
// T: My role was to evaluate both and present findings
// A: Built a proof of concept for each, measured latency and
//    failure scenarios, presented comparison with numbers
// R: Data showed async Kafka was more resilient under load;
//    team aligned on Kafka without friction

// Key: never say "I convinced them I was right."
// Instead: "The data showed X, and we aligned on that."

// STAR for failure:
// S: Deployed a database migration during trading hours
// T: I was responsible for the release
// A: The migration locked a production table for 20 minutes.
//    I took immediate ownership, coordinated the rollback,
//    and wrote the postmortem.
// R: Lesson: always test migrations on production-sized data.
//    Process change: created a pre-deployment migration review
//    checklist that the team now follows.

// Key: own it -> fix it -> prevent recurrence

// Story bank:
// Story 1 (performance): monolith -> microservices migration
//   Covers: challenging project, technical depth, impact
// Story 2 (disagreement): REST vs Kafka decision
//   Covers: conflict resolution, data-driven decisions
// Story 3 (failure): production migration incident
//   Covers: ownership, growth, process improvement
// Story 4 (leadership): mentored junior on code review
//   Covers: teamwork, teaching, influence without authority

// Rotate stories to match each question's hidden intent.

// Prepare for follow-ups by adding depth to each story:
// - The specific trade-off (e.g., latency vs consistency)
// - The metric you watched (e.g., p95 latency dashboard)
// - The feedback loop (e.g., weekly retro, A/B test results)
// - The long-term impact (e.g., system still runs 2 years later)