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

- what do you like doing?

- how are you as a person, a coworker

- are you able to ask for help?

- can you hold a conversation?

- how do you learn?

- describe a failure in your career and how it went from there

all this is for the interviewer and the interviewee to get to know each other each other and see if the candidate is a good fit for the company culture and values. If the recruitment lets in a narcissist or toxic person it will poison the well.



These would be perfect questions, if candidates didn't lie.

They do. All the time. More often than you'd think about something as trivial as "can you actually write code".

And so, you'll need to demonstrate your skills. Find a better way with an extremely low false positive rate, and you can make a fortune consulting and implementing that. It's not like anybody likes doing these interviews.


You don't need to ask "really hard Algorithm puzzles" to figure out whether they can actually write code. You can ask normally hard or even simple algorithm and have them implement it. If your company does object oriented, you can also ask them basic patterns. If you do functional, have them do little bit of that.

It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part.

That being said, asking logical puzzles is fine when you are hiring juniors you expect to train. The question with them is "is this kid smart enough to understand what I will teach" not "does this kid already knows everything". However even there, really hard algorithm is not something I would go for.


If you don't ask "really hard" questions[1], candidates instead complain because "any child can solve this" and feel not taken seriously. Somebody will always complain.

    "asking logical puzzles is fine"
No. NO. NO. That's the thing that isn't fine, because solving a logic puzzle relies on one critical insight. It's rolling the dice.

What you want is a question that has multiple answers, that's dirt easy, and where you can ramp up the difficulty to the moon if the candidate breezes through. These questions are hard to find, but they exist. They require investing some thought, so they're unfortunately not asked too often. But they work. (For small values of work. There is no good interview process)

[1] Somewhat hard. It's solvable in 45 minutes, it's not that hard.


> It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part.

Really? That's not how I read it. And when I asked OP, that's not how he responded. The examples of questions that he said he would ask had been stripped of any algorithm-related questions, or any questions that involve coding.


Neither serpix nor acroback answered again here, so it was someone else who responded.


I'm talking about serpix. When I asked him "if you don't thik that algorithm questions should be asked, then what should?" he replied with a list of pointless questions.

Then you said "it's really hard bit that's being criticized here, not the algorithm bit."

No, it's the algorithm bit that serpix was originally criticizing, as evidenced by the fact that when he replied to me he didn't include algorithm questions from the list of things that he would ask.


  > And so, you'll need to demonstrate your skills
Alas, the skills you are asked to demonstrate have very little to do with the actual skills required for the job you are interviewing for.


Isn't that just really vague and easy stuff that requires no knowledge of any kind?




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

Search: