Your next interview should start with the work.

Two candidates finish a backend assessment with the same score. One handles the obvious cases, but their query counts the same order twice. The other gets the aggregation right and misses a date boundary. The totals match. The conversations you should have with them are different.

You learn that by opening their work. A score helps you find a result; the answer helps you understand it. That is the starting point for a useful assessment and a more specific interview.

Choose a piece of the actual job

Start with a responsibility the person will have. If your backend developer will build reporting endpoints, a small data problem can reveal how they handle relationships, missing values and business rules. You do not need to test every technology in the job description.

Write down what you want to understand before choosing questions. Can they avoid double-counting? Do they make their assumptions explicit? Can they explain what would change when the data grows? These give you a purpose for the task and a basis for reviewing the answer.

In SkillsDB, the test library gives you questions to start from. Combine the formats your role needs, review the questions and add your own where the work calls for something specific.

Keep the task small enough to discuss

You have customers, orders and order items. Return each customer’s completed-order revenue for the last calendar month, including customers with no orders. Explain your assumptions about dates and cancelled orders.

That prompt leaves room for reasoning without turning into an unpaid project. Provide the schema, define the expected output and make the time boundary clear. If an ambiguity is intentional, tell candidates you want them to state an assumption.

Try the task yourself before inviting anyone. Check that the examples agree with the question and the time limit leaves room to think. Send each candidate their own invitation. They can take the assessment in their browser without creating an account.

Inspect the answer before the interview

Look at the join, the filter and the aggregation. Does the candidate filter the orders before joining them to customers? Would their approach accidentally remove customers with no orders? Does a second order item change the total in a way they did not intend?

SkillsDB brings the submitted answers and grading feedback together. Multiple-choice questions score automatically, code runs against test cases, and written answers receive AI feedback against the rubric. Review the underlying work when a result needs explanation. Feedback can point you toward a question; your team still needs to interpret the answer.

Ask about a decision they actually made

Bring one or two observations into the interview. “What happens to a customer with no orders here?” is more useful than asking the candidate to recite join types. “How would you handle refunds?” extends the problem and gives them a chance to explain a trade-off.

Let them revisit a mistake. Ask what they would check, how they would test the correction and whether the change affects another part of the query. You are trying to understand how they work through a problem, including what they do when an assumption turns out to be wrong.

Give the team the same starting point

Keep the assessment and its results in the team’s workspace so interviewers can open the same evidence. One person can explore the data reasoning while another discusses how the candidate would expose the result through an API. Both conversations start from something the candidate has already done.

A focused task, a close reading and a few specific follow-ups can make the assessment part of the interview itself. Start with the work, then give the candidate room to explain it.