Backend, Python
Stage-by-stage report
Interview Q&A
Solid performance
How this stage was scored
Solid on the fundamentals. You explained indexing and query planning correctly and gave a real example of when a composite index stops helping.
Two follow-ups went unanswered. When asked why a connection pool has an upper bound you restated what a pool is rather than addressing contention on the database side.
Answers were short and often trailed off. Several times you gave a one-line answer and waited, which leaves the interviewer to do the work of drawing you out.
Topic breakdown
Strengths
Where to focus
One thing to fix next
Your technical accuracy is already interview-standard. The thing holding this stage down is length: aim for three or four sentences per answer, and finish by naming the tradeoff.
Per-question breakdown
Your answer
It stores a sorted structure so lookups avoid a full scan. It stops helping when the column has low cardinality, or when the query needs so many rows that a scan is cheaper anyway.
Correct and well-scoped, including the cardinality point most candidates miss.
Your answer
Because you do not want unlimited connections.
This restates the constraint rather than explaining it. The answer is that each connection costs memory and a server-side process, and past a point they contend rather than add throughput.
Your answer
Probably how many the database can take.
The follow-up existed to give you a second chance at the reasoning. Naming a metric — active connections against p99 query latency under load — would have recovered most of the marks.
Your answer
An idempotent request can be retried without changing the outcome. For payments it matters because the client may retry after a timeout without knowing whether the first request succeeded, so you key the operation on a client-supplied idempotency key and return the original result on a repeat.
Strongest answer of the stage. You covered the mechanism and the reason, and you anticipated the retry case without being asked.