Brinlet

Sample run

See it on a sample CV

One CV, the interview questions it gets you asked, an answer with its score and one fix, and the second try.

  1. From the CV

    Mentored two junior engineers; introduced a design-review template the team now uses for every new service.

  2. The question

    You introduced a design-review template that the team now uses for every new service. What problem prompted it, and how did you get a 40-person engineering team to adopt it?

  3. One fix later

    6.5 → 7.9

    Target met: one clear main point, stated first

Sample run on a fictional CV, through the app's own question generator and scoring. Not a live demo. The answers are read by an AI voice from a written script; the app's pipeline transcribed and scored the recordings.

  1. The CV

    Priya Sharma, backend engineer: a made-up person, and a CV written for this run.

    First page of the sample CV: Priya Sharma, Backend Engineer, with experience at two payments companies, an open-source project, education and skills. Open the CV (PDF, opens in a new tab)

  2. The questions it asked

    From the question bank the app wrote for this CV. Each one comes from a line of it.

    • Batch to event-driven invoicing

      Walk me through how you led the move of invoice generation from a nightly batch job to an event-driven service on Kafka. How did you plan the cutover and what did you own?

      From the CV: Led the move of invoice generation from a nightly batch job to an event-driven service on Kafka; invoices now go out in under two minutes instead of the next morning.

    • Duplicate-charge post-mortem

      You ran the post-mortem after a duplicate-charge incident affecting 312 customers. What was the root cause, and why did you choose idempotency keys across all payment endpoints as the fix?

      From the CV: Ran the post-mortem after a duplicate-charge incident that affected 312 customers; added idempotency keys across all payment endpoints.

    • This run's question

      Answered in steps 3 and 4

      Design-review template and mentoring

      You introduced a design-review template that the team now uses for every new service. What problem prompted it, and how did you get a 40-person engineering team to adopt it?

      From the CV

      Mentored two junior engineers; introduced a design-review template the team now uses for every new service.

    • Settlement service at 1.2M a day

      Tell me about building the merchant settlement service in Go that handled about 1.2 million transactions a day. What were the main design concerns at that volume?

      From the CV: Built the merchant settlement service in Go, handling about 1.2 million transactions a day.

    • Scaling on queue depth

      In your open source autoscaler you scaled workers on message-queue depth instead of CPU. Why was that the better signal, and where might it fall short?

      From the CV: A small Kubernetes controller that scales workers on message-queue depth instead of CPU; about 300 GitHub stars.

  3. The first answer

    Answered out loud. Then the score, what went well, and the one fix to make.

    Interview question

    You introduced a design-review template that the team now uses for every new service. What problem prompted it, and how did you get a 40-person engineering team to adopt it?

    First answer · 0:49
    Transcript

    So, um, at Northwind, we were growing quite fast and, uh, a lot of new services were getting built and people would just start building and then in code review someone would say, oh, why didn't you use Kafka here? Or like, why is this a new database? So there was a lot of back and forth and sometimes things had to be redone. I was also mentoring two junior engineers and I noticed they didn't really know what to think about before starting. So I wrote a template. It's a doc with some sections like the problem, the options, the data, the rollout, that kind of thing. And, uh, um, I shared it in our engineering channel and some people started using it and then my manager liked it and, uh, it kind of became the standard. Now every new service goes through it. So, yeah, it was useful. I think.

    Overall score

    Overall score 6.5 out of 10

    Almost there

    Clarity
    6.3/10
    Structure
    6.7/10
    Delivery
    6.7/10

    186 wpm · 5 fillers · 0 pauses mid-sentence

    A clear, easy-to-follow account of the problem and the template's origin, but the adoption story is thin on the speaker's own actions in driving a 40-person team to use it.

    Strength: The problem framing is concrete and relatable: 'in code review someone would say, oh, why didn't you use Kafka here?' gives the listener a clear, specific picture of the pain the template solved.

    The one fix

    Clarity — One clear main point, stated first

  4. The second try

    The same question again, working on that one fix.

    Working on: Clarity — One clear main point, stated first

    Second try · 0:47
    Transcript

    The short version. I got a 40 person team to adopt it by making it the easiest way to get a design approved, not by asking people to use it. The problem was rework teams would build a service and only in code review would someone ask why it needed a new database. So work got redone. I wrote a one page template, the problem, the options we rejected, the data, and the rollout plan. Then I did three things. I used it on my own next service. So there was a real example I used. I walked through it at our engineering all hands in about 10 minutes and I asked two senior engineers to review designs only when they came in that format. Within a quarter, every new service was using it. And those design questions moved out of code review to before anyone wrote code.

    Target met

    Clarity — One clear main point, stated first

    You fixed both prior issues: adoption is now told through three specific actions you personally took, and the answer closes on the concrete outcome without the hedging tag from before.

    Opening sentence: 'I got a 40 person team to adopt it by making it the easiest way to get a design approved, not by asking people to use it' states the main claim first; the rest ('I used it on my own next service... I walked through it at our engineering all hands... I asked two senior engineers to review designs only when they came in that format') supports it with concrete owned actions, ending on 'every new service was using it' with no hedging.

    Clarity score

    6.3 → 8.2 (up)

    The drill landed, and your broader Clarity score rose too.

    Next: Number the three actions explicitly (First, Second, Third) to make the sequence even more scannable for the listener.

    Overall: 7.9

    Try it on your own CV. Free to start: 10 practices and 2 interview rounds.

    Download on the App StoreGet it on Google Play

    In the App Store and Google Play as Loquence until our next update.