Hacker News Reader

Comment by westoque | Hacker News Reader

The tech interview process is different for every company but it's definitely not broken.

As a CTO, one of the things I look for is experience. You can look up all the "basic shit" you want but if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem. If I'm interviewing a senior engineer, I want you to be able to show your seniority one way or another, if we talk about architecting something, I want you to be able to talk about why we want to solve it this way, pros-cons etc. Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key.

View on HN

In the macro, there is a ton of demand for engineers yet short supply (particularly for universities). Thus the very high false negative rate observed at nearly every company indicates the interview system is broken.

What would help is more disclosure from hiring managers and interviewers about what they want and the success rates of candidates. That information is still largely today only available to hiring managers and executives. We need less information arbitrage for a more efficient hiring system.

> Thus the very high false negative rate observed at nearly every company indicates the interview system is broken.

What high false negative rate? Can you point to some data?

By "false negative", are you referring to rejecting a good candidate? Are false negatives (rejecting a good candidate) more important than false positives (hiring a bad candidate)?

> We need less information arbitrage for a more efficient hiring system.

How do you define efficient? Whose efficiency are you considering, the company or the candidate? Why should efficiency be a primary goal of the hiring system, as opposed to simply finding the best candidates in a reasonable time frame?

Engineers are of course not a uniform thing and every role is looking for different experiences and traits, so you’ll get a lot of good engineers knocked back from interviews who go on to get a job somewhere else. This might be trite but thought it is worth mentioning as what seems “unfair” can often just be this.

More information just makes it more difficult to filter out the scripters trying to automate their job applications. That's the biggest issue I have seen, personally. There's too much noise on the channel, and giving any advantage to the CV spammers is not going to make it less noisy.

The cost of a false negative to the employer is quite low (missing on a good candidate) compared to the cost of a false positive (hiring a bad one).

In my experience, speed is the opposite of key for longer term success. Speed is how my companies have ended up with designs and implementations that weren't maintainable and/or had big gaps in them.

I'm sure the usefulness of speed varies by context

> most tech role interviews involve some sort of coding challenge

He is talking about coding challenges specifically.

> Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key.

If you feel that way, here's a viewpoint from Derek Sivers which talks about "Idea being a multiple of execution" [0]. If you genuinely believe that "solving a problem within a few minutes" can be reached, I'm going to ask you - What problems are you asking people to solve in a limited time frame?

[0] https://sive.rs/multiply

I'm curious about the reasoning behind these statements.

For example:

> if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem"

Why does this matter? Why do you want this? How do you correlate what you're stating you want here with actual job performance?

> Why does this matter? Why do you want this? How do you correlate what you're stating you want here with actual job performance?

It matters to me because we want to be able to show that we can think through solutions. If we're building a feature that has something to do with streaming video, it would be a plus if you've shown that you have experience building streaming services or at least some knowledge along the topic. This should correlate with job performance because of the experience and working on this topic is already known. Now, there would be a case where we have 0 experience with this problem space but again it comes down to thinking through solutions and thinking about race conditions, side-effects etc and being able to identify these.

Reply on news.ycombinator.com