Comment by gwbas1c | Hacker News Reader

Comment by gwbas1c | Hacker News Reader

Parent Full thread

One thing about feedback: Too much feedback helps candidates game the system. This ultimately leads to bad hires, who end up getting fired. It hurts the process overall.

When interviewing with a good interviewer, he (or she) knows that whiteboard sessions / tests / projects are just hypothetical situations. If I throw an unfamiliar API in front of you, and you ask certain wrong questions, I know you're not going to work out. If you "get it" and can move forward, I know you're going to be able to learn all the weirdo stuff that you need to learn in order to do the job.

But, something I learned when I was in a similar situation: Companies that demand a LOT of upfront, grueling time in the interview process should be avoided. Once a call drags out beyond 45 minutes, or the coding test is just too time consuming, it's time to walk away.

Regarding whiteboarding, if the candidate argues with me about why we're using a particular API, I pretty much reject the candidate. (No, we can't use the new threading API, I want to see how you can learn this API. No, we can't use an ORM, I want to make sure that you understand how to use a database.)

These all seem like highly subjective criteria, which is the whole problem with the way hiring works in first place.

You might think it's subjective, but it's more like people arguing over whether it's a 6 or a 9. There's only one right answer.

In this case, I'm trying to filter out the morons, and people who can't disagree and commit. The idiots who argue with me that we should use a different API (for the interview question) get rejected immediately. The actual programming question is pretty mindless and any competent software engineer should be able to figure it out in under 10 minutes.

But the bigger reason is that in an engineering situation, people who argue over subjective things often times just waste everybody's time. Certain decisions were made and there is really no good reason to go back and revisit them.

> Regarding whiteboarding, if the candidate argues with me about why we're using a particular API, I pretty much reject the candidate. (No, we can't use the new threading API, I want to see how you can learn this API. No, we can't use an ORM, I want to make sure that you understand how to use a database.)

YUCK. One of the first things I will do when presented with a technical scenario is start questioning the problem's parameters, including API choice.

Interviewer: "Show me how you'd store a list of items in C++." Me: "Well, depending on the expected usage pattern I'd reach for one of the standard library's containers like std::list since it is time tested, robust, and comes with the compiler." Interviewer: "No, er, I mean if you don't have std::list... I want to know you can implement something from scratch." Me: "Am I really going to be working on a project without the language's library?? You generally don't want someone's hand-rolled linked list in production code."

I guess not wanting to waste the company's time re-implementing a wheel makes me a bad candidate.

I've tried that a couple of times. Of course it was a bad idea. The same as honestly answering questions. When I managed to get a nice job, it turned out that they also hired people for upper positions - who couldn't program, didn't know more than one language... and I still have no idea how they passed such a whiteboard test.

I've been forced to implement atoi and itoa functions in interviews, and albeit I agree with you that it's silly, I think they are just looking for a positive attitude.

I try to hype myself up with a "thank you sir may I have another" once I get through solving what I think is a silly question.

I remember being asked to solve a linked list problem with callbacks in JS where a service returned a Node and the API call to the next node in a list.

I had to just build a function to traverse the async list - I'd have wanted to just redesign that API, but instead I had to solve their silly problem.

I got the job, and it was all due to forcing myself to have a positive attitude and being happy to solve the problems vs questioning why one would ask it.

That...sounds absolutely dreadful. I'm happy for you but that doesn't sound like my cup of tea.

I think it just happens when younger folks do the interviewing, they don't know how to interview so they grasp for what they know.

Just seems that every big firm does it. Recently I had a take-home assignment - spend like a week at night working on it only to be kind of insulted by the folks who interviewed me. They didn't even spend 5 whole minutes looking over my work. I was far more frustrated with that than I was being asked to implement a Linked List in front of someone on the spot.

Reply on news.ycombinator.com