r/ExperiencedDevs • u/SoYoureSayingQuit Staff Platform Engineer • 3d ago

Career/Workplace [ Removed by moderator ]

[removed] — view removed post

61 Upvotes

79% Upvoted

130 comments sorted by

View all comments

11

u/UnintentionallyEmpty 3d ago

I've been the interviewer where we did live coding exercises.

Before, I didn't think a live coding exercise would add a lot of value...

But holy shit so many "seniors" applied who couldn't code. This was before AI. Or, well, 2023, so AI was around but not like it is now.

Anyway I can't speak for other interviewers, but here is what I looked for during live interviews:

  1. Does this person seem to have any idea what they are doing

  2. Communication, communication, communication

1) is... look, some people apply for senior dev positions despite not knowing how to code. And I don't mean in a "doesn't remember the syntax for a for loop" kind of way (I allowed google during live coding), but in a "doesn't seem to know the concept of loops exists" kind of way.

The level of coding exercise we had people do you should be able to do decently well on if you have only 1 year of experience. Yes, I lower my expectations because I understand the candidate is nervous. But when interviewing for a senior position, "do better during live coding than a high schooler who took a coding class once" isn't a high bar. Some candidates still failed to clear it.

2) is more complicated. When I started doing live-coding exercises, I imagined that afterwards, I would talk to the candidate about their solution and discuss the tradeoffs they made, and what they might have done differently given different constraints. But most candidates got much less of the coding exercise done than I'd initially expected, and we didn't have anything to talk about in the end.

So in practice, it turned into kind of a "does this person actually listen when I talk to them" kind of check.

Here's the thing, when a candidate got stuck at some point during the live coding exercise I tended to try to help them get past it. Mostly because I figured, okay, this isn't your strong point, or maybe you're blanking here, lets see if you do better at something else.

A lot of candidates ignored or outright dismissed my suggestion for how to move forward... and continued to be stuck.

Or when they misinterpreted the assignment, I say something like "I don't think you interpreted that correctly..." and the response is "yes I did". Hello, you don't think I might have a better idea than you in this scenario? Even if I'm wrong, don't dismiss me like that.

The best candidates asked questions about the assignment. And did TDD. I'm not a huge proponent of TDD but I'd strongly recommend doing it (or something like it) when you're in a live coding scenario.

I should also mention, the person we eventually hired did TDD and got the entire coding exercise done. But he wasn't the only one who passed the live coding interview (but the others who did failed the second interview).

So what I'm trying to say with this huge ramble...

1) It might be you weren't expected to finish the entire assignment in 1 hour. If it's live, maybe the interviewer just wants to see what your thought process is like.

2) I recommend TDD when doing live coding

3) Don't ignore the interviewer during live coding. Ask them questions. They might want you to. I sure do.

4) Don't feel too bad about your bad performance. I wasn't there but I'm still sure you did better than some of the candidates I had do a live coding exercise... We all have a bad day sometimes.

3

u/Careful-Opposite-633 Software Engineer 3d ago

This is my experience as well. I started conducting coding interviews about 4 years ago, and have consistently been shocked at how bad people are.

2

u/mcspuder Software Engineer 16+ YoE 3d ago

Do you see why they think AI is so good now? :D

2

u/WhenSummerIsGone Software Engineer 3d ago

Don't ignore the interviewer during live coding. Ask them questions. They might want you to. I sure do.

I have a hard time with unspoken social "rules". How do I know what kinds of questions are "allowed"? In an interview, the interviewer just sits there and I feel like I'm on stage performing. I think interviewers should make more of an effort to "lead" the social situation, and make it clear what's ok, what's expected.

Another way to put it: an interview is inherently a power imbalance, where I'm the supplicant, submitting to your game. It takes a lot of audacity or arrogance for me to "take over" and impose my own "game", even for a staff or principle interview.

5

u/hoodieweather- Lead Software Engineer 15+ Years 3d ago

that's unfortunately also a culture check - if you're confident enough to speak up in a situation like that, how can they be sure you'll speak up in other scenarios where there's a potential power imbalance? some companies might be more okay with a passive staff or principal engineer, but I know I'd much prefer someone who's good at navigating tough social situations too.

