Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I ended up choosing the job that had no whiteboard interview or personality test. It was just a simple conversation with the tech lead about my previous experience and if I had the experience to work on their current system

I miss interviews like this. We need to compile a list of companies that still do this. In fact, getting on that list could really help a company's recruiting efforts - which in turn could influence other companies to adopt this interview style.




I think they're gone because, within the limited time of an interview, it's hard to prove competence with chatting, for yourself, and especially in a way that can be communicated to others in the panel. Most places I've worked, firing is a bad bad thing. It means everyone involved with the hire failed, and morale is hurt by everyone that sees the person let go.

When I first started interviewing, this was the method I used. It turns out that most people have fanfic for resumes. "Designed a system" or "worked with a system" actually means "played an insignificant part in the design of a system" or "minimally modified some existing code". Getting to a point where this is obvious can take a significant portion of a 45 minute interview, and almost always comes from digging into the nitty gritty of the details, very close to code. Then, worried, you have them try to write some basic code as time runs out, and they completely flop, with that, and whatever small thing triggered your suspicion, being the only useful evidence you can point to for why you're saying no, even though others are saying yes.

So, I flipped it. I go for real evidence first, which gives me objective, repeatable, results, then any remaining time is left to talk and go into depth. I give them an easy work related problem, requiring realistic syntax. I've had people that were fantastic with communicating their ideas, and even pseudocode, but didn't know the syntax of a function or simple for loop, in the language of their choice. Take home code/screens can't be trusted, without basically goin through it line by line. Heck, video interviews can barely be trusted these days. I've many had people obviously, and not so obviously, copy paste the top google search result. I've even had people double team an interview, with the second person listening and typing the results on a second screen.

That said, I completely agree. My dream interview, either side, is just getting nerdy for an hour and a half with someone. But, especially for less senior roles, I can see why it's not popular, especially if you're stuck with short interviews, or are not the hiring manager, where you don't have to objectively justify things. Interviews are, unfortunately, a fairly adversarial interaction.


>Getting to a point where this is obvious can take a significant portion of a 45 minute interview

I mean, without the project being some huge OS thing it's hard to prove contribution it in any amount of time. I don't mind some simple system design questions to sus that out (and maybe relate it to a work experience to test some validity), but instead it turns into 4 rounds of Leetcode. A waste of time and STILL not making it obvious.


At least for our group, the problem comes in the required defense of the written justification. Coding is a better consistent and objective signal, than passing a free form conversation that's completely different for every candidate. A free form conversation also makes the whole process much more susceptible to bias, which is part of the reason we're urged to have the same interview for each person.

If you have four people on the panel, and they're all trying to piece together something perceived as objective, then you could definitely end up with 4 rounds of leetcode. In our group, we have different people focus on different things, so this doesn't happen.

But, I think we're in agreement. I don't think a "conversation only" approach is good, because at the end of the day you have to make sure someone can actually code. A code only approach isn't good, because it severely limits the context that the person can show competence.

I would love to hear opinions on how I could interview better. I've never heard anyone claim that interviewing is easy, or solved, and I'm definitely not doing that here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: