Interview guides · CIM Group

CIM Group Software Engineer Interview Guide

CIM Group Software Engineer interview guide: the three reported rounds, system design, data integrity and behavioral questions, and a 7-day prep plan.

The 60-second brief

CIM Group is described by candidates as a real estate and infrastructure investment firm, and the Software Engineer role sits between its infrastructure teams, its investment analysts and its operations managers. The reported work is internal software: tools that show the state of a portfolio as it changes, automated monitoring built with infrastructure teams, and the full cycle from requirements to deployment and maintenance. Candidates also report that solutions have to follow the firm's internal security and data governance standards.

This guide is for engineers interviewing for a Software Engineer role at CIM Group, typically mid-level (candidates report 3-5 years of professional experience as the usual expectation). The stack candidates see listed is Python, Java or C#, relational databases and AWS or Azure.

Candidates report three stages over roughly 3-5 weeks: a Recruiter Screen, Technical Interviews with engineering staff or management, and Final Interviews with hiring managers.

Focus areas

Software Engineering
Infrastructure Engineering
AI Infrastructure (Infrastructure Engineer, AI)

Overview

The reported work is data-heavy internal tooling for an investment business: software that tracks changes across a portfolio of assets, monitors infrastructure, and feeds analysts and operations managers. That shapes the reported questions. Two are pure design (a scalable monitoring system for portfolio infrastructure, and data integrity in a high-volume environment). Candidates also report example scenarios about tracking real-time changes across a large portfolio and handling a sudden surge of data from infrastructure sensors. Prepare these as one family: ingest, store, serve and alert on data that must stay correct.

The remaining reported questions test experience you describe rather than a problem you solve at a whiteboard: cloud cost and performance, a production incident handled under pressure, and the balance between technical debt and delivery speed. Each needs a real story with a measurement in it. A cloud answer without a baseline, or an incident answer without a timeline, reads as a list of buzzwords.

Candidates also report a strong people component: explaining a technical idea to a non-technical stakeholder, handling feedback, disagreeing with a project direction, aligning your work with team goals, and explaining why you want to apply engineering to real estate and investment. Reports add that sector vocabulary matters, so learn the plain terms (for example, Affordable Housing rather than a colloquial phrase) before the loop.

The stack candidates see is Python, Java or C#, relational databases and AWS or Azure, with a Microsoft ecosystem and AI infrastructure also appearing among the reported labels for related Infrastructure Engineer roles. Pick one language you can write fluently, be ready to discuss schema design and query efficiency, and know which cloud services you would use for storage, messaging and monitoring, and what each costs you in money or latency.

The CIM Group interview process

Candidates describe three stages. The formats beyond the stage names are thinly reported, so the preparation below is tied to the question types candidates report rather than to a fixed agenda for each round.

Recruiter Screen

Candidates describe the first stage as a screen run by a recruiter to check your background and fit. Little else is reported, so treat it as the place where your story has to be clean: a short walk through your career, the kind of systems you have owned, and a clear reason for choosing this firm and this sector. Reports of the loop include a question about why you want to apply engineering to real estate and investment, so have that answer ready before the call.

What to demonstrate

How your background lines up with a Software Engineer role on internal tools and infrastructure
Whether you can explain your recent work clearly to a non-engineer
Motivation for this firm and for the real estate and investment sector

How to prepare

Write a short career walk that ends on the stack the role lists: Python, Java or C#, relational databases and AWS or Azure
Prepare a two-part answer to why real estate and investment: what draws you to the problems, and what you have done that transfers
Learn a handful of plain sector terms so you do not fall back on slang when describing the business
Have logistics ready: availability, location constraints and what you want to ask about the rest of the loop

Technical Interviews

Candidates describe this stage as technical interviews with engineering staff or management. The reported questions that fit it are the technical ones: designing a scalable monitoring system for portfolio infrastructure, ensuring data integrity at high volume, cloud cost and performance experience, a production issue under pressure, and technical debt versus fast delivery. Reports also list scenarios such as tracking real-time changes across a large portfolio and absorbing a surge of sensor data. Approach each as a structured walk-through: assumptions, constraints, design, failure modes.

What to demonstrate

Ability to design for reliability, scale and data correctness in a monitoring or portfolio-tracking system
Working knowledge of relational schema design and query efficiency
Experience with cloud infrastructure and how you reason about cost versus performance
Clear reasoning about trade-offs, including security of sensitive financial or infrastructure data

How to prepare

Design the portfolio change-tracking system on paper: sources, ingestion queue, store, query path, alerts, and what happens during a surge
List the integrity controls you would layer in: constraints, idempotent writes, reconciliation against the source, audit trail
Prepare one real incident and one real cloud-cost story with before-and-after numbers from your own work
Practise relational problems and a language of your choice

Final Interviews

Candidates describe the last stage as discussions with hiring managers about overall fit and technical judgment. The reported prompts that suit it are the people-oriented ones (feedback, disagreement, aligning with team objectives, explaining technical ideas to non-technical colleagues) along with the technical-debt trade-off, which is a judgment question. Reports also say to expect a mix of technical insight and professionalism. Bring stories where you made the call, with numbers, and prepare real questions about the team's engineering work.

What to demonstrate

Overall fit for the team and how you work with analysts, operations staff and other departments
Judgment about priorities, technical debt and shifting requirements
Whether your technical explanations stay clear for a mixed audience

How to prepare

Rehearse the disagreement, feedback and team-alignment stories in STAR form, each with a concrete result
Prepare a stakeholder story where you translated a technical constraint into a decision a non-engineer could make
Write at least three questions about the team's current technical challenges and how engineers and analysts work together
Decide your position on technical debt versus delivery and back it with an example where you chose each way

Where candidates lose points

Drawing one box labelled database for the portfolio monitoring design

Split ingestion, storage, query and alerting. Decide where a surge of sensor data waits (a queue with backpressure), how writes stay idempotent, and which store serves current state versus history. Say what you would monitor on the monitor itself.

Answering the data integrity question with only input validation

Layer the controls: database constraints and transactions, idempotency keys for retries, reconciliation jobs against the source of truth, audit logging of changes, and alerts when counts or totals drift. Say how you would detect silent corruption, not just rejected input.

Describing cloud cost work as a list of services with no baseline or result

Anchor the answer in one workload: what it cost or how slow it was, what you changed, what it cost or measured afterwards, and what trade-off you accepted. Put your real numbers in; vague claims invite exactly the follow-up you cannot answer.

Telling stories where you watched rather than decided, or where a colleague is the villain

For the disagreement, feedback and team-alignment prompts, pick moments where you took an action, show the evidence you used, and finish with what changed, including when you were wrong. Keep the other person's position stated fairly.

Answering why real estate and investment with generic enthusiasm or colloquial wording

Name the kind of problem (portfolio visibility, trustworthy numbers) and the experience that connects, and learn the sector's plain professional terms beforehand. Reports say vocabulary matters, so rehearse the answer aloud.

Questions & practice

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

How would you design a scalable system for monitoring portfolio infrastructure?

Medium · Technical and Domain Proficiency

Approach

Pin the scope before drawing anything: what counts as infrastructure here (cloud resources, servers, building or site sensors), roughly how many assets and metrics per asset, how fresh dashboards must be, and how quickly an alert has to fire after a fault.
Ingestion: collectors or agents send metrics to a durable queue (Kafka, Kinesis or Azure Event Hubs) partitioned by asset id, so a burst is buffered instead of dropped and consumers scale horizontally; consumers write to a time-series store.
Control storage with rollups and retention tiers: keep raw points for a short window, downsample to per-minute or hourly aggregates for long history, and keep label cardinality bounded, because unbounded tags (request ids, user ids) are what blows up a metrics store.
Keep alerting separate from dashboards: evaluate rules on the stream, require a condition to hold for a set period to avoid flapping, deduplicate and route alerts, and add heartbeat (absence-of-data) alerts, since a dead agent sends no error at all.
Trade-offs to name: push versus pull collection, skew from a few very chatty assets on one partition, and monitoring the monitoring pipeline itself so an outage there is not silent.

Follow-up

What happens when a large group of sensors suddenly sends ten times its normal volume?
How do you stop one failing site from paging the on-call engineer hundreds of times?
Which data would you keep at full resolution for a year, and what would that cost?

Explain your approach to ensuring data integrity in a high-volume environment.

Medium · Technical and Domain Proficiency

Approach

Define integrity before the mechanisms: no lost records, no duplicates, values that are valid, and agreement between systems that hold the same fact. Each needs a different control.
In the relational layer, let the database enforce what it can: NOT NULL, CHECK, UNIQUE and foreign-key constraints, and wrap multi-row changes in a transaction at an isolation level that matches the anomaly you are guarding against.
In pipelines, assume at-least-once delivery and make writes idempotent: an idempotency key or natural key plus an upsert (INSERT ... ON CONFLICT in Postgres, MERGE in SQL Server), so a retry cannot double-count.
Avoid dual writes to a database and a queue; use a transactional outbox so the event is committed with the row. Handle concurrent updates with a version column (optimistic locking) to prevent lost updates.
Validate at the boundary and send bad records to a dead-letter or quarantine table instead of dropping them, then run reconciliation jobs (row counts, sums or checksums per batch between source and target) and keep an append-only audit history of changes.

Follow-up

Two services update the same asset record at the same moment. How do you stop one change from overwriting the other?
How would you find out that a pipeline had been silently losing a small fraction of records for a week?
Foreign keys slow down your bulk loads. Do you drop them, and what replaces them?

How do you balance technical debt with the need for rapid feature delivery?

Medium · Technical and Domain Proficiency

Approach

Treat debt as a cost with interest: rank it by how often the code is touched and how much it slows changes or causes incidents. Debt in a frequently changed or incident-prone module gets paid first; stable code nobody touches can wait.
Make it visible and measurable: log debt items with their observed cost (hours lost, incidents, slower lead time or a higher change failure rate) so prioritising them is a trade-off decision with a manager, not a matter of taste.
Pay it down incrementally: clean up the area a feature already touches, use the strangler-fig pattern to replace a bad component piece by piece, and agree on a standing share of capacity for debt with the team rather than asking for a rewrite.
When taking on debt deliberately to hit a date, record it with an owner and a trigger for paying it back, and name the lines you do not cross: security controls, data correctness and access rules are not deferred.
Back it with one real example in first person: "I shipped the report with a hard-coded mapping, logged the debt, and replaced it in the next cycle once a second team needed it."

Follow-up

How do you convince a manager to fund a refactor that ships no visible feature?
Tell me about debt you chose to take on that later caused a problem. What would you do differently?
How do you tell real technical debt from code you simply would have written another way?

Describe a time you had to troubleshoot a complex production issue under pressure.

Medium · Technical and Domain Proficiency

Approach

Pick an incident you led or drove, and open with the impact in concrete terms: what was failing, for whom, and how you found out (alert, user report, dashboard).
Show the sequence: mitigate first (roll back, disable a feature flag, fail over, add capacity), then diagnose. Say explicitly that restoring service came before finding the root cause.
Walk through the narrowing: what changed and when (deploys, config, traffic, upstream dependencies), then logs, metrics and traces to split the system in half, testing one hypothesis at a time and saying what each check ruled out.
Cover the pressure part directly: how you kept stakeholders updated at a steady cadence, who you pulled in, and how you avoided making several changes at once.
Close with the fix and the prevention: the root cause, a blameless postmortem, and the specific monitor, test or runbook you added. A story without a lasting change, or one where someone else found the cause, is weak.

Follow-up

How did you confirm the fix worked rather than the problem just going quiet?
What would you have done if rolling back was not possible, for example after a schema migration had run?
What alert would have caught this earlier, and did you add it?

Suggested practice checklist

Day 1 — Map the three rounds and write your recruiter story

Write down the reported sequence: Recruiter Screen, Technical Interviews, Final Interviews, and mark which type of question you are least ready for.
Write a short career walk that finishes on the role's stack: Python, Java or C#, relational databases, AWS or Azure.
Outline your answer to why you want to apply engineering skills to real estate and investment, and list ten plain sector terms you will use correctly.

Deliverable: A one-page loop map, a written career walk, and a written motivation answer with the sector terms list.

