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

Don’t do interviews, do discussions

thinkingthrough.substack.com

Post reply on HN
Print view View original

361–370 of 432 posts

Re: Don’t do interviews, do discussions

#361

Post by b20000 »

jandrewrogers wrote: post #228
swman wrote: post #197

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with…

The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.

yeah, and some very competent people have no time or interest in timed coding tests and know that great software is not built that way.

if you have been through a CS program you have worked on probably at least 10 projects. and then there are your personal projects. if you have any experience you can talk about at least some of these apart from the stuff under NDA.

so, this approach is much better than timed coding interviews and is a much more fair system as it rewards and takes into account experience.

Re: Don’t do interviews, do discussions

#362

Post by disgruntledphd2 »

xyzelement wrote: post #151
osrec wrote: post #148

Earlier quoted context omitted.

I understand your point of view, but I'm the sort of person that responds poorly to someone asserting too much authority. I've had issues with bad interviews before, where I've been rejected by someone, but then got the same job at the same firm, when interviewed by a different person. Also, the lost earnings argument doesn't matter much if it comes at the cost of your mental health. A bit unrelated, but there's an o…

I hear your example and I have the counter :) I had an interviewer push deep on a failure. The entire interview, maybe 45 minutes, focused on something I failed to pull off at my old job. He kept pressing me for "what else I could have done" and I kept coming up dry for most of the interview. Two magical things happened - during this interview, I realized that I missed a huge opportunity at my previous job (in that c…

Huh, that's a really interesting story.

I can only imagine how difficult that company finds it to hire though, as a lot of people I encounter in professional settings don't seem to have this ability when applied to ther own actions.

Re: Don’t do interviews, do discussions

#363

Post by FigurativeVoid »

jandrewrogers wrote: post #228
swman wrote: post #197

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with…

The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.

This follows what I think of as the best technical interview I ever had. It was for a more junior role, but it was pretty good.

Here's a basic straw man rails controller. There are a few things wrong with it. Apply suggestions. It was nice.

Re: Don’t do interviews, do discussions

#364

Post by saithir »

philbert101 wrote: post #250
swman wrote: post #197

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with…

This is pretty pretty much what I tried to achieve here https://github.com/philbert/take-home-tech-test The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to. Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the re…

> You do not have to start a new project from scratch. It’s perfectly fine to submit something you have previously created yourself. Maybe it’s something you work on in your spare time, just for yourself!

Yeah, no, nobody is or should be giving you their own personal work. It's offensive and probably illegal that you'd even ask.

> The novelty and creativity of your submission

Yeah, no.

Re: Don’t do interviews, do discussions

#365

Post by scottLobster »

twic wrote: post #304
jandrewrogers wrote: post #228

Earlier quoted context omitted.

The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.

I do experience-based interviewing, and i have never encountered this problem. The great majority of the time, people are able to talk about anything. Sometimes, there are sensitive parts of prior work, but a candidate can just talk around those bits and focus on the rest. Even if someone had been working somewhere super-secret, if they aren't a junior, they have other experience to talk about. If all your career exp…

As someone who's done classified work, the general guidance we got is that we can speak in generalities.

So I can't say what the code specifically does or who it's for, but I can talk about how I worked on a c++ engine wrapped in a Java server that was responsible for coordinating a large group of non-homogeneous assets, as well as various architectural details (what libraries did we use, database, messaging setup, etc). So it's not like I have nothing to talk about in an interview, plus the fact that I can't get too specific adds mystique. It's kinda fun, because in my experience there's an assumption most engineers/engineering managers make about what I've worked on from that first statement, particularly if they know where I work, and it's actually not that. :)

Re: Don’t do interviews, do discussions

#366

Post by haspok »

philbert101 wrote: post #250
swman wrote: post #197

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with…

This is pretty pretty much what I tried to achieve here https://github.com/philbert/take-home-tech-test The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to. Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the re…

This is a really bad take-home exercise, because it is way too vague. This vagueness makes it very hard for me to decide how much time to devote to it, and what task is complex enough so that you will consider it, but not too small so that you don't throw it away. Instead of giving me a bar to jump over, you make the bar invisible, then expect me to jump just above it. So I hope you do have a default project for those who are not "creative"... at least not for the purposes of a job interview...

Re: Don’t do interviews, do discussions

#367

Post by slingnow »

wiseowise wrote: post #256
throwaway98az8 wrote: post #43

Earlier quoted context omitted.

Typical FANG employee... Hates whiteboard interviews until they get into FANG, then thinks that anyone outside of FANG is actually delusional about their skills and must whiteboard to prove themselves worthy of handling the incredibly challenging world which is FANG-engineering. More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...

Why are you so upset that somebody considers themselves smarter than you? Serious question.

Interesting that you decided that the OP:

1. Is upset

2. Interpreted the parent comment as being smarter than OP

Serious question: where did you infer these things from?

Re: Don’t do interviews, do discussions

#368

Post by haspok »

cj wrote: post #332
cutthegrass2 wrote: post #294

Earlier quoted context omitted.

Yep, agree. 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. The 5% that isn't, has no place in an interview. It's a bunch of brittle glue code automating and backing up data between my devices. "Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest... Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the inte…

> 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP (like util functions, and an integration syncing records from your backend the Salesforce, or something tangential to the business outside the core product) May technically be breaking you…

> would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP

Who decides what is "critical IP" and what is not?

This is a terrible advice, and no, you should never copy code from a work project without being pre-authorized to do it.

It's not just common sense, but you also might trip up over unexpected legal issues (licences etc) that you may not even be aware of.

Re: Don’t do interviews, do discussions

#369

Post by commandlinefan »

Hermitian909 wrote: post #263
TrackerFF wrote: post #260

Earlier quoted context omitted.

There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'l…

It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal. A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in t…

> It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company

I'm always curious how people interview doctors. As bad as getting a bad programmer might potentially be, getting a bad doctor must be exponentially worse, so you'd think they'd have vetting the unqualified folks down to a science by now.

Re: Don’t do interviews, do discussions

#370

Post by hippyup »

Clubber wrote: post #350
Hermitian909 wrote: post #283

Earlier quoted context omitted.

Across all examples I can think of - some yes, some no. It's not material to my point either way. I was only arguing that for some company's being very afraid of bad hires may be sensible and dismissing their concerns as hysteria does not seem obviously correct to me.

>In your examples, did they go through a coding challenge / whiteboard process? I think he was trying to point out that if some of the bad candidates had passed a whiteboard test, it brings in to the questions of the effectiveness of whiteboard tests to filter out bad candidates. I remember a guy we hired years ago who answered all the tech questions we asked with flying colors. He was lazy and unmotivated and ended…

Saying this method of interview is not 100% effective so it's useless is not a great argument. Reality is that bad hires are really expensive (as argued above) and that current interview methods are somewhat - admittedly not 100% - effective at avoiding those while mostly - again not 100% - effective at admitting the great hires. Maybe this "convert to discussion" method is more effective (I have my doubts), and I'm sure there are more effective methods out there and we should look for them, but let's recognize the reasons for what we have while we look for something better.
Post reply on HN