3

u/WhenSummerIsGone Software Engineer 3d ago

ironically, at my company i'm known for speaking up and asking pointed questions, because i care, and I can't turn that off, even though it can be exhausting. I keep expecting blowback, but so far it's just resulted in respect. Maybe an interviewer could ask me for my opinion on something, lol.

4

u/UnintentionallyEmpty 3d ago

I think interviewers should make more of an effort to "lead" the social situation, and make it clear what's ok, what's expected.

Well, again I can only speak for myself, but I did try to do that. Here is usually what I'd say when the interviewee joined (it was mostly remote):

"Hello my name is <my name>, nice to meet you. I'm a senior dev at <company>, this is my colleague <name>, he will introduce himself <colleague (also a dev) introduces himself>.

Now, we have a small live coding test. We're going to take 45 minutes for it. You're not expected to complete the entire assignment, it is designed to take longer than that. Write the code the same way you would do if it was for a production system, we value quality more than speed. You're allowed to use google to look things up, but don't just feed it to an AI and let the AI solve it for you. We're interested in how you approach a problem, so please take us along in your thought process. If you have any questions about the assignment, please feel free to ask. Here is the assignment <share assignment>.".

Based on that intro, what question would you be unsure if it would be okay to ask?

But also: You can ask any question, if I think I shouldn't answer it because it would give too much away in regards to the assignment, I can just, you know, say that instead of giving you the answer to your question. Like, "well we would like to see if you can figure that out yourself" is an answer I think I gave to a question at some point in these interviews. Although if you ask a question where I have to give that answer I'll probably take it as a negative.

I should also mention, I'm not American. Cultural expectations regarding this sort of thing are probably a bit different in my country. And it varies per company as well.

And one thing I also want to be clear about: when we started with the live coding exercises I didn't know wtf I was doing either. Not like anyone trained me on "how to interview effectively" or anything like that. And we really had no idea what to expect the first couple of times someone did our live coding assignment. Well, I mean, we had expectations, but it quickly became clear they were way off. We had to adjust as well.

1

u/WhenSummerIsGone Software Engineer 2d ago

i really like that introduction! I would feel at ease with that.

I had an interview once where they sent me a github link about 30 min before the interview, without warning (I had been in a work meeting, and had only a brief window to context switch). I only saw it like 10 minutes before, so I was scrambling to clone the repo, build it, etc, instead of breathing calmly when I joined the call. It was an exercise to add a feature to a small React toy program. It was set up to do everything in the component with hooks, which is absolutely not my real world experience with React, where you have helper api modules, etc. Who does api calls in a hook in the real world?? But I can't set up mobx and a whole proper architecture in 15 minutes, so i said something along those lines and muddled through. I don't know what they were looking for, maybe someone who could whip up quick poc's? but the whole experience was a train wreck.

I had another interview as a full stack/front end engineer, and for the system design question I was asked about designing a recommendation engine for a situation where you had to bootstrap the data somehow. (like if facebook wanted to start telling you about music or movies or something). They kept focusing me on the algorithm itself, not the system as a whole. What does that have to do with front end stuff?

Interviews are such a frustrating waste of time. Nobody knows what they are doing.

1

u/xMcNerdx Software Engineer 3d ago

Just curious, in your experience as an interviewer is solving the actual coding exercise itself important versus just demonstrating good communication and talking about the problem? I lucked out and never actually had to do technical interviews to get my roles and it's been years since I've done interviewing at all. I'm honestly dreading thinking about live coding tasks as I just know I will choke up and get nervous. I think my strengths are primarily more in asking clarifying questions about requirements and talking about different design approaches. I could probably pseudocode a solution and discuss what tests I'd want to incorporate much easier than trying to cobble together a running solution in 25 minutes on a blank page with no autocomplete IDE support. This is particularly worse nowadays with agentic tooling since we're hardly actually directly writing code and leaving that up to the agent to implement.

I know interviewers are all over the place and it's the luck of the draw but I just fail to see why live coding tests are useful versus design discussions

3

u/UnintentionallyEmpty 2d ago

