[Peroni]

I've been in this game for a while now and the breakdown is pretty simple. If you are an employer, I implore you to trust me on these two simple points:

1. Finding decent people that are both technically competent and a good culture fit is bloody tough and can take a lot longer than you'd ever expect.

2. Interviewing/screening these people is simple. Don't make it more difficult than it needs to be.

You've done the hard part and you're confident the person/people you've found are worth at least a couple of hours of your time for an interview so why waste that time by applying a boilerplate interview process that every other company uses?

Give the candidate a realistic technical challenge to complete in a realistic timeframe, in an environment that will be indicative of the environment they would expect to work in should they succeed in getting the job.

If you're happy with the technical results, spend at least an hour with them having an actual conversation. Don't sit there throwing stock interview questions at them, don't try and nitpick on their CV. Just talk to them. Get a feel for their personality, the things that motivate them, the things that annoy them, the things that inspire them, etc.

[dylangs1030]

I highly second this. To offer my own recent experience, I just had an interview yesterday of this format. It was around 4 hours (5 including lunch with the team).

1. I was repeatedly made to feel welcome, comfortable and calm as I possibly could be by everyone I met.

2. I was given technical questions that were appropriate and highly correlated with what I would be doing on a daily basis.

3. I spoke directly with two founders who, despite having my resume, opted for talking to me about my background, my goals, and offered answers to any questions I could possibly think of.

4. I was interviewed by four people total, and only one at a time.

It was honestly the most enjoyable interview I've ever had, despite the fact that I was initially nervous and didn't know what to expect, and it took the better part of a day. It was literally fun - if nothing else, this experience has given me a model for how I would interview candidates in the future if I am ever a hiring manager.

I wish every company operated this way - on some level, I think a lot of people who interview candidates don't know what they should look for, so they fall back on the "legendary battery" style of asking a suite of questions that only a recent 4.0 MIT CS graduate could answer confidently (and who could totally fizz out when asked to do something that isn't in Intro to Algorithms).

[ori_b]

> Give the candidate a realistic technical challenge to complete in a realistic timeframe

The problem is that a realistic challenge involves figuring out a realistic system. Realistic systems tend to be large, complicated, hairy. They tend to involve a lot of domain knowledge. They tend to have subtle considerations.

Working with a realistic system does not generally take a realistic amount of time. Not for an interview, at least.

[Lost_BiomedE]

I long for an interview like that. I first left the tech industry due to having to deal with HR and the hiring process.

I became a chef, where the interview could be moved to having them watch me make a dish or show knife skills. Then out of interest, I went through a biomedical engineering degree and am back into the tech field.

Still, due to my negative experiences with the filtering process, I have stayed in the realm of freelance and contracting. I would jump back into a tech job if interviews, like the above, were more common.

Thanks.

[mmcnickle]

I've always thought the simple coding interview questions was like asking a chef to prepare a very simple meal; they should be able to do it without any problem. Though it's apparent that coders, like chefs, can choke on even these simple tasks. You only need to watch the "skills tests" on "Masterchef: The Professionals" to see a dozen professional cooks fail to fry schnitzel or fillet a fish. The same chefs go on the create some fantastic dishes in less stressful challenges.

[nawitus]

One additional difference is that interview coding questions don't have a realistic working environment. Programmers utilize tools like search engines, IDEs and documentation, but these may be not available in a coding interview question, which might mandate a programmer to work on a whiteboard or using unfamiliar software.

[mfringel]

It's like asking a chef to prepare a very simple meal, but what most bad tech interviewers actually ask is "prepare it exactly the way my mom used to make it for me, which I'm not going to tell you."

[hackinthebochs]

>Get a feel for their personality, the things that motivate them, the things that annoy them, the things that inspire them, etc.

What exactly are you trying to determine from this? The problem with such open-ended types of questions is that all objectivity is lost. You end up picking people who mirror your own motivations, annoyances, etc. Unless you are sure your question will produce actual signal in an objective manner, you shouldn't ask it. You are just biasing the process in favor of people that will flatter your own ego.

[cpprototypes]

If technical competency has already been established, then there should be no problem with asking these kinds of subjective questions since it's meant to screen for a subjective area (team/culture fit).

[hackinthebochs]

It's not obvious that the examples given do that (besides whether you'd want to have a beer with them). If there is a specific set of behaviors that you believe will better gel with the team, then ask questions that are signals for those specific behaviors. Or, perhaps you should simply set up processes that enforce those behaviors.

[derefr]

I do believe what is being suggested is that people only hire people they want to have beers with.

[HelloMcFly]

One could argue that while you're overtly trying to screen for cultural fit, what you're actually screening for is self-monitoring, presentation skills, etc. But that's a "problem" with all interviews, structured or no, and typically those attributes are functional anyway.