A Method I’ve Used to Eliminate Bad Tech Hires

needs a sense of humor but the right kind of humor. "shit" too edgy.

I never really know how much time to spend on take-home problems. I could spend a lot of time on it and it should be better -- possibly demonstrate more of my skills -- but often that ends in it being over-engineered and ultimately bad or otherwise unrepresentative.

Getting paid could provide the ideal constraints for the problem at hand.

Hey, you can take the words out of my mouth. I like IntelliJ as well.

Thanks for your reply.

Your instincts are good here - one cited problem was indeed the departure from standard conventions. I had my reasons, not saying they were good ones, but I didn't get a chance to explain them either.

I'd like to, but it appears I won't get that chance. I gotta say, that is the part of this all I don't really like. It was vastly better than my only previous experience with a take-home project, where I didn't hear back for a month and got a one-line brush off from a recruiter. In this case, I am certain that they looked over the code reasonably carefully - they did provide a short bit of feedback, though it was delivered by a recruiter, and there was no back and forth here. I'm ok with not getting a job, but I would have liked an actual follow-up where we reviewed the code after that level of effort and time invested.

Lastly, the job was fairly senior, so it may have been a high bar, and that wasn't the only problem with the code. Then again, how much are you really supposed to work on a sample project?

Overall? I'd be hesitant to do this again. I might ask in advance what the policy is on a review. Maybe a 30 minute conversation is a requirement for me to do this. Still mulling it over.

Basically, you just wrote nearly (exactly?) what I wanted to write. I'm good at algorithm problems. I LIKE algorithm problems, but having someone watching me on a whiteboard in a high pressure situation diminishes my abilities. At a minimum, it is a distraction. If it is an easy or familiar problem then it usually doesn't matter and we can discuss the solution and I might even want to talk about it. But if it is a tricky problem -- and a lot of tech companies intentionally give problems that are tricky or vague or superficially easy -- then I need to use my natural process for systematically and rigorously tackling tricky problems. I'll still probably finish it in a half hour and we can still talk about the solution and discuss improvements but let me work on it alone first.

One thing I've found from technical interviews is that, due to the pressure to speak and communicate and "show my thoughts", I'm more susceptible to falling prey to trick and vague questions that I would otherwise treat more carefully. This is consistent with scientific results on the way people respond the pressure situations[1]. They tend to fall back on what is familiar instead of trying approaches that may be better. Working alone, there is no fear of judgement if I need to try an unusual strategy[2] that may not work or if I need to backtrack. Let me dabble and doodle on my own sheet of paper and iterate rapidly over whatever comes to mind freely.

Furthermore, turning problem solving into a theatrical event unavoidably increases the cognitive load on an interviewee simply due to the fact that you have to make more decisions. You have the technical decisions like data structures and algorithms which are normal and expected, but on top of that, there are all these non-engineering decisions that you have to make because they want you to talk about how you're solving the problem in real time. Should you mention some fancy algorithm or approach that you are considering? You must choose your words carefully since anything you say can be used against you.

I'm not claiming that everyone works better alone or even that I don't like working with others. I just think that the interviewee should have the option of working on the problem alone for up to 30 minutes. As suggested by parent, we can discuss the solution or non-solution after I've become familiar and comfortable with the problem. One of the worst feelings is when I fail to solve a problem during an interview, only to have the solution come easily when I'm able to tackle the problem in a pressure-free environment. Expecting some kind of portal into someone's mind while they solve an unfamiliar and maybe tricky problem strikes me as overindulgent and voyeuristic. It is a flaw in the current technical interview process and the only way to mitigate its effects is to just get more comfortable interviewing.

[1] - https://www.psychologytoday.com/blog/choke/201106/flocking-t...

[2] - For tough problems, tend to use my own idiosyncratic variant of Z-Notation. I have a very high success rate solving algorithm puzzles when I use it but it is easy to forgot to use it under pressure of an interview.