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

311–320 of 391 posts

Re: In defense of coding interviews

#311

Post by Apocryphon »

isbvhodnvemrwvn wrote: post #213
Apocryphon wrote: post #8

Instead of endlessly rehashing the controversy of coding interviews, has anyone considered just how engineers are expected to be able to understand the material on the interviews? Should it be from university CS programs? Which are supposed not to be vocational? And would discriminate against those who are not degree holders? Should it be from internships, which are nowadays subject to the same Leetcode examinations…

I don't get your comment on junior developers. We have no issue whatsoever hiring juniors (we hire about as many as mid-levels), but we don't have to settle for someone who doesn't have internships or projects and the openings can be closed in 2 weeks so it seems like nobody is hiring, but actually the bar has risen (and there are plenty of candidates who clear the bar).

That incredible dearth of junior positions is stranding a lot of new grads and juniors, as seen in discussions like this:

https://news.ycombinator.com/item?id=31537711

Re: In defense of coding interviews

#312

Post by endisneigh »

I wonder how well the following exam would correlate to job performance:

A completely fictitious language is developed. Simple enough that you can become fluent within an hour. From this you read a bunch of problems in said language and must solve them.

A set of assertions about the problems are written down and you must verify them. Finally a full program, created from a dialect of the given language is given and you try to understand

Re: In defense of coding interviews

#313

Post by adam_arthur »

ipaddr wrote: post #169
adam_arthur wrote: post #9

Earlier quoted context omitted.

Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on com…

It's 10x the worst not average developer so it becomes 2x the average. Besides a 10x developer cannot be uncovered through a leetcode test or a coding test. A 10x developer pushes back on requirements, bridges gaps.. identifies issues early.. it's about making things happen not typing faster or knowing the stack well

It's definitely 10x the average. But exact numbers are going to be subject to debate.

The worst are net negative productivity

Re: In defense of coding interviews

#314

Post by vorpalhex »

Tronno wrote: post #305
vorpalhex wrote: post #103

Earlier quoted context omitted.

It is better to not know and explore than adopt a bad process because you overheard it in a coffee shop. It's ok to not have an answer.

You have personally used at least one tool, language, or framework without reading its code or understanding it beyond a surface level. You've done this because some text on some website claims it gets the job done. And you probably do this every day (e.g. your OS, your phone, your microwave). People cargo cult because there isn't enough time to exhaustively research every topic from scratch. Civilization exists beca…

I'm going to put the definition of cargo culting here since we seem to have lost it:

> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Some examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion code for objects that garbage collection automatically collects.

Installing an app from the store is not cargo culting. Playing with a new framework is not cargo culting. Trying a new order at the donut shop is not cargo culting.

Re: In defense of coding interviews

#315

Post by robertlagrant »

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…

I can't tell if you think companies should hire everyone or hire no-one.

Re: In defense of coding interviews

#316

Post by Apocryphon »

maccard wrote: post #235
implmentor wrote: post #153

Earlier quoted context omitted.

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…

It might not "just fix" hiring, but at least it doesn't blinding accept the status quo and attempt to engineer an alternative that can then be evaluated. We are supposed to be scientists, are we not?

Re: In defense of coding interviews

#317

Post by ldjkfkdsjnv »

dagmx wrote: post #291
zach_garwood wrote: post #35

Earlier quoted context omitted.

Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.

It's not a boolean can/cannot code. It's a cannot code at the level expected of the seniority. I interview tons of software engineering candidates (pre pandemic it was at least one or two a week). At least half of my senior candidates fail basic phone screener questions. These are questions that reflect something they'd be doing day to day in the role, but also are incredibly standard in our field. The issue in most…

I think actually whats happening is some people are just not good at interviewing on the spot. And people are looking for gotchas in these interviews, "He didnt know how to use breadth first search?!?!?!", when the senior engineers daily life is probably more like a surgeon operating on a highly convoluted large scale code base full of business logic.

Re: In defense of coding interviews

#318

Post by Apocryphon »

peterhunt wrote: post #290
maccard wrote: post #241

Earlier quoted context omitted.

Algorithmic interviews optimise for algorithmic knowledge, not on the job capability. It checks for rote learning and time spent preparing for the interview. Knowing how to implement prefix tree or a hash table shows that you've learned solutions, but not that you can write good code in a team environment. Frankly I'd take a worse engineer that worked better in a team over a 10x that ends up silo'ed in 95% of cases.

That’s not a fair characterization of how most companies (well, at least FAANG) do algorithmic interviews. A good algorithmic interview does not test algorithm trivia. The question should be solvable with only strong structured thinking and fundamentals. For example, the much-derided “reverse a binary tree” question (I don’t ask it but I think it’s reasonable) doesn’t really require a ton of algorithm trivia. The dat…

Algorithmic interviews, at least the way they are formatted now (with interviewers silently watching over the candidate at all times, typing notes) also test for anxiety:

https://news.ycombinator.com/item?id=23848039

Maybe the content, despite it being able to be gamed and drilled via Leetcode et al, is sound, but the format in which it is tested may not be.

Re: In defense of coding interviews

#319

Post by Apocryphon »

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…

What was your journey from engineer to lawyer like?

Re: In defense of coding interviews

#320

Post by swat535 »

koonsolo wrote: post #134
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…

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.

This is really not rocket science. We have implemented in our company.

Step 1: An initial phone interview with the candidate regarding technologies of choice, war stories, etc

Step 2: A small coding exercise that is similar to what we work on. The candidate can solve this on their own time and email us the solution.

Step 3: Review the solution together and ask questions about their methods.

Step 4: Meet the boss & offer.

The coding exercise is only sent _after_ the initial phone call, so we don't waste their time or ours.

The only problem here is that we can't virtue signal that we follow FANG whiteboard interviews and pretend that everyone working at the company can invert a Trie Tree in a 30 minute coding session..

Post reply on HN