interviews on C'est la Z

The Technical Interview - we can do better

Thu, 06 Apr 2023 10:22:02 -0400

I'm spending the week down in Atlanta. Never been before but since Batya is spending the semester teaching at Georgia State University, it seemed like a good chance to see her teach and check out a new town.

That was the plan anyway. At least until I made the unfortunate decision to come down with Covid again. Symptoms are mild but I'm stuck camping out in our Airbnb while Devorah and Batya can see the sights.

So, might as well spend the time writing a post or two.

The other day a younger friend announced that he got a new job on LinkedIn. He was caught up in an earlier round of big tech layoffs so it was nice to see him landing on his feet rather quickly. Still, knowing what he always brought to the table, I was surprised he was let go to begin with but then, so many big companies have positively moronic layoff policies.

Anyway, my friend was lamenting the technical interview process. As a devops person the algorithmic trick questions really don't apply, particularly since he already has a track record of actual, you know, devops work to point to. He actually called an interviewer on this at one point and even though, I'm sure he was 100% right, it did not go well. While he didn't go into details he talked about the interview process that landed him his forthcoming job and how it was much more reasonable and relevant to both the role he was applying for and if it and he were a fit.

The technical interview - that algorithmic brain teaser has been popular at big tech for a long time now. The big boys - Google, Facebook, and the others use it and since tech is a copycat league, so do most small houses.

If you're not familiar, the idea is that the candidate is presented with a problem to solve - something similar to the problems you'd get in a programming competition. It might be something like writing a routine to reverse a singly linked list or print the nodes in a binary tree level-wise. Of course, they can get much trickier and the candidate is doing this under the gun. It's stressful and in my view not a great way to assess a candidate.

The truth is, while there are some people who can just solve these problems on the fly, the reality is, for most people, they have to specifically train for this style of interview. The more problems they do, the more likely they'll see something they've already done or something similar to what they've already done.

Then it becomes the "can I fake it to make it look like I haven't seen this problem before" interview.

