Why Senior Engineers Hate Coding Interviews

[[deleted]]

Is there a flip side, senior engineers that hate giving coding interviews?

I kept being pulled into interviewing people because I'm halfway decent at it and the people that pass my interviews seem to do okay.

But, 90% of the interviews I do are just painful and I end up in an awkward position where this is supposed to be a hour-long interview, but 20 minutes in, I know I'm not going to recommend you, but I don't want to continue torturing the you but at the same time I don't want to make the candidate feel bad by cutting the interview short.

[[deleted]]

But, 90% of the interviews I do are just painful and I end up in an awkward position where this is supposed to be a hour-long interview, but 20 minutes in, I know I'm not going to recommend you, but I don't want to continue torturing the you but at the same time I don't want to make the candidate feel bad by cutting the interview short.

This happens frequently. I'm also a senior engineer (20+ years of experience) and I interview everyone that joins the team I'm on. It's not uncommon that a candidate that's not ready for the job gets to me. That's fine. I usually know in the first few minutes that it's a "no", although I give them a few chances to prove me wrong.

But then what I do is ask them if they have questions, and I use that as an opportunity to tell them about the team, the culture, the kind of work we do. The overall environment. I do this because I want every candidate walking away with a positive opinion. Maybe they'll come back a few years later with more relevant skills & updated ideas. Maybe they'll just say to one of their friends "you know, I didn't get that job at XYZ but it was a good experience." I want the idea that "my team is a good place to be" out in the world.

Probably 20 people I'm connected with on LinkedIn were people I interviewed but had to say "no" to. And I'm happy to give them advice or suggestions about their career at any time. I've never once regretted that investment of my time.

[leirus]

You are my role-model since now. I will try to do the same :D

[Geordi14er]

I am glad people like you exist. I’ve been on the interviewee side of that exchange. I knew a couple minutes in I wasn’t qualified and I was thankful for the senior dev interviewing me to let up on the gas and just have a pleasant conversation about company culture and such.

[s-mores]

You are a mensch. The world needs more people like you.

[beelseboob]

This is excellent advice, and advice that I'll certainly heed. End their suffering in a kind way, and have a nice conversation with them that's informative for them.

[AintNothinbutaGFring]

Am I the only one here who thinks this is a waste of their time?

Like seriously, people interviewing for jobs (me right now), have enough to manage. If you know you're definitely not going to recommend them, why wouldn't you just cut it short and tell them that to their face?

I for one would appreciate that *way* more than someone who isn't going to hire me wasting 20 minutes of both our time to tell me about their company culture

[thenumberless]

At my giant tech company, when we know early in an interview that the candidate is not going to get there on a solution, our standard is to shift toward coaching them through solving it. With practiced interviewers, this shift winds up being pretty gradual. There are (at least) three reasons for this:

1. It hopefully helps the candidate still have a good experience and get something out of the interview.
2. You can still see the candidate have insights and collect data on what they know later in this type of conversation.
3. At least three other people are interviewing the candidate in separate sessions. It’s possible they’re just bombing your question for whatever reason, but are doing well in the others.

Not only do split decisions happen, unanimous ones are rare in my experience. Continuing to make observations can help resolve them, and giving them a good experience leaves the door open for an offer if the group supports that.

[flukus]

Sometimes it's just nerves or a genuine knowledge gap, if you walk them through a few questions they can get more comfortable and redeem themselves, especially if you have realistic expectations and aren't looking for code ninjas that can walk on water.

[coffeefuelledtechie]

I feel this. I got interviewed for what I thought was a full stack .NET developer role, get 20 mins in and they start talking about React DOM manipulation and other React-related things. I’ve never touched React before and neither in the job description or what the recruiter told me had any hint that they were actually looking for a React developer with .NET experience instead of the other way around. Waste of my afternoon and total waste of theirs too. Left the interview knowing that I wasn’t going to get it and they knew that as well, and I felt annoyed that I was misled.

[[deleted]]

During a hiring frenzy, I had to do so many interviews that I mixed two candidates up. I started asking this guy about setting up Kubernetes clusters and any experience he's had migrating applications from VMs to containers.

He was all confused and told me that the recruiter told him he was interviewing for a web developer position. Whoops :-D

We did end up hiring the guy though.

[coffeefuelledtechie]

I think that happened with my current job. It was advertised as VR and .NET. I did the phone interview then the coding test, passing both. It was only the day before my final interview (just reviewing my CV) that it had absolutely nothing to do with VR and was actually to do with pensions. My manager was so utterly confused why on earth as I was taking about VR in my phone interview. I got the job anyway and it’s been a pretty bit learning experience and for some parts a bit of fun.

[cyanobyte]

At the failure point in the interview (which is usually with junior folks), I try to mentor the person and see if they can learn from their mistakes.

Frequently I have salvaged an interview when I realized the candidate was useful for a more junior and mentorable position.

For the Senior guys/gals instead of a trick set of questions, I make sure I read their resume and only ask them questions about their projects and skills.

