Why Senior Engineers Hate Coding Interviews | Hacker News Reader

Why Senior Engineers Hate Coding Interviews

medium.com

36 pointsvvern61 comments

Everyone wants to talk about the bad hire that can’t “program their way out of a paper bag but I want to talk about another kind of animal. The one who seems to know what their doing on all the coding tests. You hire him thinking he’s great. Gets right to work , cranks out a ton of code, is working weekends etc. Then you look at the code and it’s a crap ton of idiomatic garbage, seemingly clever hacks, etc. The rest of the teams productivity goes to shit because no one can understand Glen’s weird code.

I worked with a guy who spent weeks writing a CSV parser. Firstly there are a ton of libraries to choose from. Secondly while CSV is simple it can be surprisingly difficult to handle all possible options. When we got a look at his code it was filled with really odd usage of reflections and dynamic code generation. This was supposed to process huge files so performance was supposed to be a priority.

Or the other guy who complained daily about maven then one day he comes in on Monday right before a major deadline with a big shit eating grin on his face and when someone finally asked what he was grinning about he said he spent the weekend replacing maven with ant.

I’ll take someone who can’t program their way out of a paper bag over one of these guys any day. At least when they’re in the paper bag they can’t destroy anything.

Do you not have coding style guidelines and code reviews? Unlike incompetence this behavior can be corrected easily.

We've had a case like that in one of previous jobs. It was not very bad. The key is correct procedure.

We've had required code reviews for every bit of code written. Those are always harder for the new people, but exactly how hard depends on the person. I have seen PR reviews which require major things like "let's refactor those changes into separate class with proper interfaces". And the good old "this code is too hard to understand, let's simplify"

As for CSV story -- if you new people can go off for weeks and work on new project without talking to anyone, there is something wrong with your org. You want to have status meetings periodically (weekly? every sprint?) where everyone talks what they are working on, and what difficulties are they facing. Those are really great -- they let the team feel together, they let people whom to ask for help, and they may help discover hidden talents.

And we did have people who would spend time doing integration with their favorite IDE's build system. It is not quite "maven vs ant" -- but if this helps them be more productive, why not! Of course this would be still optional, so other people would not have to use this, and it is up to them to maintain the integration.

Anyone who says coding interviews don't work has never made the mistake of hiring someone who can't code. I've done it before -- someone who looks great on paper, interviews well but can't code their way out of a paper bag. I have no clue how or why they are in this industry, but I will never again let someone off the hook without demonstrating that they can code.

I don't want to hire people who think coding is beneath them or are so far removed from the actual tech that they can't code anymore.

Sure, yet how most interviews are done is bonkers.

I don't mind simple fizz-bang coding interviews. But some of the ones I've been to, for internal positions no less, have been absurd ambushes.

I once had an interview for a front-end midlevel position. I had some prior front-end experience in another framework, but mostly worked on midteir and vendor products. I was notified the morning of my interview that it wasn't just a regular interview but a code screen and I could use any language/tools/etc that I wanted. I got there and found out that was not the case - he was not following HR's procedures. So he hands me a Mac (which I'm not familiar with), tells me to use Angular (which I've never used), in Webstorm (I played around with it once), and tells me to build a page to upload a CSV file and display the contents in a table on the page. I have 30 minutes to do it, and then I'll get 30 minutes to dress it up in CSS. Needless to say, I bombed it. I was sort of impressed with myself that I had it almost functional, but yet ashamed at my abysmal evaluation. He said I didn't do well and that he was looking for an expert. Shouldn't you open a senior posting if you want an expert? I asked him why he gave me an interview if my resume listed none of the technologies, with my cover letter stating that I was looking for a change and wanted to learn new technologies. His answer was that maybe I knew the tech from personal projects. I had Android personal projects listed on my resume, so why would I have left off other ones more pertainate to the position? My guess is he was too lazy to read and understand the resume and cover letter, not to mention ignoring HR's instructions. What a waste of both our time (moreso mine since he was on his laptop most of the time).

That sounds like an absolutely terrible experience. I think you dodged a bullet! :)

When you say "someone who can't code", what exactly do you mean by that? Does it mean that they have no idea what a for-loop is? Or that they have basic understanding of a programming language, but lack the fundamentals? And how do you define fundamentals?

The phrases "can't code" and can't pass "fizz-buzz" are loosely used. What exactly is fizz-buzz? To me, it's writing a for loop to reverse a string, but to someone else, it's implementing Dijkstra's algorithm in a 40 minute period to solve some made up problem.

