💼 Interview Questions

Interview Questions: These questions span everything above: basic onboarding knowledge, intermediate day-to-day usage and trade-offs, and advanced production/architecture scenari

These questions span everything above: basic onboarding knowledge, intermediate day-to-day usage and trade-offs, and advanced production/architecture scenarios. Basic ≠ "definition trivia" here — even the easy ones are framed around a real decision you'd actually make on the job. Think of it like a cooking interview: nobody asks a chef to recite the boiling point of water. They hand them ingredients and watch what gets reached for first. The knowledge is assumed; the ordering of decisions is what is being measured. So why do so many candidates who "know Bruno" still stumble here? Because knowing a tool and being able to justify choosing it are different skills. "Bruno stores collections as files" is a fact anyone can repeat. "We moved to file-based collections because our API tests needed to go through code review like the rest of our repo, and cloud sync gave us no diff" is an argument — and the second one is what tells an interviewer you have actually run this in a team. The same split exists in Java interviews: reciting what `PreparedStatement` does separates fewer candidates than explaining why you would reject string concatenation in a code review. In both cases the discriminator is not the definition but the reasoning attached to it. For QA there is a practical rule buried here: for every answer, be ready with the trade-off you accepted. Every tool choice costs something — Bruno's cost is that secret management becomes your team's responsibility rather than a vendor's. A candidate who names the cost sounds like someone who has shipped; a candidate who claims there is none sounds like someone who has read a landing page.

Interview Lens — Read the Bruno UI Like an Interviewer Would

🎬 The Same DELETE Twice: What Idempotency Testing Expects

200 (idempotency bug)

A "delete order" flow is being tested. The first question: what should happen if the SAME DELETE request is sent TWICE?

Step 1 — the first DELETE is sent: the resource genuinely exists, the server deletes it and returns 200/204.

Step 2 — the resource is now gone. bru.setVar() stores the orderId so the second request retries the SAME ID, not a different one.

Step 3 — the SECOND DELETE is sent with the same orderId. This is the heart of a real idempotency test: what should return when the resource is already gone?

Step 4 — the correct behavior: 404 "Not Found". Saying "it was already gone" is different from saying "successfully deleted again" — the assert EXPECTS 404.

Final (the contrast) — had there been an idempotency bug: the second DELETE would also return 200/204, as if something were deleted again — proof the backend NEVER tracks the "already deleted" state, and the assert exists specifically to catch this gap.

Step by Step: One Token-Refresh Spot for 50 Requests

Collection-level pre-request script

The refresh logic is placed in ONE spot, the collection's (or top folder's) pre-request script — not copy-pasted into all 50 requests.

bru.getVar("tokenExpiry") reads the stored timestamp and compares it against the current time.