How do you manage the technical tests after an interview ?

A method I've personally used for many years is to have the candidate do a coding "test case" prior to the technical interview. The case shouldn't be big, or hard/tricky, and shouldn't take a lot of time to do (if you know what you are doing = 1 hour) - preferably it should be described in a paragraph. The instructions for the candidate should say that although small, the candidate should make the sure it is production quality. Something of the shape that they would do a pull request for to be merged to the production branch. During the technical interview - you both got a recent code base to discuss and look at. How did the candidate come up with the solution? How is it ensured the implementation is correct? And so on... Note that the point is not to see if the candidate can solve a tricky problem, but to create something the candidate knows 100%. Now - depending on level of seniority - put the implementation through different scenarios and ask the candidate how they would do it? "What if you needed to expose this implementation to external customers, what would you do then?" "Ok, if you got an enormous amount of requests - where would the bottle neck be?" "In what way would you scale this?" "If, by some reason, processing the result would take several minutes - how would you change the implementation then?" You would ask different questions of a junior candidate compared to a senior. A senior you could expect to reason about architecture, message queues, cloud services, etc. While with the junior candidate it may be more relevant to talk about testing for example. I think this method is pretty good - it gives good insight into the developer experience, and it doesn't stress someone out because they have to live code something, or remember some trick algorithm question only people straight out of university remembers.

Technical tests can't differentiate candidates. They can at a minimum declare a candidate fit for service.