Hacker News Reader

Same! This topic gets me soo irritated. If someone is supposed an expert in a field (hence them being an interviewer) how can an average joe fool them into thinking they know more than they actually do during a conversation?

Even now with LLMs generating almost real time, there is always a slight delay and we all know that LLMs are far from perfect.

It seems the tech community on one hand complains at how bad LLMs are for doing deep tech while at the same time fears them as they can make any candidate pass interviews. So which one is it?

Also, the simplest trick even old-timers professor already know:

1) Prepare an open ended question about X

2) Ask it to ChatGPT, Claude, etc.

3) Take note of the titles, keywords used, etc.

4) Ask it to the candidate

5) Compare responses

Not all interviewers are experts. If you are building out your business you will be hiring roles that don't exist yet. Of course that brings different requirements for that first hire, but judging their skill level might prove very hard.

I think it's worthwhile doing simple coding tests to check that the interviewee can actually code. It seems crazy but I've interviewed plenty of people that couldn't write a simple for loop.

I agree asking difficult leetcode questions is less useful because it depends so much on whether people have practiced (or now whether they cheat with AI). Often these questions are so difficult there's no way you could come up with a solution in an interview situation if you hadn't already seen it.

Getting rid of all coding interviews is stupid though. Other industries would kill to have such an easy to test skill! We shouldn't throw away such a nice thing just because some people take it too far.

There are people who can talk their way out of trouble for sure. That is why I suggested the take home exercise followed by a discussion.

It's only when there's niche knowledge involved that I think it isn't necessary, because you won't be able to answer any hard questions properly without having actually worked on code for that niche at one point or another.

Most applicants fake the take home problem or have someone else or ai do it for them.

You have to watch someone produce a compiling for loop to prove they’ve ever built software before. Fraud is rampant.

I've been lucky to never have to deal with that. Sucks for everyone that has.

On the other hand, I personally cannot code properly while someone is conceptually "breathing down my neck". A for loop sure, but I'd probably fail at writing a hash table or whatever despite nearing 10 years of experience on many different projects, including compiler frontends and a simple garbage collector I wrote for the fun of it.

Today, I guarantee you that candidates will eventually take that risk to cheat in the online assessment stage in the hopes of getting an offer from the company and will likely turn into a bad hire.

Not hiring them is better than a bad hire.

If it were me, I would not use Hackerrank, Leetcode, or other online puzzles sites. Instead it would be just a conversation in to just show me your open source contributions in large repositories or you building projects (open / closed) that others are using.

That is it.

For contributions, they must be under public code review or you doing the review and for open source projects they shouldn't be hello world / test projects but useful to others which are used as dependencies in other larger open-source projects.

A basic easy conversation that rids of 95% of cheaters and frauds and those who cannot code.

Not everyone has open source projects to show. Also, for the ones that do, extremely few would be used as dependencies in larger projects, so that requirement is just ridiculous.

Also, how do you even know if it's the candidate that has developed the code? You simply don't know if the candidate copy-pasted the code.

Secondly, just because someone cheated at an extremely difficult Leetcode problem doesn't in any way mean that they can't code on the job. Jobs hardly require such problems.

Instead, ask the candidate to explain specific parts of your code that you show them. It can also be cheated, but it has both a screen and a voice input component, so cheating would take more work.

When I say for loop, I mean for loop. No tricks.

Declare a variable with any number type initialized to the value 0. I’ve seen candidates fail that, spend 30 minutes attempting to declare a variable in the LANGUAGE OF THEIR CHOICE.

That is really grim. I work on rather niche systems engineering stuff so that already serves as a pretty major filter, your average codemonkey won't even bother applying to this sort of stuff.

Exactly. "Yes to fizzbuzz, no to leetcode" seems like a reasonable position that few companies take; usually it's either both or neither.

In my entire career, I only once had a situation where they gave me a trivial technical problem, I wrote the first line, and they were like "okay, you passed the test, no need to finish this, we just use it to filter out the people who can't even start". And then we talked.

But usually it's either just talking, or some puzzle that requires you to remember some extremely specialized optimization technique which you will never in your life use again if you pass the test.

I agree. My whole interview technique is just to have a long conversation with the person.

My team was hiring recently. Guy comes on, says he's never used Rust, but has some thoughts on it. We talked about all the pros and cons of it, what the system requirements would be, and so on. He talks us through everything to do with the domain, just two seniors talking to each other at a high level. Very pleasant.

We hire him, and a month later he's making idiomatic Rust.

No need to put people through a ridiculous gauntlet.

You got very lucky. Congrats!

This industry is unfortunately full of very charming, polished, smooth talkers who would ace that interview and then 3 months later it would dawn on you that you made a big mistake. There is this growing breed of "LinkedIn thought leader" types who, during character creation, put all their skill points into Charisma. And they're really good at sounding technical, using the right buzzwords, overwhelming the interviewer with word-salad, subtly steering the conversation towards areas where they have crisp, prepared answers, and so on. They look great, speak eloquently, and have those ivy-leaguer mannerisms that allow them to breeze through these kinds of informal chit chat interviews. Doubly so if that kind of interview is conducted by an exec or someone less-technical. Beware!

> conducted by an exec or someone less-technical

It only works if you are technical. Yes, your sales guy will not know a diamond from a fugazi.

But as a senior tech guy, I don't think it's ever gone wrong. I've never hired a guy who I thought could code and it turns out he couldn't.

You have to be willing to have the conversation with only a few scripted questions, just a few essentials. Everything else an open field. You let them sculpt it into a garden or dig their own grave, either way you give them a shovel.

Yep, it’s why I stopped looking for software development jobs long ago. It's this die-hard criterion that’s based on very isolated problem-solving issues rather than the big picture or the concept at least. This has resulted in the current outcome of software development nowadays, where you need a ‘wrangler’ (aka product manager) and all sorts of useless methodologies to deliver a product that’s literally identical to hundreds of products out there.

It gets even worse than that, with hiring based on arbitrary values. One of the companies I worked for before had an engineering manager who chose one candidate over another simply because he had a repo with thousands of stars.

Creating and maintaining popular open source software seems like a reasonable criterion for deciding between two otherwise-similar candidates for a software development role.

Every single big corpo knows about it. We just haven’t been able to come up with a better filter for the amount of candidates that are going through the interviews that isn’t extremely subjective.

Small companies that I interviews with had a very simple process (2x talks with upper management, mostly technical talks, also a semi-coding related talk about systems). There are a lot of very well paying (maybe 15-20% less than FAANG) jobs out there, but they’re just that fancy looking.

I guess FAANGs in particular have rather messy recruitment due to the amount of applicants, but my experience is from a giant multinational, talking hundreds of thousands of employees globally here, not "small" by any stretch.