I understand what you mean about ridiculous SV interview practices. And your point that all we should really be measuring is on the job performance is an import

I understand what you mean about ridiculous SV interview practices. And your point that all we should really be measuring is on the job performance is an important one. All I'm really going for is to ask someone to write some code live, on their laptop with their tools, so I can watch how they debug, how they think through things, etc. I want the problem to be hard enough that the person has to model execution in their head and that it's challenging to do so. I have found that there are people who can code decently well but get badly stuck when the complexity hits a certain level. I'm trying to not hire them in senior positions. For example, I had a recent project where we were analyzing user data and producing a bunch of edges representing potential connections detected between users, as a way of sniffing out fraud rings. One feature associated with this was a banning UI, allowing loss prevention types to navigate through the graph, select groups of users according to certain criteria, and generally look for patterns that are evidence of fraud rings manually, to supplement the automatically generated analysis. There are a lot of front end people who will go into brainlock on this kind of thing. I need to make sure I have some people around who don't. When making senior hires, I want people who can write code for this sort of thing without making a huge mess or just getting stuck for weeks. Presenting a real sample from a problem like this needs way too much context though. I'm going to keep thinking about how to precisely define the type of task that i'm really talking about here. My fuzzy definition about ability to model execution of X complexity in one's head is obviously weak and probably flat out wrong.