Comment by hnfong | Hacker News Reader

Comment by hnfong | Hacker News Reader

Parent Full thread

I read your story and the only thing I can think of is: I have no idea how to "properly" interview you, and I don't think anyone knows how to either (except maybe just reading your CV, having a pleasant chat with you for 30 minutes, then handing you the job).

All this ranting seems to be against a one-off event into a (presumably) multi-year gig.

Switching careers just because of a couple bad interview experiences is a really interesting line of thought, but assuming you actually act upon the idea (instead of just dwelling on it because you thought software interviews are bad), maybe in the process you'll gain a bit more perspective of how good or bad the software industry is doing w.r.t. interviews as compared to other industries.

Don't worry about sounding like too much of a baby on HN, it seems everyone else here also wants to be fawned upon by random strangers in the interview process and have a list of a dozen things they would absolutely not tolerate during the process.

Madness, if you ask me.

How about a single 4 hours coding session in which you and another engineer work on a real application solving the real problems the hiring company is working on?

What do you really test when you ask an engineer with a ton of experience to solve a classic Leetcode problem like implementing a trie-based search? The only thing I can think of is that you are confirming they made an effort to brush up their algorithm and data structure knowledge.

If you take 10 people, they will give you 20 kinds of interviews they prefer. You can't make a perfect kind of interview.

I can already see people bitching about your proposal:

- it's too long

- coding along with another engineer is unrealistic

- it's close to impossible to scale this out to a number of interviewers as there are no strict scoring guidelines

- it's too different from what other companies do

- it's trying to outsource some of the problems your company has

- it's too technology specific

- candidates who know the domain will have an advantage

- candidates who know your tools will have an advantage

I'm not saying these are sensible arguments, but you will hear them against all and any kind of interview you can come up with.

"The ideal candidate is somebody deeply familiar with the tech stack we are currently using, preferably having spent at least 6 months working on our code base."

Seriously though, the performance of an interviewee in such conditions are mostly a function of how well the interviewer can "onboard" the interviewee within 4 hours, or how much the interviewer is willing to actively guide the interviewee to the solution (as opposed to letting them figure it out).

Even with a single interviewer this easily introduces bias. I've interviewed many many people over the years, and sometimes I wonder whether I'm giving slightly more hints or less hints based on how subjectively I "like" the candidate. I mean, I try hard to be fair, but I don't follow a strict script, and the variability occasionally makes me doubt myself.

For such open ended tasks as 4 hours of essentially pair programming, I don't know how any interviewer could be objective and fair. Especially presuming that you wouldn't be re-using the same task once it's actually been solved/fixed... (otherwise that's just another artificial problem)

You don't get it. :)

Algorithmic interviews like that test your capacity for bullshit. They're like "I know I'm testing you on irrelevant bullshit, but I want to see you succumb to my unreasonable demands to have studied trie-based search, because that means you are more likely to swallow any other bullshit I'll throw at you on the job".

I love this idea for an interview. This would give you a good idea of what the company is actually working on the quality of the code base and who you would be working with. Interviewing should always be a two-way street.

You may want to look at this through a hiring manager eyes.

Create a job posting on linked in, then review thousands of those CV's, pick people and have a 4 hour interview with each (meaning repeating the same problem, you don't want to have a different 4 hour coding session with each individual).

Then calculate how much time you wasted on (a) outright scam (b) people lying about their experience (c) people nervous enough so they almost freeze (d) people not motivated as if you already owe them something.

Then, you need to realize that you probably need more than 1 engineer and you'd want to repeat the process.

Things like leetcode at least filter out people who can't code and people not motivated enough to solve a couple of challenges. Yes, this will not prevent scam. And then you can filter out scam on the follow-up call.

If you solve this problem of getting qualified engineers to the companies at market rates (not overcharging like some outstaffing firms), where companies and engineers have a pleasant experience, I guarantee you can scale it to a billion-dollar-sized business.

Appreciate this thought out response. The interview process is terrible on both ends. Like you said, is a billion dollar problem waiting to be solved.

> How about a single 4 hours coding session

How about saying no?

Reply on news.ycombinator.com