This is why schools where students have an easier time getting together to work on and share solutions have a huge edge in this process (read that as rich elite schools where kids live on campus and don't have to work to pay the bills).

This whole process works for the big and/or hot company - the Google's of the world because they can afford to miss a huge number of great candidates who wash out on the technical interview just so long as they fill their quota with candidates who can pass their test. Sure, it hurts diversity, equity, and yeah, talent, but if we're really being honest, big tech talks the equity and diversity talk much more than they walk the walk.

It's bad enough that the big boys use this flawed but convenient for them method. It's worse that everyone else feels compelled to do the same. It makes for a miserable stressful job search and in the end, for the vast majority of tech employees who were hired through this process, they never need to think about problems like these again.

I'm reminded of another friend of mine, Dan, who has been CTO / Head of Engineering for a number of small to mid size companies. He doesn't do a Google style technical interview. He told me once "I can't compete with Google. If I do the same interview that they do, I'll only get Google washouts - if they can pass the Google interview, they'll certainly chose Google over me." He came to the sensible conclusion that he needed to come up with another way of assessing candidate fit - something that would catch the amazing employee who didn't thrive under the algorithmic tech interview. It might make the process more complicated for the company or more time consuming but I wish more places followed Dan's lead.

In addition to my friend's post, I've also been thinking about this since I've been teaching data structures and specifically run time and whenever I do this I mull over where my focus should be. How important are the specific data structures we teach given that the minority of CS students will ever go on to need to know them at the level of detail we teach? Do we need to actually prove the run time of algorithms? Should we do more interview type problems because our kids by and large need them?

These are questions that should probably be talked about more in college CS programs. I'll share my specific thoughts on where I think the emphasis should be next time.

On Technical Interviews And Diversity

Sun, 28 Apr 2019 11:27:46 -0400

I recently stumbled upon Laurie Barth on Twitter and noticed a couple of tweets about tech interviews and the hiring process, something I've been thinking about recently.

Solid rant. I think the teach to the programming test market already exists. And it’s why interviewers who subscribe to these tactics get upset if a candidate admits they’ve seen the problem previously. Because it ruins the illusion that this is revealing how candidates think. https://t.co/DpHgQx0TST
— Laurie (@laurieontech) April 26, 2019

One of the things I often think about is feeling like I got lucky making it through some of my interviews...and then killed it on the job. We know interviews don’t match the on the job skills, it’s about time we did something about it. https://t.co/xmUXkGvtoA
— Laurie (@laurieontech) April 28, 2019

I guess I've been thinking about it because I'm teaching a section of Data Structures which, along with Algorithms, provides the base knowledge you need to have a shot at the typical "Google Style" technical interview.

I say "base knowledge" because just completing those two classes doesn't really prepare you. It gives you the building blocks but you really have to prep specifically for the types of questions they might give you. Unfortunately, for most kids it involves a whole lot of rejection and failure before you start getting offers.

You might get a problem that has a bad brute force solution and during the relatively short interview, devoid of your typical resources and comforts you have to turn it into a much more efficient one. The argument is that the interviewer is really trying to see how you think about a problem but having spoken to many, many tech employees who do these interviews that's a specious argument at best. It's really a test of "who has seen the problem or something similar before but can fake that they haven't the best."

While it's true that you will get some candidates who can solve the problems on the spot you're going to miss out on a whole bunch of great candidates who just don't do well on that "Google style" of interview. At the same time we keep hearing that, as Laurie tweeted, the skills required on the job don't match the ones needed to pass the interview.

This doesn't really matter to the big, hot companies. The Googles and Facebooks of the world. So many students coming out of college want to work for them that they can afford to miss on tons of great candidates so long as they hit on enough good ones.

I put the word "diversity" in the title of this post and you might wonder what I was going for there. So far, I'm just ranting about the interview process. This becomes a diversity and privilige issue because the process favors "elite" CS schools with established CS cultures. I'm not talking about the fact that they pre-select high performing candidates nor the fact that all the tech companies go to those schools, sometimes exclusively for recruiting. I'm talking about how the school's student tech culture helps prepare the students for the technical interview.

From my discussions with many graduates from many of these institutions, while classes don't prep for interviews, students at these CS schools regularly share interview questions. Friends and classmates talk about the questions they got and help each other out with practice sessions - formal or otherwise. I'm certainly not faulting students for doing this but it's another known secret. We all know that the more tech interview questions you see the better prepared you'll be - both because you'll get better at that specific problem solving skill and also because you'll likely get interview questions that are already in your library. It's that latter part that makes the whole process very nod, nod, wink wink.

Nothing stops other students at other schools from doing similar but it's much harder at a commuter school where kids live off campus and have to work part time jobs. It's the reason I'm fighting so hard for space and working on building a postitive tech culture at Hunter. Not specifically for interviews but to help my students become a support network for each other.

I'll finish by noting that while this "technical interview" process might more or less work for the big boys - the hot company du jour, it probably doesn't for eveyrone else. A buddy of mine was talking to me about the process he uses at his much smaller company. He noted that he could use the "Google interview" process for his future employees but since his company was much smaller and lesser known, people who did well would probably also get offers from the big boys and go work for them. His goal was to come up with a process that catches the great candidates that don't do well on the Google interview to try to catch the great talent that doesn't do well on today's technical interviews. A number of smaller companies seem to be starting to do this and from the few I've spoken to it seems to be going well.

I get that big companies are machines and look for uniformity in all processes including the interview process but there has to be a better, more human way to evaluate talent than a one size fits all process where the norm is failure - particularly when it seldom relates to actual skills needed on the job.

Whiteboard interviews

Sun, 05 Mar 2017 00:00:00 +0000

A few days ago, I saw a piece on David Heinemeier Hansson's tweet on whiteboard interviews:

Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.
— DHH (@dhh) February 21, 2017

I'm not a huge fan of the whiteboard interview but I think many of the tweets missed the point. Most of the whiteboard interviews I'm aware of involve algorithmic problem solving while the tweets, at least the ones I've seen all refer to things that indeed one would look up. Things like API calls - not things that whiteboard interviewers typically care about.

Tim Bray takes that point of view and shared his thoughts in a recent blog post.

The idea behind the whiteboard interview isn't all bad. The interviewer has an opportunity to see how the candidate thinks and works through a problem and in an ideal situation the interviewer is, at least to a point, coaching the candidate to help them through the process. It seems to me that the problem lies more in the types of questions asked and the skill of the interviewer rather than the idea that candidates work through a problem live.

I'd imagine that whiteboard interview success skew towards candidates who work well in isolation in a short period of time, have a good amount of exposure to these types of algorithmic problems. Also those who have practiced and trained specifically for the interview will have a huge edge. For people new to the process, it can be very stressful.

Once a candidate has accepted a position, they'll likely be working with a team, with additional resources, and with time to solve problems. This is a very different environment. The whiteboard interview, much like the SAT is thus something of an arbitrary gatekeeper that a candidate must prepare for and conquer rather than a skill that they must develop that will make them a more productive team member.

This whole process tends to advantage those with the time and background to prepare - this is one of the places where the argument that whiteboard interview hurt diversity come from.

I could be totally wrong but I seem to recall that the whiteboard interview, at least in terms of external visibility grew out of the legendary Google puzzle interview questions.

A tech giant like Google can interview however they like and they'll still get the talent. They go to the most selective institutions where candidates have already been culled for success. If they then interview 100 candidates and 10 of them would be good fits, as long as a couple thrive through the whiteboard interview process, they'll get their engineer. They'll miss out on a lot of great talent but they can cast such a large net they'll fill there seats with productive employees.

On the other hand, smaller companies will certainly miss out on great talent if they follow the same approach.

Is there a better way?

Some companies pre-assign mini projects and then discuss that at the interview. Pairing could also be a lower stress alternative to the technical interview. Another option would be to look at a candidates existing projects.

An interesting question is "why do so many companies use the whiteboard interview?" I can't say for certain but I wouldn't be surprised if it was a simple as "because Google does it."

For over 100 years, Stuyvesant high school required students study mechanical drawing (drafting). The relevance of the subject lessened over the decades and what was taught in many ways has become a joke. A typical class during the CAD parts of the class might be going over the cylinder command in CadKey. That's like spending a day studying the edit menu in Microsoft Word in an English class. If you can't tell, I'm not a fan. Drafting at Stuyvesant is the vestigial organ of the course of study.

My point isn't to bash drafting at Stuy but rather that there have been any number of schools that require their students take drafting even though it doesn't prepare students for, nor lead them to anything else in the schools curriculum (which now can be said for Stuy's drafting requirement). I've spoken to teachers and principals at these schools and we go back and forth as I press them for the reason for the requirement and ultimately, they tell me that their school requires drafting "because Stuyvesant does."

Why do so many small companies employ the whiteboard interview? Because the big kids do. The trouble is that the big kids can get away with it, the smaller players on the other hand, are hurting themselves. Even the bigger players would be well served to try to come up with an interview process that better assesses fit rather than a course filter that while it does pull in talent misses talent as well.