What a Novograde assessment looks like
A real example, end to end — so you know exactly what to expect before you start.
During the assessment
You answer five role-specific questions. After each answer, you get instant, honest feedback — here's a sample question with the feedback it produced.
Feedback on your answer
Strong instinct to separate p99 from average — that immediately points at tail latency rather than a broad regression. You correctly reached for distributed tracing and flagged connection-pool exhaustion as a likely culprit. To go further, you'd want to rule out slow-growing data (a table without an index that's only now large enough to hurt) and check whether the regression tracks request volume rather than time.
Your API's p99 latency has crept from 120ms to 800ms over three weeks, but average latency looks fine and no single deploy correlates with the change. Walk me through how you'd isolate the cause.
Your final report
At the end you receive a full scorecard: an overall score, a category breakdown, strengths, weaknesses, suggested next steps, and a personal coach's note.
Overall Score
8/10
Category Breakdown
✅ Strengths
- • Reasons from first principles rather than reciting patterns — separated tail latency from averages without prompting.
- • Strong production instincts: reached for tracing, connection pools, and data growth as concrete hypotheses.
- • Communicates trade-offs clearly, weighing cost against reliability instead of giving absolute answers.
❌ Weaknesses
- • Best-practices answers leaned on convention without always justifying why — occasionally 'because that's standard' rather than the underlying reason.
- • Less fluent on observability tooling specifics than on the conceptual debugging approach.
📚 Suggested Next Steps
- • Deepen hands-on familiarity with a tracing stack (OpenTelemetry + a backend like Jaeger or Tempo) to match your strong conceptual debugging.
- • When citing a best practice, practice stating the failure mode it prevents — it'll sharpen already-solid judgement.
- • Explore capacity planning and load-testing tools to round out the operational side.
Authenticity
Natural
Answers included hedging, self-correction, and a specific personal anecdote about a past incident — all consistent with genuine recalled experience rather than rehearsed material.
💬 Coach's Note
You come across as a pragmatic engineer who thinks in systems, not snippets — the kind of person who's actually debugged a 2am incident, not just read about one. Your strongest move is reasoning from symptoms to causes without panicking, and it shows. The growth edge is small but real: make your tacit knowledge explicit, because the 'why' behind your instincts is what turns a strong senior into someone others learn from. Keep going — this is a genuinely good foundation.
This is a sample. Yours will be tailored to your role and your answers.
Start your own assessment →