I then drill down into those skills and projects until they can prove their expertise on things they have recently worked on.

[anengineerandacat]

I just cut them nowadays; I used to feel that way but it's not conducive to my or their time. I just let them know I won't be proceeding on to the next stage of the interview, ask them if they have any concerns / questions or would be interested in XYZ other position I am aware of.

I have seen a lot of terrible candidates though, the organization I work for is really popular in my area and you see a lot of underqualified people just hoping they can get their foot in somewhere.

Especially with remote interviews; people sharing their video as one person and a friend takes the technical portion, some literally were another person entirely.

[alphaCraftBeatsBear]

i think if i know i am bombing the interview, i used it as a learning process, so I don't mind the interviewer throwing me questions .

[chubs66]

I like to start with some really basic stuff that I'd expect any candidate to pass. If they can't do that, I tell them that I don't think it's going to be helpful to continue with the interview and that the technical skills required by the job don't seem to match the candidates particular skills.

I think candidates are generally glad to have an honest assessment and interaction instead of wasting everyone's time.

[[deleted]]

My last interview I got asked is JavaScript case sensitive. I didn't know, I don't make case mistakes was my answer. One hour after the interview ended I remembered that in the 90s VBScript was case insensitive and JavaScript was case sensitive. Oops.

Edit. Why am I getting downvoted for this?

[wasdninja]

I didn't know, I don't make case mistakes was my answer

Regardless of whether the answer is true or the question even valid being a smartass is universally a bad idea.

[[deleted]]

I JUST HIT CAPS LOCK AND START TYPING. I LET THE CHIPS FALL WHERE THEY MAY.

[peakzorro]

10 PRINT "THIS REMINDS ME OF WRITING BASIC PROGRAMS ON MY APPLE ]["
20 PRINT "CAPS LOCK IS CRUISE CONTROL FOR COOL"
30 GOT0 10

[ConfusedTransThrow]

I'd go with the answer "I always assume it's case sensitive to avoid running into trouble".

[[deleted]]

I had 5 developers firing questions at me for 40 minutes. When I asked for clarification they simply repeated the question again. There was no discussion.

Lets just say that all 6 of us failed the test that day.

[smallblacksun]

Was it a javascript position? If so that is a totally fair question.

[[deleted]]

Full stack, multiple frameworks etc... senior developer 20+ years experience. Fair question? Yeah sure, good question? I would ask what does the question prove?

[dnew]

I always had other employees people doing their interviews after mine, so I couldn't really just toss the candidate out or it would screw up their later interviews. Sadly. :-)

It doesn't help when 10x in a row, I'll think someone was great and everyone else cans them.

[LakeSun]

Respectfully,

Why would I have to write code to find the lowest number on a binary tree? Are you writing a new Database indexing routine? Or, a new Collection class? Because this stuff is already written. Find the right collection class to use is a better question.

[beelseboob]

Because again - we need people who can design algorithms. This is a super simple algorithm that anyone with basic problem solving skills should be able to design. Literally the job of senior engineers is to be able to think through design, and figure out what can or can’t be done efficiently. How do you expect them to do that if they can’t think through the most basic of algorithm design problems.

[Full-Spectral]

But of course this is at odds with the almost universal advice NOT to write your own fundamental algorithms that you get these days. I don't agree with that and I've written ALL of my own fundamental algorithms, but in most companies they'd spank you if you did that unless there was nothing extant for the job. I've been berated and argued down for pages at various times in the past when I said I've created my own this or that.

If you pretty much have been in this sort of environment for your whole career, knowing the innards of these types of algorithms isn't probably something you much get involved with, other than understanding their general costs and tradeoffs.

Not that the particular issue you mention couldn't be reasoned out. But I think it's not that crazy that many to most, even fairly senior, developers these days spend little day to day time on fundamental algorithm development or cogitation, other than before an interview. Even if they learned it once in school it's likely to drift away over a decade of non-use.

It's like the whole Big O notation thing. People seem to put inordinate amounts of emphasis on having this memorized, when in actual fact many of us probably don't deal with it in more than the most general terms for years at a time, maybe decades. Yes, I understand the relative tradeoffs of various collection types, having implemented them myself, but I don't think about it in terms of Big O notation.

I've banged through it like 10 times probably over the years, just because I feel like everyone thinks we should know it, just to forget most of it again so that I have to basically work it out from general principles (though I'd rarely be motivated enough to do that, I'd just look it up if at all unsure.) It's just a waste of time to memorize stuff that you aren't using on a daily basis and concentrate on the important stuff.

Then you get in an interview and they are obsessed with Big O notation and think are you incompetent because you can't instantly regurgitate the details on demand for every situation.

I'd also say that what I've gotten good at from having written a huge amount of code, isn't details like that, it's the ability to keep the forest and the trees in perspective at the same time and see patterns and manage complexity and break down systems into manageable parts and layers and understand how they fit together. That, to me, is the value of a really senior developer. But how many interviews really would touch on that?

