On a great interview question

Between 2010 and 2019 I interviewed dozens of Software Engineer candidates at Google. Almost always I asked the same interview question. Moreover, this question happened to be on the banned list at Google, because it was publicly available on Glassdoor and other interview websites, but I continued to use it because I got good signal from the candidates. <a href="https://www.linkedin.com/in/dtunkelang/" rel="noopener ugc nofollow" target="_blank">Daniel Tunkelang</a> had a similar positive experience with this problem but retired it back in 2011: “<a href="https://thenoisychannel.com/2011/08/08/retiring-a-great-interview-problem/" rel="noopener ugc nofollow" target="_blank">Retiring a Great Interview Problem”</a>. That is an excellent read by itself, but since my experience with this problem has been more extensive, I decided to write it down. <h1>Why this is a good interview problem</h1> The problem starts simple. Really simple, to the extent that some candidates think they have not understood it correctly. From there it explores the candidates understanding of various basic algorithms and data structure concepts. Moreover, the problem as I present it, has enough range to sift out bad candidates from good ones even if the candidates have seen the problem before, which is why I successfully used it even though it was banned at Google. Twice I asked the hiring committee if I should stop using this and they had no problem with it. <h1>The interview</h1> This is a 45-minute technical interview for Software Engineering positions, from junior to mid-level candidates. Maybe surprisingly, junior candidates sometimes rank better at this problem because their Data Structure & Algorithms knowledge is more fresh. But this pattern is not universal. Good senior candidates have no problem with the interview at all. A few anecdotes that have stayed with me: <ul> <li>I once had a candidate with 15-years work experience give me lots of attitude for asking them such a simple question, while at the same time struggling at it.</li> <li>The fastest I had a candidate solve the entirety of the problem with all bells and whistles was in 20 minutes, by a freshman from the University of Waterloo, the type who did high-school competitions.</li> <li>The most depressing failure I saw was a PhD graduate from University of Toronto who could not produce working code for the first section of the problem in 45 minutes.</li> <li>A candidate upfront told me that they have seen the problem. I grinned and said “great, so you should know how to solve it!” and they still struggled with it.</li> <li>Another candidate had clearly memorized the solution code and jumped to writing it. I asked them to step back and go through the steps I asked them to. They also struggled. They were also dishonest about having seen it before.</li> </ul> I start by telling the candidate that I like to hear their thought process, and I do not want them to write code until I ask them to do so. I then tell them that there are two parts to the problem. <a href="https://behdadesfahbod.medium.com/on-a-great-interview-question-aea168279942">Visit Now</a>