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

Coding interviews are stupid (ish)

darrenkopp.com

Post reply on HN
Print view View original

391–400 of 679 posts

Re: Coding interviews are stupid (ish)

#391

Post by glandium »

godelski wrote: post #369
glandium wrote: post #350

Earlier quoted context omitted.

We live in the age of ChatGPT. It might actually be time to assess how candidates use it during interviews. What prompts they write, how they refine their prompts, how they use the answers, whether they take them at face value, etc.

Sure, and we live in the age of calculators. Just because we have calculators doesn't mean we should ban them on math tests. It means you adapt and test for the more important stuff. You remove the rote mundane aspect and focus on the abstract and nuance. You still can't get GPT to understand and give nuanced responses without significant prompt engineering (usually requiring someone that understands said nuance of t…

I'm actually not talking about interviewees (ab)using ChatGPT to pass interviews and interviewers trying to catch that or work around that. I'm talking about testing candidates' use of ChatGPT as one of the skills they have.

> I see you're the founder of Archipelago AI.

I don't know where you got that from, but I'm not.

Re: Coding interviews are stupid (ish)

#392

Post by roenxi »

xandrius wrote: post #270
roenxi wrote: post #40

Earlier quoted context omitted.

The roughest outline for hiring as far as I can follow it is start with 100 resumes, filter it down to 10 by picking ones that are nicely formatted, then filter down to 1 by interviewing. Each level of filtering should be structured so that it biases towards technical competence. It isn't really a licensure examination because, as you point out, the industry doesn't bother to put the resources in to make sure anythin…

Got any tips/suggestions on how not to be filtered out because of "formatting"? Got any great examples to share?

In my experience, pure black-and-white text does extremely badly.

If someone is in a position where they have to read through 100 resumes, there is a limit to how often they can look at a paragraph-formatted WYSIWYG text edited black and white document that says "I did well at school, I worked some jobs afterwards, now I want to work here". They blend together something shocking.

It is worth having a tasteful dash of colour or maybe a formatted header/footer where possible. Low bar, but there is a big pool of serially unable-to-get-past-screening candidates who can't clear it and you want to stand out from them if at all possible.

Re: Coding interviews are stupid (ish)

#393

Post by dbcurtis »

Lately, when I have to do a coding interview, I ask the candidate to test some code, not write some code. I learn a lot more about how they think that way, and if you have an argument as to why testing is not a relevant skill, I would like to hear it.

Usually I do something like this: candidate picks a language (let's say Python) and I will put up a function prototype that is maybe almost Pythonic, and has a SphinxDoc docstring that is subtly not-quite-complete, and say the rest of the function is a block box that you need to test.

First off, do you have any questions about the definition? Or let's say you saw this prototype for a yet-to-be-implemented function in a design review, would you have any input or want clarifications?

Then, I would ask the candidate to present some test stimulus and expected results. Not code, just make a table with inputs and expected output in columns.

I find out very quickly if they can think about corner cases, think about possible exceptions, know which exception is appropriate under various circumstances, and occasionally (too rarely...) I will get some opinions about various test frameworks that they like or don't.

This technique will not sort people by how fast they can code up a tree balancer. But.... if after hiring them if I were to ask them to implement a tree balancer, I can be pretty confident that it will work.

Re: Coding interviews are stupid (ish)

#394

Post by glandium »

ok123456 wrote: post #52

I've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a…

"Here is a bug report, and the patch to fix it, review the patch"

And the patch:

- does fix something but not the described bug.

- could do the same thing in a third of the added line count.

- has typos or other errors.

Re: Coding interviews are stupid (ish)

#396

Post by ipaddr »

dbcurtis wrote: post #393

Lately, when I have to do a coding interview, I ask the candidate to test some code, not write some code. I learn a lot more about how they think that way, and if you have an argument as to why testing is not a relevant skill, I would like to hear it. Usually I do something like this: candidate picks a language (let's say Python) and I will put up a function prototype that is maybe almost Pythonic, and has a SphinxDo…

If you are testing on a skill you can train you are doing it wrong.

Re: Coding interviews are stupid (ish)

#397

Post by VirusNewbie »

ryandvm wrote: post #177
VirusNewbie wrote: post #96

Earlier quoted context omitted.

Why do you think they haven't adjusted again? Is it possible it is actually (loosely) correlated to job performance? I interviewed at Google and all the questions were practical, challenging, and not found on leetcode. I've seen all kinds of interviews in my twenty years of experience, and while all types can be done poorly, (including DS&A ones), having some live coding is one of the best signals you can get in a sh…

> I've been blown away by a candidate while they're talking about their experience, but then asking them to code something small, they utterly bomb. You're making the opposite point you think you are. How do you know that you observed an inability to code as opposed to interview performance anxiety? I've been coding for 25 years, but have bombed my share of very simple white-boarding exercises because I panic and my…

>You're making the opposite point you think you are. How do you know that you observed an inability to code as opposed to interview performance anxiety?

I've done lots of interviews, and I know that if someone has seen a question recently, or if someone is rusty in interviews, or one of a million things can affect someone's live coding ability.

So I'm not looking for speed, I don't give more 'points' to someone who is calm and collected vs. someone who takes twice as long cause they're nervous. They both "pass" in my book.

I also don't particularly care if someone starts intermixing java and C++ syntax or forgets the string library and says len(var) instead of var.len() for example.

I'm even fine with giving hints. But there are literally people, with hints, who cannot write a basic recursive function or understand to check for null references. That isn't being nervous. That's just...being bad at the craft.

Re: Coding interviews are stupid (ish)

#398

Post by tptacek »

frithsun wrote: post #226

It's against federal law to IQ test employees, so they ask brain teasers that are IQ test questions thinly disguised as "coding questions." It's not a perfect system, but it works better than the alternatives.

It is not in fact against federal law to IQ test employees.

Re: Coding interviews are stupid (ish)

#399

Post by emseetech »

whstl wrote: post #300
xandrius wrote: post #257

Earlier quoted context omitted.

I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system struc…

I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library. It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn'…

| this kind of algorithmic knowledge was important to build features that were differentiators in the market

I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments.

So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful?

For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes.

That said, I'm not sure how to test this is an interview setting.

Re: Coding interviews are stupid (ish)

#400

Post by analyte123 »

dilyevsky wrote: post #139

Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

My go-to first screening question, regardless of where I work, is to present some JSON from a public API relevant to the domain (nothing too crazy, maybe 2 or 3 levels of nesting max), then ask the candidate to do a filter plus a sum or max - then for bonus, analysis or refactoring of their choice.

Way too often, this results in a painful slog, lots of hints from me, and, nowadays, snippets of AI generated code copied in that actually solve part of the problem but that they don't read and therefore end up breaking.

Post reply on HN