I've interviewed people who had ostensibly been working for years as a professional software developer be unable to even define a function that would accept a string as an argument, do _literally anything_ to it, and then return it. People who couldn't even write a syntactically valid function definition of any sort, during the entirety of an hour long interview, when given the choice to use any language they wanted.

A few years back I was working at a company that had a policy that they didn't have recruiters do any pre-screening of candidates who had prior development experience listed on their resumes. I was a frequent stage 1 interviewer for our team, and we gave the candidate an hour to write a function to count the occurrence of words in a string (e.g. "the old man and the sea" -> {"the":2, "old": 1, "man": 1, and" 1, "sea": 1}. Candidates were allowed to select any language they wanted, use their own editor/environment or use a cloud based IDE if they preferred. They were allowed to search any API documentation they wanted, to use any libraries, and were explicitly told to not worry about any edge cases like punctuation, capitalization, etc.

I'd guess about 1/2 of the candidates I interviewed were able to complete the assignment in the provided time, with about 1/4 of them finishing it almost immediately, and another 1/4 unable to even write a single syntactically valid statement or line of code. Some candidates claiming years of experience with a language couldn't even write something that looked at all like the syntax of the language.

Fizz-buzz is a well-defined specific task. It's not a stand-in for a generic easy question.

https://en.wikipedia.org/wiki/Fizz_buzz

Can’t you just review their code samples?

The organization of their code tells way more about their skills, than some stupid L33T coding problem that they must solve in 5 minutes.

This would definitely give you more and better information — if you could know that the samples were definitively from the candidate.

I’ve interviewed candidates who were clearly not the person on the phone screen, for example.

You're optimizing for the wrong thing there.

Given 10 positions you need to fill anticipating these hires will stick around for 3-5 years each.

Pick one:

- [ ] 10 "less experienced" developers for 3-5 years

- [ ] 9 "very experienced" developers for 3-5 years + 1 "no experience" developer for a few months which you'll then have a 90% chance of replacing with a "very experienced" developer

Bad hires are a fact of life. It's unavoidable. Hiring is a crapshot. Just like romantic relationships. Would you say, "I had a bad relationship once, so I'm going to grill every date to make sure something isn't seriously wrong with them"? With that attitude, you'll never have a relationship again.

Interviewing is a two-way street. Especially with senior engineers. You're trying to convince the candidate to work with you. After all, they could say no, and walk away. Moreover, nobody wants to work for an incompetent boss, and we know there are a ton of incompetent bosses out there. What if I, the job candidate, want to give you, the interviewer, a test to make sure you know what you're doing? Don't worry, I can give you a take-home test to do in your "spare time". ;-)

I don't think companies realize how many potential senior candidates they drive away with audition-style interviews. I've religiously avoided them, just never applying to companies who do them. I'll walk away if I don't like the hiring process.

> What if I, the job candidate, want to give you, the interviewer, a test ..

As an interviewer, we always allow for that! Our standard procedure is to leave last 10-15 minutes for "questions for the interviewer".

People usually ask things like "which stack do you use" and "how many hours per day you work", but once I had candidate ask me programming question, related to the one I just asked them. We've had a nice conversation about algorithms and runtime performance.

Did these people also have github accounts or example code they've written before?

All excellent points, happily ignored by every large company.

Every time I come for an interview, I ask: did you check out my github? Only once in a while somebody responds with a yes. I mean, it's not a big deal - I just have a bunch of weekend projects there, nothing really outstanding, but it might give more information than any 15 minute coding quiz can give you.

And, always the whiteboard coding... madness!

Thing is, going through the github repository requires time, the whiteboard exercise they can pick anyone that happens to be idle just 5 minutes before the candidate arrives, just in time to print out the cv and being dragged into the interview room.

That's it. They are not really interested in getting the best (or competent) talent, they just need to follow a ritual.

I mean, it's all explained better in the article, but focusing on competence: if they don't measure the competence [of a senior software engineer] they will not hire a competent engineer. And I've seen plenty of senior engineers who can produce reams and reams of awful, unmaintaineable, and buggy code.

And, I am sure, they all aced the whiteboarding.

I wrote a "find the bugs" test that did a great job of selecting good senior engineers. No coding, just point out the mistakes in a series of short code snippets. Some bugs were simple and some were obscure corner cases.

I think these types of tests are pretty good, especially if there's a healthy mix of objective bugs and subjective warts. Not only does it easily allow the candidate to show what they know, it also opens the door for some discussion on the subjective parts.

Seems like a much better test style to me. You could come prepared with cases from multiple languages and frameworks even.

This is a great exercise because code reviews are such a important part of the job.

The ones I truly hated were presented in some weird online not-a-real-text-editor format (unrealistic environment), and were also TIMED (unforgivable).

