Practise answering 5 interview questions for a Platform Economics Analyst role. Covers infrastructure unit economics, reserved instances, cost allocation, rightsizing, and egress costs.
Key vocabulary
Unit economics: cost per unit of value delivered (cost per API call, cost per active user)
Reserved instances (RI): upfront commitment to use a specific instance type for 1–3 years in exchange for 30–70% savings
Savings Plans: flexible RI alternative that commits to spend (not instance type)
Showback: reporting cloud costs to teams without charging them
Chargeback: actually billing internal teams for cloud usage
Rightsizing: matching instance type and size to actual workload requirements
Egress: data transfer OUT of a cloud region/provider — typically charged; ingress is usually free
0 / 5 completed
1 / 5
The interviewer asks: "Can you explain the difference between reserved instances and savings plans, and when you would recommend each?" Which answer is most strategically complete?
Option B is the strongest: it names all three Savings Plan flavours with their specific discount levels and flexibility characteristics, gives a concrete recommendation framework with a portfolio split (70%/10-15%/remainder), and names the specific scenario where RIs beat Savings Plans (3-year database commitment). Option C efficiently summarises the core recommendation (Compute Savings Plans as default) and introduces the commitment coverage ratio metric — a real FinOps KPI. Option D adds the maturity-based approach and the practical workflow of using 90 days of baseline data plus Cost Explorer recommendations — this is how it works in practice. Option A is accurate but lacks the three Savings Plan types and the recommendation framework. Senior FinOps answer: three Savings Plan flavours with discount levels → flexibility-discount axis → portfolio split recommendation → RI use case specificity → commitment coverage ratio as KPI.
2 / 5
The interviewer asks: "What is the difference between showback and chargeback, and when would you recommend each?" Choose the most operationally complete answer.
Option B is the strongest: it frames the maturity axis explicitly, defines both terms with the business consequence distinction, names the three shared service allocation methods (direct/fixed/proportional), identifies the tagging failure mode with the specific consequence (disputes → trust breakdown), and gives a concrete transition recommendation (3–6 months showback first). Option C focuses on the three preconditions for chargeback transition — tagging coverage threshold (90%), allocation policy, and finance integration — all of which are real prerequisites. Option D adds an important org structure dimension: chargeback works in product-led P&L teams but adds bureaucracy in cost-centre orgs — this is strategic thinking about when chargeback actually changes behaviour. Option A makes the common error of asserting chargeback is always more effective without considering the prerequisites. Senior FinOps answer: maturity axis → tagging coverage threshold → three allocation methods → failure mode → org structure consideration for chargeback recommendation.
3 / 5
The interviewer asks: "Walk me through how you conduct a rightsizing analysis for a fleet of EC2 instances." Which answer is most methodologically rigorous?
Option B is the strongest: it provides a five-phase structured methodology with named phases, specifies the data collection period with rationale (14–30 days for batch job coverage), segments the fleet by workload type before applying rules (burst vs. memory vs. network), gives the specific 20% average / 3x peak-to-average thresholds, includes the staging validation step, and adds the 14-day post-change monitoring requirement. Option C efficiently covers the Compute Optimizer workflow, confidence score filtering, and savings/risk matrix stakeholder communication — a practical applied answer. Option D adds two important nuances not in others: using P95 rather than average (with a concrete 70% P95 target), and the RI coupling problem (downsizing without updating the RI wastes the commitment) — showing real production experience. Option A is too thin — no segmentation, no peak analysis, no validation. Senior rightsizing answer: five phases → workload segmentation before rules → peak-to-average ratio → P95 vs. average distinction → RI coupling problem → post-change monitoring.
4 / 5
The interviewer asks: "Explain egress costs and how they should influence cloud architecture decisions." Which answer is most architecturally complete?
Option B is the strongest: it gives the full egress price breakdown (internet/cross-region/cross-AZ/CDN) with specific numbers, identifies four architectural implications with concrete cost examples (10TB same-region free vs. cross-region; 1TB/day replication = $7,300/year; 100TB migration = $8,000–9,000), names the lock-in mechanism explicitly, and provides counter-strategies including enterprise discount negotiation. Option C adds the product design angle (model egress cost before launch at projected user scale) and integrates egress into unit economics — showing strategic product thinking. Option D goes into the three egress types (internet/cross-region/cross-AZ) and their separate optimisation levers — particularly the cross-AZ microservices co-location trade-off (redundancy vs. cost) which is a real production consideration. Option A covers the basics but lacks the lock-in dimension, cross-AZ costs, and multi-region implications. Senior egress answer: full price breakdown → data gravity → replication TCO → lock-in mechanism → unit economics integration → three egress types with separate levers.
5 / 5
The interviewer asks: "How would you explain infrastructure unit economics to engineering leadership?" Choose the most business-aligned answer.
Option B is the strongest: it provides a five-step framework with named steps, explains why the unit choice matters (business model alignment vs. obscuring signals), gives the four-layer decomposition of cost per MAU, provides the 10–30% COGS/ARPU benchmark with the 40% unprofitability trigger, names the hotspot-as-prioritisation-signal concept with a concrete example (40% of compute for 5% of users), and closes with the roadmap decision integration (projected unit economics per feature). Option C adds the Pareto chart visualisation (top 3 services = 60–80% of cost) which is a strong communication technique for engineering leadership. Option D introduces the three-layer executive communication framework (efficiency trend/cost attribution/investment return) including the feedback loop between investments and measured outcomes — this is how FinOps programmes justify themselves over time. Option A covers the basics (cost per MAU vs. ARPU) but lacks the decomposition, the COGS/ARPU benchmark, and the roadmap integration. Senior unit economics answer: unit selection for business model → four-layer decomposition → 10–30% COGS/ARPU benchmark → hotspot as prioritisation signal → roadmap integration → Pareto visualisation.
What does "Platform Economics Analyst Interview Questions — coderslingo.com" cover?
Practise answering 5 interview questions for a Platform Economics Analyst role. Covers infrastructure unit economics, reserved instances, cost allocation, rightsizing, and egress costs.
How many questions are in this interview set?
This set has 5 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.