I think that JUST looking at how well someone solves a whiteboard question is a poor predictor of a success in a job. However, if a person can not solve a reasonably sophisticated problem, it is a good predictor of failure. You can look for signs of initiative, admitting mistakes, bluffing, attention to detail by looking how the person goes through the written screen and interview.

What is a reasonably sophisticated problem varies. It should be something that does not involve "trivia knowledge" of a particular algorithm. Ideally, it should be something that can be solved multiple ways.

It all starts with a written screen. In it I have a small programming exercise. A candidate needs to demonstrate that they know the diff. between the performance characteristics of a LinkedList vs. ArrayList. Both provide a working solution, but only one of these two provides a performant solution. The problems stresses performance. Also, ChatGPT provides the WRONG solution (it works, but not performant) and I can find some tell-tale signs that they used AI to solve it. There is also potential for an off-by-one error.

Im the interview, I start by going through a small gauntlet of super simple exercises (reverse a list, count items, show uniques, print while maintaining insertion order). They are framed as word problems. This show that the person knows the basic data structures available in Java. List, Set, HashSet, LinkedHashSet, TreeSet, HashMap, LinkedHashMap, TreeMap. There's room to show off with trees, dequeues, and stacks for more ambitious folks but the basics suffice.

I have a algo design problem that I use. It scales well from juniors to seniors. It's not exactly a whiteboard problem. I ask the candidate to talk through a solution in pseudocode. My wife was able to solve it when I reframed it in Excel terms even though she is not a programmer. It shows that a person can understand instructions, keep several requirements in their mind at the same time, communicate their thoughts clearly, and ask clarifying questions.

When they come up with a solution, we start talking about how well it performs. I ask questions about how it could be implemented differently to use less memory. We talk about how it could be implemented using SQL, or Java Streams.

Regularly I see people coming up with strangely awkward programming constructs to implement basic parts of the solution. People routinely forget one of the two requirements of the problem. I run into senior programmers who don't think to use a Set to ensure uniqueness. People who don't know that a TreeSet can sort entries. People who know the definitions, but when it comes to applying that knowledge to a word problem, stumble completely.

My interviews are conversations. I start shallow and go deep. I try to see where people's knowledge ends. When they don't know how something works, I ask them how they would implement something themselves.

I turn away people who seem to have the knowledge but can't communicate well. Software development is a team sport. If you can't explain what's in your head clearly in a reasonable amount of time, we will waste a lot of time. If you can't follow a clear explanation of a concept and keep losing important bits along the way, work will be difficult.

If you want to talk I can hop on a call. I am passionate about this. Also, I am currently interviewing mid-level Java Backend Devs, so my thinking is current. Email me - contact info in profile.