Half

I hate coding questions, and give exactly one question to people - but there's many, many reasons why I do so. It is in a screen-shared environment, where I tell the person they can ask me absolutely anything, and we talk through the problem and work out a solution collaboratively. Half an hour tops, no take-homes, and it's the second half of a two-step interview process (once for HR to make sure you're sapient, once with me for what I'm looking for). I give them a reasonably hard problem - I have a d20 I spin to pick the question, and all are roughly the same difficulty. I tell them, "it is a collaborative test - let's plan it together, and I'll let you write it. Ask as many questions as you can think of - there is no such thing as too much, and describe your thought processes and plans as you look through the prompt". What happens next, usually, is reading the question, thinking of some ideas, and then asking some clarifying questions before beginning to plan out a solution of some type. Things I'm looking for: #1: The ability to recognize a problem as a specific class or subtype of problem. This is for experienced roles mostly, but I pick leetcode questions that have sub-problems that tend to pop up when doing ETL (Extract/Transform/Load) operations, so recognizing how hard something is (If it's a search-like of O(log(n)), or a sort-like of O(nlog(n)), what have you) and what kinds of solutions work in that context is great! #2: The ability to clearly and concisely explain your understanding of a problem and the structure of possible solutions in a way that's understandable both to a fellow professional, and bonus points if you can simplify it to layman's terms. Communication and comprehension is unbelievably important in this field, and if you can't explain yourself, and can't understand project specifications, then it doesn't matter how talented you are at implementation - it'll be a struggle to point you in the right direction! #3: Asking questions! Especially with how bad documentation has been at some places I've been - this is what has caused the highest attrition rate of developers I've worked with: silently struggling, and silently failing. Everyone wants to be an island of productivity, but it is very hard as a newbie! An experienced developer can sometimes, in one minute, save a newer person an hour, just by knowing the exact right thing to do or look at. Experienced devs, in any shop worth its salt, are perfectly aware of the expectation of mentorship and advisory - and that plays into #2 very closely, as it's hard to be an advisor if you can't explain things! And yes, I've had interviewees ask, "What's the answer?", to which I excitedly would say the name of the algorithm (Edit Distance? "Levenshtein!", I'd say), only to, for some reason, get modest disappointment in return. If they were especially determined, they'd ask what a good implementation of it would be, and I'd describe in general terms how small parts of it would work, watching for when they're able to complete the puzzle themselves. I've also had interviewees ask, "Can I google some stuff?", to which I always answer, "yes, of course - you'll always have google at work!". If they're really struggling and we're about 10 minutes in, I'll mention that it's open-internet, and see how they research and learn independently. Because yes, while asking questions is important, #4: Ability to research and learn independently is also very important. If they destroy my problem without much effort, I'll half-heartedly ask an implementation question about what is, but shouldn't be, a relatively obscure API (the FHIR CMS Meaningful Use API standard) and ask them to do some quick (<5 min) research to check for comprehension - the ability to learn is the ability to stay relevant in a developer's world, ultimately. And if they can, without existing knowledge, learn of a solution, comprehend it and implement it, that leads to #5: The ability to plan a solution, and then execute on it Ultimately, it does come down to your ability to understand a problem and come up with a solution. If your theory is sound, but you get stuck on the implementation, but it's just stupid syntax bullshit or easy-to-miss variable name mismatching, I'll grade you more highly than someone who copy-pastes the solution and can't explain it. If I didn't value peoples' time, I'd absolutely do a follow-up question that involved using the exact same solution in a different way, but what I test for seems pretty thorough as it is. #6: Mood. When a problem seems hopeless, do you give up, or are you determined? Does a problem excite you? When you're stuck, do you reach out for help, or shut down? If I suggest that there might be a problem on a certain line (with almost that exact wording), do you look at it, fix it and go "oh sweet thanks", or do you get defensive/combative about it? Do you have an ego, or are you able to be wrong and thrilled to learn from your mistakes? &#x200B; I've been doing this for a couple years - and I'm sure others have way more experience than me, so feel free to ask me anything, or disagree with anything so I can learn! :D