I mean, I’m not sure what you’re assessing if you throw 4 different problems at me to complete in an hour using an editor I’ve never seen before (that may have bugs of its own).

“Homework assignments” seem OK to me though; feel free to give me a few days in my environment of choice to produce quality work. Anything less is not a good benchmark.

I general agree that timed coding is not good. I had a similar experience. I don't know that take-home stuff is good either. It can allow some individuals to cheat.

Why is this downvoted?

I would say take homes are good, but not by themselves. Instead of spending an hour in front of the applicant trying to solve a problem, let them take the challenge home, and spend 15 minutes afterwards letting them explain their solutions. You'll fish out cheaters by questioning their work.

If your job is not either my only hope or my dream job, no, I'm not doing homework assignments that take a few days. I'm probably chasing several different places. 3 days homework times 10 places equals something that I do not have time in my life for. Nor am I going to make time for it to try to get into your company. You aren't that much better than anywhere else, so don't make it harder for me to get a job at your place.

I'll just throw out there that one reason I think coding interviews have some sort of value is because there are very few metrics to distinguish good engineers vs bad engineers when it comes to software engineering apart from working with them.

For example someone was the lead Senior Engineer for 10 years at their previous company. Their biggest project was a rewrite and migration of the invoice handling system to optimize for data analysis leading the millions more in revenue.

Based on this description I have no idea if this person

a) Went to hundreds of meetings around priority, resources and timelines while other engineers did the actual work. While he went to the big wig meetings as the technical resources because he was trying to make optimal "architecture decisions" not because of talent but because his role as lead was built on having been with the company 10 years he knew how to navigate the internal politics as well as being an SME in the companies specific systems.

B) He was making major architectural decisions, leading the engineering team, mentoring other engineers, helping ensure best practices and trying to find time to squeeze coding in while trying to prevent the PMs and Execs from making the wrong decisions and getting the wrong ideas.

The problem is these pieces of information can be hard to distinguish between based on the information that most people have access to during the hiring process.

Now the looking at the github can be useful but if you are applying at a large organization a lot of the rules and processes are controlled not by the hiring manager but by HR who is trying to avoid anything that could lead to a lawsuit, so hiring managers have to try and navigate this field in a sub-optimal way.

Software engineers should be entitled to keep a copy of their code.

This code can be presented to interviewers for subsequent positions.

Interviewers can be allowed to review a hardcopy during the course of the interview, but can't keep it.

If the hiring company wants to use the code, a license must be obtained from the employer who has copyright.

The tricky part of this approach is that many companies treat all of their software as a trade secret. These types of companies would likely object on these grounds. For code that isn't part of a trade secret, it's not a bad idea.

Agree that the system is broken.

Not to defend the current interview system, but what other scalable solution do we have other than LeetCode type of questions? How would we be able to show that someone knows how to write code without testing them on the fundamentals of CS?

Genuinely curious.

It's not just testing fundamentals, it's testing who spent the most time on interview prep. Companies increase the difficulty level as more people do prep. That's become a cycle that favors those who have the most spare time. Senior engineers often have houses, kids and aging parents to take care of.

That doesn’t excuse hem forgetting what a priority queue is and when it’s appropriate to use one. The good senior engineers I know have a strong grasp of the fundamentals

So you're saying LeetCode is only for screening seniors? What about entry level?

Where did I say that? Senior should have both fundamental coding and also more broad system design interviews.

You're hiring the candidate who happened to use one somewhat recently. The same candidate has completely forgotten other concepts and would have looked like a fool if questioned.

That’s why people do more than 1 interview. My example was just an example, I probably should have qualified it.

Requiring to implement a priority queue is harsh and no one should do this at the interviews.

Asking "what is a priority queue" is a totally fair question (if your job may reasonably require it), because knowledge that such things exist is a big part of being a senior person. You don't have to be able to know the class name, or exact notation, but you should be able to know what to Google for.

A person who does now know what a priority queue is will happily write O(n^2) algorithm which repeatedly calls max() and completely kill your app performance. There would be no opportunity to Google anything, because only senior people get business requirements, not names of algorithms they need to use.

If your company refuses to hire anyone where this statement is false, that doesn’t tell you much.

LeetCode is not fundamentals.

Leetcode requires you to know all the common algorithms and data structures. Every software engineer should know these

LOL. The data structures I can see, but what algorithms are considered standard will vary from domain to domain. A good engineer can look these up. I dare you to find an engineer that knows ALL of the LeetCode perfectly on the first try.

