On the unreasonable reality of “junior” developer interviews | Hacker News Reader

On the unreasonable reality of “junior” developer interviews

samphippen.com

23 pointsingve13 comments

I've been through many, many tech interviews during my 25-year career, and not one of them has been objective. I have always been hired based on whatever opinion the interviewer formed about me within the first minute of meeting me. The rest of each interview has always been a drawn-out, cumbersome attempt for them to justify their initial, subjective decision.

In my experience and opinion, software engineers are some of the world's most incompetent buffoons at interviewing; myself included.

There has been times when we've made a subjective decision to hire someone based on a first minute impression, and later changed our minds due to the interviews when we found out the candidate was not nearly as technically competent has we had hoped for the position.

Based on what out of interest? A 3 hour coding challenge? Whiteboard excersice?

Asking for an example of good code the programmer had written previously and bringing it in and asking them to explain what they thought was good about it. Sometimes this can tell you the programmer is being too clever / not clever enough. E.g. when they override javascript prototype classes for the sake of succinctness, or going too far the other way when they repeat some boilerplate code excessively. You could ask them questions about why they did things that way, and see if they can provide a good reason, or they just didn't think deeply about the code they picked to show us.

I prefer this style of interview to the 'quiz' oriented style which revolve around the interviewers ego 90% of the time.

I too prefer this style of interviewing. I don't ask people to do whiteboard questions or solve puzzles anymore. I just ask for a portfolio of their work (like intelligent people in almost every other industry do).

How do you know this is what happened?

As somebody who just dealt with about a dozen rounds of these kinds of interviews as part of a job search, this post was extremely close to home. While I never got a question nearly that intractable, I did get a lot of questions that toed the line between "this is a useful algorithmic test" and "this is about minutiae and what you remember."

One thing I've found interesting was examining the various ways different companies handle the tech screening process. I've had everything from no real tech screen to back to back algorithm-based interviews. It's definitely possible to suss out what a company cares about from the sorts of questions they asked.

The biggest issue for me was that I never really was unable to get the right answer, but that wasn't always what the interviewers were looking for. I got told at least once that they expected me to simply be faster. I wasn't sure how to take that.

Looking back, all but one of the several companies from whom I received job offers had processes requiring coding-intensive tech screens that placed only minimal restrictions on the time one could take. The job I took was actually with the company that had the MOST intensive process (though that wasn't really a factor in my decision).

I don't think I'm incapable of doing the jobs at the algorithmic-questions companies who rejected me, any more than I think myself incapable of the job I was hired for. In fact, the work at each organization was quite similar. So, am I missing something, or are they, or both?

> So, am I missing something, or are they, or both?

They are.

Interviews, by definition, are not standardized tests. The more you think like they are standardized tests that should be done objectively, the more useless agony you're taking on yourself. It's never going to happen. It can't.

On the spectrum of human interactions, interviews are closer to a date, than they are to an exam. If you make a connection with your interviewer during that hour, (via whatever topic it is), they will go at lengths to hire you. Yes, you're expected to solve the given technical problem reasonably well, but beyond that, you have to leave it to "chance" and "pray" that you get a good panel.

That's how it SHOULD also work. Because YOU are also interviewing them at the same time. If you don't get inspired with the interviewers, you should also not join that company. i.e. you're also looking for a human connection.

I train for technical interviews for a living, at our exclusive bootcamp for interview prep: http://InterviewKickstart.com . Our entire theory is based on this premise i.e. that interviews are not a standardized exam; they cannot be gamed. All you can do is practice technical stuff really really well. In the end, who gets hired is not in your hands. And that's okay.

If you're going to ask a whiteboard question, solve it yourself (on paper, without references). If you can't solve it in a few minutes, it's probably not a good question. I do this with every whiteboard question I ask.

I ask these types of questions not because I really care if an interviewee can reverse a linked list or whatever, but to gauge their familiarity with the language. If their resume claims several large projects, and they claim to work with a language every day, but they struggle with the basic syntax, something is off. And that happens all the time.

maybe the most insightful recommendation w/r/t the developer interview process i've read (approx. 3/4 through the post):

"A technical discussion makes a much better place to start an interview. One isn’t under pressure to perform. Instead, one gets the opportunity to talk, correct previous mistakes, listen, react, and, generally learn about the person. Communication is the most important thing we do as developers. All computer problems are people problems. Let’s interview like that’s the case. One walks out of a technical discussion usually feeling pretty good. Interviewees like to spout reckons. Interviewers like to hear and react to those reckons. We get to work out if we can work together based on how reasonable our reactions are, whether we’re willing to give ground where we’re wrong, and, generally demonstrate how we like to work."

I like the fact that this writer ends up discussing how all interviews are really people interviews. Finding out in the interview whether or not a candidate can fit into the team is probably more valuable than finding out their level of technical skill.

Also, the blind focus on coding interviews forgets the hiring market. So what if a candidate fumbles in front of the whiteboard. When there are 10 jobs chasing every candidate, you would be better off hiring people who barely demonstrate the technical skill you need, but who fit in the team AND DEMONSTRATE A STRONG DESIRE TO WORK WITH YOU.

Employees who have a strong desire to succeed, will learn what is needed for your technical environment, and won't run away for a higher salary after 6 months.

People don't really consider the downsides of the whiteboard interview. They often fail miserably on the criteria of dialogue and end up being a candidate's monologue in a room full of silent observers. I've gone through such interviews in which only one of the observers ever spoke, and mostly just hints/reminders about the coding problem. At the end, I knew nothing about the company's technical environment or the way that the team worked. And they knew little to nothing about me and my technical skill.

People view whiteboard exercises as a proxy for getting to know the candidate, and in my opinion, this is far from reality.

I still see some value in a test about the same level of complexity as FizzBuzz, but only as an opener for an actual dialogue with the candidate about what they are capable of.

I think the fascination with whiteboard tests comes from the influx of CS types used to greenfield development into the flood of startup companies doing greenfield development, who were faced with a flood of candidates whose entire previous work experience was in brownfield development. In reality, most of those who failed at the whiteboard tests were competent developers who simply had no experience working with a blank slate Given an existing system, and a feature to be added or a problem to be fixed, they do just fine. And most greenfield companies get to the brownfield stage within months of starting up.

In fact, now the industry has become more of a brownfield industry than it was a few years ago and needs more people who can refactor legacy code, or at least cope with the mess.

I suspect that the mess would have been less if whiteboard interviews had not become so important because more startups would have hired brownfield developers who could have warned of how quickly technical debt can overwhelm you.

Common to see a startup go from startup to legacy big ball of mud in only two years.

Reply on news.ycombinator.com