Cresta Software Engineer Interview Experience — A Feature-Flag Evaluation Engine, Then Rejected After a ‘Great Chat’

I used Claude to help organize this write-up. The interviewer kept saying he really enjoyed our conversation, and then rejected me anyway.

Problem background: you're given three JSON files and asked to implement a feature-flag evaluation engine that maps every user to a final boolean value (on/off) for every flag.

Input files:

• flags.json — definitions for 7 flags
• user.json — 10,000 users
• expected_decisions.json — the answer key (200 users x 7 flags), for self-testing

Data structures:

Flag structure (this is exactly how it was pasted to me, cutting off mid-way):

{ "key": "beta_dashboard", "enabled": true, "default": false, "rules": [ { "name": "market_launch", "conditions": [ { "attribute": "country", "operator": "in", "va { "attribute": "plan", "operator": "eq", "value": "enterprise" } ], "value": true } ] }

User structure: user_id / country / plan / support_ti (also cut off in my notes — presumably support_tier plus a couple more fields). The source's example also included an email field, which I have omitted here.

Core requirements:

• Write a function that evaluates a single flag
• Write a function that evaluates all flags for a given user
• Multiple conditions inside one rule are combined with AND
• If no rule matches, return the flag's default
• If multiple rules match, follow the logic shown in expected_decisions.json — true wins (if any matching rule evaluates to true, the final result is true), not sorted by rule name
• Add comments explaining the evaluation logic
• Operators that show up in conditions: eq / in / regex / ~=

A few gotchas (which were also the actual test points):

• If a flag is disabled (enabled: false), return default directly and ignore all rules
• The regex is anchored — equivalent to re.match, matching from the start of the string. There's a rule involving something like "testers..." but in practice it never matches anyone — it's a no-op
• Percentage rollout: some rules have a percentage: 30 field...
• Rule conflicts: e.g. a Germany (DE) + Enterprise-plan user matches multiple rules at once, and the expected answer uses true-wins -> true
• Dirty-data trap: in user.json, some users have their country/plan fields nulled out (the expected answers were generated before those fields got nulled). These need to be handled as their own case — don't mistake it for a logic bug

flags.json (one flag, as an example):

{ "key": "beta_dashboard", "enabled": true, "default": false, "rules": [ { "name": "market_launch", "conditions": [ { "attribute": "country", "operator": "in", "va { "attribute": "plan", "operator": "eq", "value": "enterprise" } ], "value": true } ] }

user.json (a few users, including one with a field nulled out as "dirty data"):

[ { "user_id": "user_00001", "plan": "enterprise", "support_tier": "gold", "signup_date": "2021-03-14" }, { "user_id": "user_00003", "plan": "enterprise", "support_tier": "gold", "signup_date": "2020-11-02" }, { "user_id": "user_00007", "plan": null, "support_tier": "gold", "signup_date": "2022-06-21" } ]

expected_decisions.json (expected answers for a few users):

{ "user_00001": { "dark_mode": true, "beta_dashboard": true, "new_checkout": true, "experimental_search": true,"ai_assist": false, "legacy_export": false }, "user_00003": { "dark_mode": true, "beta_dashboard": true, "new_checkout": true, "experimental_search": true, "ai_assist": false, "legacy_export": false } }

Suggested approach: don't rush into the implementation. First use expected_decisions.json to reverse-engineer the algorithm (especially for rule conflicts and the percentage logic), get the "100% match on clean data" case working, and only then start coding. Finally, add unit tests covering the happy path plus all the edge cases above.