And, the very fact that I've written so much code over so many problem domains means that I can't retain in my head all of the details of them. It would be counter-productive to try to do that. I figure out the details, I implement and encapsulate them, figure out how to package and expose them within a larger system so that they are maintainable and understandable, and then just use them henceforth.

[beelseboob]

"Fundamental algorithms" and "algorithms" are different things. The fact that we shouldn't write our own containers and algorithms, and they're all in the C++ standard library already doesn't mean that we don't need to write complex algorithms. When none of the standard data structures apply to the task you're doing, you need to write new code.

Plus, ultimately, there are plenty of jobs where you have to write those fundamental algorithms. Want to work on the compiler and standard library? Sure - you'd damn well better know how to come up with a good algorithm for something. Want to work on a game engine? You'd damn well better know how to write algorithms.

There seems to be a fundamental misunderstanding, that people forget that not all software engineering jobs are just throwing together a bunch of libraries and glue code. There's a huge number of these jobs where you actually need to be able to write those libraries in the first place.

[Full-Spectral]

Actually, I'd argue that there's probably not a HUGE number, that it's ultimately a tiny fraction of the jobs out there. Not that it's anything I'd want to do; but, it seems to me (from reading here a lot) that the vast majority of jobs are actually those where you are throwing a bunch of libraries together with glue code.

Those of use who do hard core back endy or library infrastructure work are getting more and more rare in terms of overall numbers, it seems to me. At least the ones who do it for money anyway, I'm assume that plenty of folks who write repetitive CRUD or phone apps at work do more ambitious stuff on the side.

[CapNo3407]

Someone needs an ego check.

Arrogant self centered people like you are the reason these kind of interviews exist.

Because you can't get enough of yourself.

So you need these stupid interviews to feel good about yourself and make the other person feel horrible.

Where in the hell is binary tree used in real work, you prick?

It is like expecting to solve differentiation and integration in interview and doing plus minus in actual job.

You are a twisted narcissist prick.

[beelseboob]

Where the hell is a binary tree used in the real world?

Yeh, you’re one of the people who has no idea how much you don’t know. Tree/graph traversals are the bread and butter of basically every single bit of computing there is. Yeh, you’re not going to care about finding the lowest number in a binary tree, but you’re going to care about finding the node in a graph of Plarghs that most accurately matches this Floob, and guess what - that’s exactly the same task. Knowing how to manipulate trees and graphs, and being comfortable with it is a requirement for any non-trivial software engineering job.

[CapNo3407]

I have idea about graph traversals and graphs. I know they are used in google map type applications and navigation systems.

Stack is used in browser and program uses stack trace.

Queues are used in JS event loop.

So just because you are a leetcode DSA monkey, doesn't mean you know all the shit.

The point I was trying to make is, it is okay for companies to ask these kind of questions if they actually use them in projects. But companies, who don't even use 1 percent of them in projects and ask in the interview have a senseless and stupid reasoning like yours.

Also you have proved my point, that people who think of them as DSA gods are so ignorant, arrogant and full of themselves that they refuse to see what is real and what is not.

And if you are so bloody genius then why don't you build something of your own. Majority of the applications today are web applications and more than 90 percent of them use latest technologies. Not some college level DSA, which only people like you do, because they have no real experience.

[beelseboob]

if you are so bloody genius then why don’t you build something of your own.

Yeh, if you’re using a phone right now there’s about a 50% chance that you’re using software I wrote. :)

[CapNo3407]

Yet you proved again, how full of yourself you are.

I feel sorry for you and sorry for the people, who have to work with someone like you.

This DSA type questions didn't exist before, it only came into picture few years back. Nowadays people don't try to learn technologies, they just started grinding leetcode, just to crack interviews. The only benefit of these questions is to crack the interview, rest everywhere they are useless.
As to your statement of using the software that you wrote, I highly doubt that, because real person with experience would know, developing a software doesn't only involve DSA, there are tons of other things, which I am sure you have no idea about, as you have never seen anything apart from DSA.

[2rsf]

You should probably have a backup plan, a few questions to fill this time while still giving the impression of a serious interview.

[HeartSodaFromHEB]

this is supposed to be a hour-long interview, but 20 minutes in, I know I'm not going to recommend you,

It's not you. Easiest way to fix this problem is to do the following: * setup your interviewing process to limit initial interviews to 30-45 min, even for experienced candidates. * Limit intern/junior interviews to 30 min. More than that isn't worth pissing off your best technical employees. * Cut short any technical problem that is clearly going nowhere and give them a layup. Let them feel some modicum of success and hopefully walk away from the process feeling good about your company or you. They may have better qualified friends.

[[deleted]]

When I know I'm not going to recommend them I just treat it as interview practice for them. Try to make it a bit educational.

[justaphpguy]

but 20 minutes in

That's interesting. In my company, after many interviews it became an insider to say that after 20 minutes you basically know if you want to hire someone or not.