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

401–410 of 432 posts

Re: Don’t do interviews, do discussions

#401

Post by swman »

Hermitian909 wrote: post #247
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…

As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them. Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved a…

What happened to references? That’s an easy way to verify if someone is bullshitting. It is possible to bullshit your way through interviews (there’s a whole industry to help you do just that) and not know good software engineering patterns.

Re: Don’t do interviews, do discussions

#402

Post by zsmi »

soneca wrote: post #310
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…

Isn’t the time spent memorizing leetcode similar to the time spent building a side-project? I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.

> Isn’t the time spent memorizing leetcode similar to the time spent building a side-project?

The nice thing about leetcode it is easy to bound the time to what you can handle. I do one puzzle a week and set a timer for 20 minutes. Then I get the answer and browse the forum. It's basically the equivalent of solving the Sunday crossword for me, and it keeps my algorithm skills sharp. Probably no worse than burning a lunch hour on HN.

Re: Don’t do interviews, do discussions

#403

Post by zsmi »

auggierose wrote: post #313
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…

I don't like it, but I get it. You can train for the algos, so just do what needs to be done and train for it. Maybe you don't like to do what needs to be done? Well, that filter worked. Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)

> Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular

It's also hard to scale it, make it objective, and keep the efficiency high (most developers prefer not spending their time on either side of the interview table)

There is another advantage to the "algos". If you can learn algorithms then perhaps you can learn other things as well.

Every new job I've had involved quite a lot of learning in a very short period of time.

Learning whatever language, and whatever standard library is almost always trivial. They're usually not all that different, well documented, some with textbooks even.

Learning to navigate and reason about the huge number of undocumented, often arbitrary, system architecture decisions, design decisions, code layout, etc. etc. that make up real code bases.

That's hard. Really hard.

Re: Don’t do interviews, do discussions

#404

Post by quercusa »

bigmattystyles wrote: post #13

I do the discussion approach, but my goal is to make sure I 'give candidates enough rope to hang themselves'. I also make extremely clear that it's ok to tell me that they don't know or aren't sure. A lot of times, I never ask the question that makes someone look bad, I just let them talk. No interview system is good, but after cycling through many interview styles, this is the one I have found to be the least bad. O…

I usually pick some topic to do a deep dive on; I want to hear someone say "I don't know." If they can't or won't do that and just try to fill in with BS - that's a really bad sign.

Re: Don’t do interviews, do discussions

#405

Post by ernst_10 »

dtoms wrote: post #118

Don't do interviews, do take home tests. Do what's representative of the work you will be doing. I highly doubt even at google that it's a life or death situation that you correctly code an obscure algorithm in 30 minutes. Folks think you "cheat" on take home, but all they are doing is selecting for folks who "cheat" by being able to memorize massive amount of leetcode questions, its still a poor signal. 6-8 400-500K…

> all they are doing is selecting for folks who "cheat" by being able to memorize massive amount of leetcode questions

This takes an extremely high level of cognitive ability, which is a far, far better signal than a take-home test.

Re: Don’t do interviews, do discussions

#406

Post by austincheney »

kube-system wrote: post #165
austincheney wrote: post #85

Earlier quoted context omitted.

There is a couple of problems with that. More than half the time I have interviewed nobody reads resumes. They know your name and kind of how long you have been employed. Second, you control what appears on your resume. You can spin it how you want by the facts you include and omit. You list the great selling points about yourself and none of the bad. Don’t lie on a resume because its already under your control and i…

When I interview, I don't spend much time reading the resume beforehand, but I'll ask a few specific questions about it during the interview. If one assumes nobody reads their resume, however, then what benefit would they get from lying?

A resume is not an interview.

Re: Don’t do interviews, do discussions

#407

Post by twiddling »

swman wrote: post #401
Hermitian909 wrote: post #247

Earlier quoted context omitted.

As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them. Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved a…

What happened to references? That’s an easy way to verify if someone is bullshitting. It is possible to bullshit your way through interviews (there’s a whole industry to help you do just that) and not know good software engineering patterns.

Most companies won't do references beyond verifying employment. Then you relying on professional references, and are they lying?

Re: Don’t do interviews, do discussions

#408

Post by soneca »

zsmi wrote: post #402
soneca wrote: post #310

Earlier quoted context omitted.

Isn’t the time spent memorizing leetcode similar to the time spent building a side-project? I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.

> Isn’t the time spent memorizing leetcode similar to the time spent building a side-project? The nice thing about leetcode it is easy to bound the time to what you can handle. I do one puzzle a week and set a timer for 20 minutes. Then I get the answer and browse the forum. It's basically the equivalent of solving the Sunday crossword for me, and it keeps my algorithm skills sharp. Probably no worse than burning a l…

I do my side projects the same way

Re: Don’t do interviews, do discussions

#409

Post by vineyardmike »

Jensson wrote: post #221
vineyardmike wrote: post #214

Earlier quoted context omitted.

> I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. This is the impossible problem with hiring. Every interviewer wants to minimize false positives (they're expensive!), but every interviewee thinks they're a false negative.

Which is funny since I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome". Anyone with impostor syndrome would view themselves as a true negative.

> I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome"

I don't think this could be true? If you think you don't belong/deserve the job (imposter)... why would you think you deserved the job (false negative).

Re: Don’t do interviews, do discussions

#410

Post by twic »

logfromblammo wrote: post #391
vsareto wrote: post #307

Earlier quoted context omitted.

>and they just don't have nontrivial answers. Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.

To extend the plumber analogy, prospective employers will frequently look for plumbers with specific experience in copper pipe, rigid PVC pipe, or flexible PEX pipe, as though fragmenting the plumbing space in this fashion has any bearing on whether or not the result will conform to building codes, ensure that all the drains and faucets work as expected, and generally solve any fluids transport problems that may come…

Quite often, though, you hire tradesmen and they're bloody terrible. More often than not. So i'm not sure this is a very motivating analogy.
Post reply on HN