Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

Post reply on HN
Print view View original

231–240 of 391 posts

Re: In defense of coding interviews

#231

Post by vletal »

motogpjimbo wrote: post #222
vletal wrote: post #216

Earlier quoted context omitted.

Interviewing is assessing how a person would perform, not an actual day to day collaboration. There is a gap. You do not talk like you would to a colleague. You have a limited time and it's more one-sided to even the playing field. It's worth preparing for to overcome the gap. It's like a dance. Your are supposed to lead deriving the solution, interviewer is supposed to follow closely and judge your performance. If y…

I would never change the way I speak to someone just because they're interviewing me. If you're interviewing me it's with a view to working with me on your team a few months later. You would surely want to see the real me, not some constrained version. Maybe it's an age thing, but I'm comfortable enough with my skills and my knowledge that I don't feel the need to put on an act. And remember that you're interviewing…

I might not have been clear. It's not an act. You are not usually guiding your peer trough your thought process our loud step by step. That's inefficient. Yet that is what you should do to maximize the amount of information passed onto the interviewer. It's just a different setup to which most people need to adjust to.

Re: In defense of coding interviews

#232

Post by nowherebeen »

lapcat wrote: post #226
nowherebeen wrote: post #210

Earlier quoted context omitted.

> But I agree that Google is different than most companies. There the main thing is ads and search and infrastructure to run both of those. One of the Marques Brownlee videos mentions that when he met Eric Schmidt, Schmidt mentions that every problem Google have were scaling. If you look at it from his perspective, it would make a lot of sense why algo is so important for Google interviews. He applied it not only in…

"CEO Eric Eric Schmidt stood out because he 'was the only candidate who had been to Burning Man.'" https://en.wikipedia.org/wiki/Eric_Schmidt#cite_note-31 Funny how the "objective tests" that leaders apply to grunts never get applied to the leaders themselves.

It's the whole "Do as I say, not as I do" motto. In their eyes, you are workers, and they are employers, so these objective tests don't apply to them. They hire based on their need and not your wants. They don't need another Eric Schmidt, they need more lemmings to do lemmings work.

Ultimately, that's how I think these companies eventually mature. The people that know how to steer the cargo ship retires and you are left with workers that only know how to do the work assigned. Bureaucracy ensues and no one dares to steer for fear it would sink it or get fired for causing unneeded risk. And plus, they don't know how to.

Re: In defense of coding interviews

#233

Post by lapcat »

jordanpg wrote: post #230
d--b wrote: post #56

The dirty secret is that it’s never about the coding skills. It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not. And I think it’s fine. You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. What really mat…

SWE to lawyer here. The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests. Both have absolutely nothing whatsoever to do with being a lawyer or the kinds of activities that lawyers actually do. What they are are intelligence tests. They are easy ways for judges and top tier law firms to tell if you are "one of them." You can get your foot in the door if…

> The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests.

How are these analogous? LSAT is the Law School Admission Test. It gets you into law school. It doesn't get you a job as a lawyer. (The bar exam doesn't get you a job as a lawyer either.) And you only have to take it once, not for every job interview.

Re: In defense of coding interviews

#234

Post by schwartzworld »

mrwh wrote: post #88

Other professions handle this via professional qualifications. Architects - and please do contradict me actual architects! - are not tested on their knowledge of basic architectural concepts as part of interviewing at a firm, because that's what the professional qualification is for. You have done the test already. And here's where our industry isn't a "real" profession yet. There are plenty of qualifications one can…

Is there anyone who has never had a bad experience with a licensed qualified professional? Bad doctors, dentists and lawyers are easy to find. I wish I had a way of gauging knowledge before letting someone drill my teeth

Re: In defense of coding interviews

#235

Post by maccard »

implmentor wrote: post #153
koonsolo wrote: post #134

Earlier quoted context omitted.

I do a lot of interviews with potential candidates, and worked with plenty of those we hired (and unfortunately some we fired afterwards). If you have a better way on how to assess a software developer, I would love to hear it.

Not OP, but I would love to share some: I relate strongly to the anxiety induced descriptions in OPs text and thus try to avoid these when I interview devs as an engineering manager. Of all the candidates I have interviewed over the years I have never done a live coding interview because it is essentially worthless for me as an interviewer and only serves to discards potentially very clever people whose thought proce…

> Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time,

And in this case you're eliminating people who aren't willing and/or able to spend time preparing for your interview process. One of my previous jobs had a clause in the contract that all my programming work belonged to my employer; is your company going to sign a waiver that says they take responsibility if a previous employer sues? Doesn't matter whether or not it's enforceable or not.

What if you use that solution in production, do you compensate for their time in helping solve the problem like you would if the task was assigned to you?

Also, you're not really setting a level playing field here. How do you gauge a candidates experience/seniority versus the other 10 candidates you hired if you're not asking them the same questions or looking for the same things. Maybe I've solved that bug in my current job.

All this is to say that this doesn't "just fix" hiring - I don't know if it's any better or worse than giving people on-site tests, but you're at the very least trading one set of problems for another.

Re: In defense of coding interviews

#236

Post by jordanpg »

lapcat wrote: post #233
jordanpg wrote: post #230

Earlier quoted context omitted.

SWE to lawyer here. The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests. Both have absolutely nothing whatsoever to do with being a lawyer or the kinds of activities that lawyers actually do. What they are are intelligence tests. They are easy ways for judges and top tier law firms to tell if you are "one of them." You can get your foot in the door if…

> The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests. How are these analogous? LSAT is the Law School Admission Test. It gets you into law school. It doesn't get you a job as a lawyer. (The bar exam doesn't get you a job as a lawyer either.) And you only have to take it once, not for every job interview.

Fair enough; it's not a perfect analogy. The main point is the nature of the metrics.

Getting into law school is the first part of the "interview." If you don't have the LSAT score, you won't get into a prestigious law school, full stop. If you aren't in a prestigious school, then a huge swath of elite positions are permanently closed to you. (In general -- yes there are a sprinkling of exceptions.) The bar exam has nothing to do with it -- everyone has to pass that, no matter what you do.

The second part of the interview is law school grades and certain extra curricular signals. You're right, there is only one "interview." But the analogy still holds up, with respect to the nature of the intelligence and memory tests.

Re: In defense of coding interviews

#237

Post by dijit »

angarg12 wrote: post #29

Before we criticize the current interview format and propose alternatives, we need to understand how we got here first. This is my understanding of what happened (I wasn't there for most of this!). Leetcode-style interviews became popular in the mid 00s, primarily because they were used by hot tech companies of the time. The thing to understand is that at that time, the idea of asking people to write code during an i…

Was it really the 00-s?

I had two jobs at the turn of the decade and they were conversations about topics such as “where would I go to find authoritative information on x” (google is not the answer) and approaches to troubleshooting.

Granted, I’m a script monkey (sysadmin) but some level of automation has always been part of the job.

I’ve had precisely 1 leet-code style interview (2hours for 16 problems) and I couldn’t tolerate the pressure.

The interview I had at google was much more humane than what people are attempting to cargo cult.

Re: In defense of coding interviews

#238

Post by maccard »

ozim wrote: post #166
vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

Fun part is that it can work like ideal world when you have 1-2 devs per year to hire and as a small company you get 20-30 CVs a month. Once you get into scale where you need to hire 20 devs a year and get 100s of CVs per week it all breaks down.

I've been at companies where we receive hundreds of applications per role posted, and one where we receive 10s. I've posted about this before but in both cases the pipeline was the same - initial pass eliminates about 70-80% of the candidates because they're just not worth following up on - think things like IT staff applying for mid level development jobs with no experience, education or anything to indicate they could write any code. Of the remaining we end up filtering out based on comparing applications - this bit sucks, but pretty much stack ranking the resumes and picking out the top 20 or so[0]. At that point, everyone gets a phone screen with a set of questions picked from a list and we proceed through that. The same process works mostly because the size of your interviewing group scales with the number of engineers you hire.

[0] side note - I work in games where we're often filtering resumes for specific roles, e.g. a gameplay programmer or an online programmer. The filtering here is most of the time bucketing candidates based on their experience and sorting that way.

Re: In defense of coding interviews

#239

Post by gedy »

jordanpg wrote: post #230
d--b wrote: post #56

The dirty secret is that it’s never about the coding skills. It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not. And I think it’s fine. You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. What really mat…

SWE to lawyer here. The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests. Both have absolutely nothing whatsoever to do with being a lawyer or the kinds of activities that lawyers actually do. What they are are intelligence tests. They are easy ways for judges and top tier law firms to tell if you are "one of them." You can get your foot in the door if…

Great analogy. I think the rub is I wouldn't want to study for and take the LSAT before every interview, and especially not after working in the field for 10 or more years.

Especially if the interviewers make comments like "um how much do you actually practice law?" if you stumble on one of their pet quiz questions.

Re: In defense of coding interviews

#240

Post by [deleted] »

freyr wrote: post #170
vorpalhex wrote: post #89

Earlier quoted context omitted.

You can just ask them to talk about code. You can ask them to compare and contrast some frameworks or languages of their choosing. You can ask them to do design tasks, or just talk about the work the company does and let them ask questions. One of the things I like to do, especially when a candidate is super anxious, is just ask them to talk about a recent project they've done that they like and why they like it.

So instead of selecting people who can do algorithmic problem solving well (under pressure), you’re selecting people who can bullshit well (under pressure). I’m not convinced it’s really an improvement. I’ve worked with too many people who are great bullshitters but terrible engineers, who sailed through on their charisma. But that’s why most companies have a mix of technical and behavioral interviews.

[deleted]
Post reply on HN