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
Fundamentals are solid
You explained indexing, transactions and HTTP semantics correctly and without hesitation: the technical base an interviewer needs to see early.
Concrete over textbook
On idempotency you reached for a real payment-retry example instead of a definition, which is what makes an answer land.
Where to focus
Answer in two parts
Several answers gave the what and stopped. Lead with the direct answer, then one sentence on why it matters.
Practice: For your next five answers, force a second sentence starting with "which matters because…".Fill gaps out loud
On the connection-pool follow-up you went quiet rather than reasoning. Saying what you'd measure keeps you in the conversation.
Practice: When unsure, narrate the check you would run instead of pausing.
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.