Problems & Demos

github.com/personio/backend-coding-challenge — Kotlin + Spring Boot scaffolded, PostgreSQL + Flyway + JOOQ. You can use any language, but if you know Kotlin, use the scaffold.

The 3 features to build

Feature 1 — Dashboard display

• Reminder appears on the dashboard starting at 00:00 on its scheduled date.
• Displays the reminder text + a "Done" button.
• Marked-done reminders disappear.
• Incomplete past reminders continue to appear until done.

Feature 2 — Email notifications

• Optional time-of-day, 5-minute precision (14:00, 14:05, 14:10…).
• Email sent exactly once, within ±5 min of scheduled time.
• Timezone-aware — respect each employee's local TZ.
• Marked done before send time → no email.

Feature 3 — Recurring reminders

• Optional recurrence: frequency ∈ {DAILY, WEEKLY, MONTHLY, YEARLY} + interval integer.
• Each occurrence is independently markable.
• With email enabled: one email per occurrence.
• Yesterday's "Buy milk" not done? Today's still shows. Both visible until each marked done.

Data model (sketch)

CREATE TABLE reminders (
  id          UUID PRIMARY KEY,
  employee_id UUID NOT NULL,
  text        VARCHAR(512) NOT NULL,
  start_date  DATE NOT NULL,
  send_at_time TIME NULL,        -- optional, 5-min precision
  recur_freq  VARCHAR(10) NULL,    -- DAILY/WEEKLY/MONTHLY/YEARLY/NULL
  recur_step  INT DEFAULT 1,
  timezone    VARCHAR(64) NOT NULL, -- e.g. 'Europe/Berlin'
  created_at  TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE reminder_occurrences (
  reminder_id  UUID REFERENCES reminders(id) ON DELETE CASCADE,
  occurs_on    DATE NOT NULL,            -- specific occurrence
  done_at      TIMESTAMPTZ NULL,
  email_sent_at TIMESTAMPTZ NULL,         -- idempotency anchor
  PRIMARY KEY (reminder_id, occurs_on)
);

Architecture (clean architecture, matches their scaffold)

What graders look for

1. Separation of I/O from logic. Domain has no DB or SMTP. Use cases take repos as deps.
2. Timezone handling. Store UTC, convert with employee's ZoneId. Test for DST transitions.
3. Idempotent email. email_sent_at column. Send loop: UPDATE … WHERE email_sent_at IS NULL RETURNING … — atomic claim.
4. Tests for the core rule. Recurrence expansion, timezone edge cases (DST spring-forward), "marked done before send" path.
5. 1-page README. Assumptions · scope · how to run · what you'd do next.
6. Invite critique. List 2–3 things you'd change in the follow-up. Coachability signal.

Common mistakes

• Using LocalDateTime instead of ZonedDateTime / OffsetDateTime.
• Materializing all future occurrences (infinite recursion risk).
• Using a boolean email_sent column instead of a timestamp — can't tell when.
• One giant service class with controller + DB + email all mixed.
• No tests for the "past reminder not yet done" case (it's in the spec).

Problem

Given a recurrence rule (frequency + interval + start date), return all occurrences within a time window. This is the core of their reminder challenge — and very likely a live-coding follow-up.

Live demo

Code

from datetime import date
from dateutil.relativedelta import relativedelta

def expand(start, freq, interval, window_end):
    occurrences = []
    cur = start
    deltas = {
        'DAILY':   relativedelta(days=interval),
        'WEEKLY':  relativedelta(weeks=interval),
        'MONTHLY': relativedelta(months=interval),
        'YEARLY':  relativedelta(years=interval),
    }
    delta = deltas[freq]
    while cur <= window_end:
        occurrences.append(cur)
        cur = cur + delta
    return occurrences

Gotchas Personio will probe

• MONTHLY edge case: start on Jan 31 → next MONTHLY occurrence is Feb 28/29 (not "Mar 3"). Use a date library that handles this (e.g., dateutil.relativedelta in Python, java.time.LocalDate.plusMonths in Java).
• DST in WEEKLY/DAILY: if the recurrence has a time, the same wall-clock time can land on different UTC instants. Store wall time + ZoneId, compute UTC at expansion.
• Unbounded expansion: always require a window bound. Don't return an infinite generator without a stop condition.
• Memoization for read-heavy: cache materialized occurrences in a table once you've expanded them.

Why this matters at Personio

Payroll. Floating-point arithmetic silently drops cents in ways that compound over thousands of payslips. Using float for money is a senior-level red flag.

Live proof

The right way

# Python
from decimal import Decimal, ROUND_HALF_EVEN, getcontext
getcontext().prec = 28

salary = Decimal('4825.50')
tax_rate = Decimal('0.215')
tax = (salary * tax_rate).quantize(Decimal('0.01'), rounding=ROUND_HALF_EVEN)
net = salary - tax

# Always:
# 1. Construct from STRING, not float. Decimal(0.1) ≠ Decimal('0.1').
# 2. Quantize at the LAST step, not intermediates.
# 3. Use Banker's rounding (ROUND_HALF_EVEN) for tax/payroll.
# 4. Store as DECIMAL(precision, scale) in DB — never FLOAT.

// Java / Kotlin
import java.math.BigDecimal;
import java.math.RoundingMode;

BigDecimal salary = new BigDecimal("4825.50");
BigDecimal taxRate = new BigDecimal("0.215");
BigDecimal tax = salary.multiply(taxRate)
                       .setScale(2, RoundingMode.HALF_EVEN);

// NEVER: new BigDecimal(0.215) — picks up float imprecision.

Even better — a Money type

class Money:
    def __init__(self, amount: Decimal, currency: str):
        self.amount = amount; self.currency = currency

    def __add__(self, other):
        assert self.currency == other.currency, "can't add EUR + USD"
        return Money(self.amount + other.amount, self.currency)

    # Multiplication only by a scalar (Decimal), never by another Money
    def __mul__(self, scalar: Decimal):
        return Money((self.amount * scalar).quantize(Decimal('0.01')),
                     self.currency)

Problem

Schedule "14:05 Europe/Berlin" reliably even during DST transitions. The take-home spec says emails are time-zone aware — they'll quiz you on this.

Live demo — DST gotcha

The right pattern

1. Store wall time + zone (e.g., 14:05 + Europe/Berlin), not a UTC instant. Otherwise DST changes shift the user's intended time.
2. Resolve to UTC at expansion time, per occurrence.
3. Handle the "gap" and "overlap":
   • Spring forward (clock jumps 2→3 AM): if reminder is 2:30, it doesn't exist that day. Pick policy: skip, or shift to 3:00.
   • Fall back (clock repeats 2→3 AM): if reminder is 2:30, it happens twice. Pick policy: first occurrence wins.
4. Use the tzdata library, never hardcode offsets. UTC offsets change (Russia, Brazil have).

from zoneinfo import ZoneInfo
from datetime import datetime, time, date

def resolve_to_utc(occurrence_date: date, wall_time: time, zone: str):
    local = datetime.combine(occurrence_date, wall_time, tzinfo=ZoneInfo(zone))
    return local.astimezone(ZoneInfo('UTC'))

Prompt

Design a system to run monthly payroll for 10,000 European companies. It must be: idempotent, auditable, tolerant of late data, and accurate to the cent.

Clarifying questions (always ask first)

• What's the time SLA — same day? Within an hour?
• How are calculation rules versioned? (Tax law changes mid-year.)
• Can a payroll be re-run? Edited after-the-fact? Locked?
• Multiple currencies?
• Are we generating PDFs (payslips) or just numbers?

Architecture

Key design decisions (verbalize these)

1. Idempotency anchor: run_id. Same run re-executed = same output (or skip if already done).
2. Snapshot at start. Freeze employee data + calc rules version. Late edits don't corrupt the in-flight run.
3. Immutable results. Errors → new "corrective run" referencing the old. Never UPDATE a payroll record. Auditors thank you.
4. Decimal arithmetic everywhere. Postgres NUMERIC(15,4); Kotlin BigDecimal. Document it.
5. Versioned rules. Tax brackets stored as tax_rules(country, valid_from, valid_to, rule_json). Calculator picks by date.
6. Late data: if a salary change arrives after the run, you have two choices: corrective run (preferred), or block until cutoff. Discuss the trade-off.
7. Per-tenant partitioning. No cross-tenant rows. Each calc worker only ever sees one tenant at a time.
8. Replayable: from the event log + snapshots, you can reproduce any run bit-for-bit, months later, for audit.

Failure modes to discuss

• Worker dies mid-employee: partial writes are OK because results table has (run_id, emp_id) as primary key. Next worker retries.
• Calc rule changes mid-run: snapshot prevents this. Run uses the version captured at start.
• Bank payout fails: separate phase from calculation. Calculation succeeds independently; payout is retried via DLQ.
• Tenant A's bug blocks tenant B: per-tenant workers / queues prevent noisy neighbor.

Prompt

An employee leaves a company; ~7 years later they invoke their right to be forgotten. Implement.

The decision tree (have this memorized)

Live demo

Architecture

What to nail

1. Anonymize, don't hard-delete — preserves referential integrity (payroll history needs employee_id) while removing PII.
2. Replace PII fields with deterministic hashes or "DELETED USER" + a tombstone ID. Salaries/dates kept for audit.
3. Catalog of subject data. You can only erase what you know about. Have a registry of every table/column containing PII.
4. Audit log itself is exempt. GDPR Art. 17(3) — log the erasure event, including a non-reversible hash for proof.
5. Backups. Schedule erasure for next backup-rotation cycle (you can't reach into a 30-day-old snapshot easily).
6. SLAs. GDPR mandates "without undue delay" — typically 30 days max.