Day 2 — Design the portfolio monitoring system

Draw the architecture for a scalable system that monitors portfolio infrastructure: sources, ingestion, storage, query path and alerts.
Walk through the reported scenarios aloud: tracking real-time changes across a large portfolio of assets, and a sudden surge of sensor data. Note the first thing that breaks in each and your fix.
Write down your consistency, retention and security choices, and the metrics you would watch on the system itself.

Deliverable: A labelled architecture diagram, plus a short failure-mode list covering the surge and the change-tracking scenarios.

Day 3 — Data integrity and relational data

Write a layered answer on ensuring data integrity at high volume: constraints, transactions, idempotent writes, reconciliation and auditing.
Work the practice problems on holding a per-tenant cap under concurrent creates and on diffing a projection against the primary, and write one sentence on each race or mismatch you found.

Deliverable: A one-page integrity checklist and three solved practice problems with notes on the failure each one guards against.

Day 4 — Cloud cost and production incidents

Pick one real cloud workload and write its baseline, the changes you made, the trade-off and the result in your own numbers.
Write a timeline for one production incident: detection, first hypothesis, what you checked, the fix, and the follow-up that prevents a repeat.
Say both answers aloud and cut each until the reasoning, not the setup, takes most of the time.

Deliverable: Two written STAR outlines, one for cloud cost and performance and one for a production issue under pressure, each with real figures or timings.

Day 5 — Technical debt and coding fluency

Write your position on balancing technical debt with rapid feature delivery, with one example where you paid it down and one where you deliberately deferred it.
Work the practice problem on archiving a resource graph without recursion or broken live references, and state the complexity of each solution.

Deliverable: A written technical-debt position with two examples, and two coded solutions with stated time and memory complexity.

Day 6 — Stakeholder and team stories

Write STAR outlines for explaining a technical concept to a non-technical stakeholder and for how you handle feedback from team members or management.
Write STAR outlines for disagreeing with a project direction and for keeping your work aligned with team objectives, each ending with a clear result.
Say all four aloud, then replace jargon with plain terms and add what you did differently afterward.

Deliverable: Four STAR outlines, each with a measurable or observable outcome and one change in your behaviour.

Day 7 — Full mock and questions to ask

Run a full mock in order: recruiter-style introduction, a spoken portfolio monitoring design, an incident story, and a disagreement story.
Mark where you rambled or skipped a trade-off, then fix those answers.
Write at least three questions for your interviewers about the team's technical challenges and how engineers work with analysts and operations staff.

Deliverable: A recorded or written mock with corrections, and a final list of three or more questions to ask.

Behavioural preparation

The reported people questions cover cloud experience told as a story, explaining technical ideas to non-technical colleagues, handling feedback, disagreeing with a direction, aligning with team goals and your reason for entering real estate and investment. Reports also mention stakeholder management and adaptability when requirements shift, which fits a role that serves analysts and operations managers. Build each answer as a STAR story where you made the decision and can state the result.

What is your experience with cloud infrastructure, and how do you optimize for cost and performance?

Medium · Technical and Domain Proficiency

Approach

Choose one workload you actually ran in AWS or Azure and state it in a sentence: what it did, who depended on it, and the monthly cost or latency problem you were asked to fix.
Start with measurement. Name the baseline: cost by service from the billing breakdown with resource tags, and p95 or p99 latency and utilisation from monitoring. Say what the data showed before you touched anything.
Describe the levers you pulled and why: right-sizing idle instances, autoscaling, commitment discounts for steady load, storage tiering, cutting cross-region transfer, caching, and fixing slow queries or missing indexes instead of buying a bigger database.
Show the trade-off explicitly: where you accepted more latency for lower cost or spent more to protect a reliability target, and how you checked the change had no regression (canary, load test, alert thresholds).
Close with the result in the original units, plus the guardrail you left behind, such as budget alerts or a cost dashboard. If you lack exact figures, give a clearly labelled range rather than invent precision.

Follow-up

How did you prove the saving came from your change and not from lower traffic?
When would you deliberately pay for more capacity?
How would you attribute cloud cost to different teams or products?