Coding problems and impact on diversity! Why ask Binary tree inversion?
I have discussed this particular topic so many times with friends and colleagues, and the usual trigger goes like ‘when was the last time you had to invert a binary tree’?
I won’t get into the long story but just share the conclusions.
Don’t let the perfect be the enemy of good.
It is actually well accepted fact that interviews are not the perfect tool for jobs. Internship are the best, but I bet a existing FAANGUM engineer will not be thrilled to “intern”.
Let's start with objectives and constraints of the interview process
1. Identify the best candidate among pool of interviewees
2. Don’t make it heavy on the interviewer or interviewee. 2 hours per interviewer(pre/post debrief, notes, interview itself) and no more than 7 hours for the candidate.
Now ‘best’ is pretty subjective, but in a large company the skills we identify are generic enough across most of the engineering teams. Every single interview loop I have been part of in MSFT/AMZN/UBER, candidates can choose any language. For specific roles there is additional round but rest of the process stays same.
So by decree of ‘identify generalized best candidate’, we have eliminated need to master
- Language (from C to Python)
- Platform, OS (UNIX, Linux .. Microsoft)
- Tech stack (embedded programmers to quant programmers)
Now you know why we will not ask a specialized question on virtual functions in C++ or dealing with registers and interrupts in code. This leaves very few areas where we can test the deep knowledge of candidates. They are namely ‘Design and Architecture’ and coding.
Folks usually get a fuzzy read on how they did in D&A round, so very few people blame D&A for failing interviews. The eventual consistency and scaling patterns have so many nuances that unless you know as much as interviewers, you won’t know you did good or not. Perhaps more people get rejected because of D&A round than coding. So naturally the D&A round never gets the heat that is received by coding round.
Speaking as a hiring manager, we look for folks who are passionate about what they do. We respect everything that is not coding, but for coders, I would expect the candidates to love coding. And a natural side effect of this is, those who really like coding, they are very good at it. Granted there is NO way of knowing who is passionate about coding versus who has spent lot of hours at coding practice while not enjoying it.
The real difference between who like to code and solve the problems versus who don’t like it, is not always external, but the sum total of happiness they would receive from the same job.
To be clear, coding is a no special skill compared to singing or gymnastics. May be it is easier compared to singing and gymnastics. It just happens to be higher paying, on average, in this day and age.
Now the practical problem. Consider you have to choose one candidate among 50 really bright folks. If everyone can solve a knapsac problem, you will add a branch and bound problem. Now what if all them can solve every branch-and-bound problem? You will add DP problems to differentiate, who among them is best programmer (data-structure, problem-solving, coding). Inverting trees will quickly become your phone screen question, as those who can’t solve binary tree inversion, they probably can’t solve more complex onsite problems. This becomes arms race between the candidates and usually the winners are in one of the three category
A. Passionate and enjoy learning/coding or
B. Meh but spend hours anyways (they can be passionate about something else)
C. Exceptional folks who pick-up naturally
Regardless of the category, all three categories in FAANGUM usually can crack novel DP problems they haven’t encountered before.
Now about why this is not a perfect way to judge candidates:
1. Some smart & passionate folks would have spent much less hours learning/coding compared to others. I had interviewed a journalist candidate who picked up programming like fish to water, but she didn’t crack DP problems. I knew she had just taken couple of courses on comp-sci a year ago. We made the offer call. She was one of the best hire in that year.
2. Some candidates are passionate about solving problems more than learning programming. A while ago we came across, a candidate with plenty of open source contribution (hallmark of a great problem solvers) who didn’t bother to read on latest questions asked in interviews. This was in a company where we couldn’t bend criteria to get that person in. It was a bad no-hire decision, as the candidate excelled in his career in a different company.
3. Not everyone has bandwidth to spend weeks and months preparing for interviews. This means folks who are passionate and smart, could get “out-competed” by those who can spend 6+ months practicing coding.
Now we make an assumption that over all, number of folks getting rejected for wrong reasons is so few, that it doesn’t make sense to change the coding bar. But hiring managers do tend to make judgement call, from time to time.
Summary for candidates — Tough coding problems is a harsh reality that is a result of competition and lack of better way to differentiate. See in which category you belong (A/B/C) and choose your effort accordingly.
Summary for HMs and Leaders — Have rules. But empower the people to find exceptions and take risks. That's how you build diversity.