I don’t get the “LOL” from you but ok. Anyway, the fundamentals are in textbooks for a reason, they aren’t domain specific. To answer your other question, I could definitely solve most leetcode and so could my colleagues. Maybe not perfectly optimally first try for all but who cares about that.

"Maybe not perfectly optimally first try for all but who cares about that."

That's the purpose of LeetCode. If you're saying you can't solve all of them, what happens when you get one of the ones you don't know?

Then you keep interviewing until you get the ones you know. There's luck involved with everything. Luck in the sense of the right time at the right place.

This is a very unserious reply.

This is a very unserious reply. You have a bad habit of misconstruing my words into a straw man

Perhaps you're not using the correct words.

Sorry. Yeah, I probably misread wha you wrote or read some other comment. Anyway, to answer your earlier question, good interviews are a conversation and allow you to demonstrate your knowledge and problem solving abilities. It’s ok to start with a suboptimal solution to a problem and iterate. If you already know the perfect solution to one problem then a good interview will move on to another problem so it’s not that useful.

A lot of down votes, but I have yet to see a response to the valid question of "what other scalable solution do we".

Don't attack the person. Attack the argument.

> what other scalable solution do we have other than LeetCode type of questions?

This question is based on a flawed assumption that interviews need to be "scalable".

If you're interviewing more than 3 or 4 candidates for a senior position, you're probably doing almost everything wrong, starting with your method of finding candidates. (Job postings are almost universally terrible. Why is everyone so bad at it? I don't want to hear excuses like "HR". If hiring engineers is crucial for the company, then you need to fight HR.) You may need to interview only 1 or 2.

Don't "screen" a bunch of people. That's a giant waste of everyone's time, both employers and candidates. Start at the top of your list, and only interview your top candidates. Spend the time to research those few individuals — even before you interview them — instead of spreading out your time relatively equally on a large number of candidates.

This will just interview people with the best resumes and will be biased.

Yes, that's the point. If you're hiring a senior engineer, you want to be biased toward the people with the best resumes. Insanely, the current system is actually biased against them and in favor of freshly minted comp sci graduates.

You'll probably be biased in worse ways too. That was my point.

This is a strange point. The empirical results from audition-style interviews have been in for many years, and the results are indisputable. Software engineering is extremely lacking in diversity. So maybe try something else for a change? Not sure how it could possibly be worse than what has already been demonstrated over and over again to be absolutely awful.

My suggestion isn't particularly novel. It's often how hiring works in other industries that aren't as insane as tech. Software engineers have their own special snowflake hiring process that they hold onto almost like a cult. They rhetorically ask "What's the alternative?" without actually empirically looking at the rest of the world outside of software engineering. The fact that "FizzBuzz" and "LeetCode" are words everyone recognizes just shows how much of a cargo cult software engineering has become.

You give a very simple question, generous time frame (like a 40 minute slot for a 5-minute question), and prepare set of discussions / more complex scenarios. Also don't require compileable code -- getting all the syntax errors out is boring and stressful. Do the thing on the piece of paper, whiteboard, or online editor without compilation functionality. Tell them you don't care about exact function names or typos.

If the interviewee does not work well under pressure, they'll have 30 minutes to do the question. Hopefully they'll worry less during the interview, and perform better.

If the interviewee breezes through your question, you give them next, more complex variation ("and now you cannot assume X anymore"). Make sure you have a few of those.

Basically, don't be a computer. Your goal, as an interviewer, is to get the candidate to show off their skills. Putting extra pressure does not help with it.

(and yes, this is pretty scalable. we are still having a single meeting for each candidate)

Recently I've been interviewing a bunch of programmers and most of them exhibited one pattern - while their code was good, when it came to edit it, in a f2f interview, they simply couldn't do it. They had access to googling the answer, they could ask questions and I tried to give hints to the answer. It's as if they didn't write it - it was most bizarre. So, no, will stick to the interviews as well.

Wow that's crazy. I wouldn't mind being given interview like that. It's the hard math quiz whiteboards I'm petrified of. Not being able to access my notes is like telling me run shell commands on a cli program you've never used and you can't use --help or -man

Yeah, that's unrealistic - in the real world you have access to the internet, to your notes, to other people. As long as you can apply that knowledge, as long as you can show that "ok, here I want to use XYZ because of ABC", I think that's what matters.

Perhaps you've hit a run of people submitting dodgy or bogus work?

One of the other commenters mentioned people doing phone screens who were clearly not the people in a f2f interview.

So maybe it's something along those lines? eg: people who've not really written the code, then being asked to edit it... and boom, they're screwed.

If you're having a run of people doing that though, it sounds like something about the way you're finding candidates needs adjusting. Maybe try through a different avenue?

Reply on news.ycombinator.com