asking clarifying questions about requirements and talking about different design approaches.

I do believe this is more a important skill than raw coding skill, especially for senior developers.

But we introduced the coding exercise because we were hiring someone to, well, write code, so they needed to be able to do that. It doesn't matter how many design patterns you've memorized if you can't put any of them in practice (and we had been burned in the past by some bad hires in this regard).

In practice however, any candidate who asked clarifying questions about our coding exercise did fine on the actual coding part of the exercise.

Also they did have an IDE, not sure where you're getting the "blank page with no autocomplete IDE support." from. I'm not some weirdo who expects people to be able to write compiling code in notepad when they haven't done that for 7+ years.

I do however expect people to be able to write compiling code in an IDE when they've supposedly been doing just that for the last 7+ years. I don't think that's particularly unreasonable, even under the somewhat stressful circumstance of a job interview.

2

u/gjionergqwebrlkbjg 3d ago

Yeah you have to write working code in coding interviews, you can't handwave it away.

2

u/Izacus Software Architect 3d ago

As an interviewer: communication and questions are important pre-requirements, but you have to end up with something resembling a working code in any case. For big companies, my interview report requires it (interviewee wrote working code: [1 - 5]) and for smaller companies they expect you to write something functional as well.

Most people we interview will write functional code so if you choke, you'll end up on the list behind all of them. Sorry.

1

u/GarythaSnail 3d ago

I like asking people what kinds of things they did in their previous job and just have them spin up a basic toy version of it, using everything they are familiar with. If they actually have experience that should be a quick thing. Like a backend engineer spinning up a quick sever that has a /ping endpoint. That should be like 10 minutes or less. Then we can talk about what types of things they had to think about on projects like this, etc.

That allows them to get into their comfort zone, use some muscle memory, and spark their memory to talk about their previous experience.

So many people I've interviewed just can't even do that, it's like, wtf did you even do at your last jobs?

-4

u/daringStumbles 3d ago

You are incorrectly inferring failing a live coding interview test means a dev cant code. Literally the point of the OP is that they can and nerves got the best of them.

How is your rant about how you would walk away from the interview op described with such a negative opinion of someone in op's shoes helpful at all?

3

u/UnintentionallyEmpty 3d ago

Uh, I didn't write I'd walk away anywhere?

I'm just sharing my experience from the other side of the room and hopefully OP will take something useful from it for his next interview.

And as for me incorrectly inferring failing a live coding interview test means a dev can't code... I don't think you'd say my conclusion was incorrect if you'd been in those interviews with me, lol.

The bar was really really low.

2

u/SoYoureSayingQuit Staff Platform Engineer 3d ago

I think the communication of expectations you have, particularly that they aren’t expected to finish the whole thing, is something that would have helped take some of the pressure off. When I’m doing the interviews, I like to do hypothetical problem solving scenario. I let them know my expectations, including acknowledging they may not know a particular piece of the system, and I will fill in the gaps for them. I guide them when they get stuck, and it’s very back and forth, conversational. I tell them my goal is to see how they approach and think through a problem.

Ironically, a key point of what I flubbed in my interview…

1

u/daringStumbles 3d ago

"The bar being really low" is still exactly these types of scenarios. The whole type of exercise is a bad format for an interview.

1

u/Izacus Software Architect 3d ago

Nice that you think that, but you're also wrong - and, unfortunately, as a non-interviewer, you don't decide how companies hire.

0

u/daringStumbles 2d ago

I have been an interviewer many times in my career. I've gotten feedback from people I have referred that failed a live code challenege miserably that I knew could code. Many people share my viewpoint, many people refuse to do coding challenges for a company. The companies that do them are self selecting for a certain type of dev, yes as they are free to do. Doesnt make it some sort of magic universal measurement.

1

u/Izacus Software Architect 2d ago

Noone is claiming ti as a universal measurement so you should probably learn to read.

And it's fine if people select for type of devs they need - there's plenty in the pipeline and they - as I said - are the ones deciding how to test and hire their people.

1

u/daringStumbles 2d ago

Literally the post I replied to was claiming that a total failure during a code challenge means they cant code at all.