I think most SDEs would acknowledge that the typical whiteboard interview process is flawed. Some might say it's still the best we can do, given the constraints. There's research (https://bit.ly/2MOTQoS) suggesting that in general interview success is a bad predictor of employee success/happiness. I also heard someone say recently (apologies for not remembering where so I can't cite it) that interviews might actually hurt your chances of picking the right candidate because the decision-makers tend to over-weight the interview experience relative to the credentials. What are your observations/theories/data about how organizations' hiring practices influence the quality of the code base as a whole (ie not the individual's coding abilities)?
Years ago my college roommate was in a band. They played local gigs at college bars and local festivals, etc. They never made much money from it, so they were constantly replacing band members. What I noticed from sitting in on some of the auditions for various bassists, guitarists, and drummers is that anyone with the courage to audition had chops. They had been in other bands, they had CD's showing what they could play, and they could make it through a jam session (some better than others). The pattern I noticed was that none of that was as important as how the new band member acted after joining. Did they show up to rehearsals and gigs on time, did they mesh creatively with the rest of the band when writing and learning songs, just general culture fit.<p>As a former director of engineering, that lesson always stuck with me. When hiring engineers, I never cared much about what college candidates went to, or what companies they worked for, or how they whiteboarded. The thing I looked for were signals that would indicate this person would not fit in with the team culture, take a long time on tickets compared to peers, ignore clean code or performance, etc. If you are optimizing for that, then Automattic has one of the best hiring processes around. You do the interview async, and then you have a 6 week contract to work on tickets (based on actual past tickets). I went through the process and hated the work and the company, and they also thought I focused too much on the code and not the customer. A perfect outcome in my opinion. A standard interview process might have resulted in an offer and my acceptance.
I wrote a bit about interviewing here <a href="https://nojvek.substack.com/p/how-to-make-coding-interviews-better" rel="nofollow">https://nojvek.substack.com/p/how-to-make-coding-interviews-...</a><p>1) white board interviews are good for brainstorming, terrible for writing code in<p>2) Coding questions consider whether candidate can write code, ask more details about the problem space, iterate possible ways to solve a problem and list their tradeoffs.<p>3) Talk to the references<p>A lot of times it is not about the candidate, it is how well you onboard and mentor them.