Ask HN: Does it make sense for people to have to solve problems in interviews? | Hacker News Reader

Ask HN: Does it make sense for people to have to solve problems in interviews?

5 pointscodingclaws17 comments

Lately, I've been thinking that it doesn't really make sense for people to have to solve problems in interviews. I'm willing to do take homes or talk about past intricate problems I've solved. What do you think?

View on HN

This issue has been debated ad nauseam on HN, practically every week. No offense intended to the asker, but I'm not sure this question is useful, given the social context. Round N in an N-dless debate. The question adds nothing new to it, and no detail ("it doesn't really make sense").

I've read a lot of HN interviewing discussing, but I've never seen this specific question asked.

You question isn't really "does it make sense", you're just taking an opinion poll on what interview style people prefer.

I'd rather solve problems during the interview than do take homes.

You're saying it doesn't make sense to solve problems in interviews, but you're not saying why.

It makes a lot of sense to solve problems in interviews, the interviewer gets to see your thought process and it prevents cheating by getting someone else to solve the problem. Furthermore, unlike talking about past projects, the interviewer can compare the answers of different candidates on the same problem.

I think solving problems in an interview and not in an interview are two very different things. In other words, it seems to me there's a difference between solving a problem however I want vs. solving one on a phone or video call while someone is twiddling their thumbs. If anything, there's no room for subconscious thinking which I heavily rely on.

Also, sometimes I feel like a "monkey in a circus". Sometimes I want to say, "I'll solve your problem if you solve mine". Is power imbalance the right phrase?

As an Interviewer:

I think it's helpful, in order for me to understand the person I'm interviewing, to pair program on a problem together. I don't think it makes sense for them to LeetCode an algorithm in front of me; I think it makes sense for us to build a working API or an Async Worker. I need to know that you _know_ these things or at least know that _you can figure these things out_ and know how to _ask questions when you are stuck_.

As an Interviewee:

I won't do take-homes. I barely like having to do 1hr long interviews, there's no way I'm going to take 1hr+ of my time _outside of work and interviewing_ to do your toy problem _and then talk to you about it_. I would love to hang out, sling code together, and spend time nerding out for 1hr with people as an interview. In fact, I know that if the interview is a "let's code together" one that I'm pretty likely to get the job so I look forward to those types of interviews.

I would like to pair for an interview but I don't think I've ever done that across over 100 of them. It might be hard for me though, because I'm a generalist and often apply to jobs where I haven't used the stack recently.

I think: Yes. As long as the problem is representative of the types of problems that the candidate will be required to solve if hired for the job. Naturally the problems should be within the candidate's claimed areas of expertise.

I like to pose problems that have been solved a while back, but was the subject of some considerable debate. Given a whiteboard, I am more interested in how the candidate approaches the problem and the questions they ask, the concerns they raise. In other words, demonstrating a mature approach.

I don't think interview problem solving is a good barometer for a person's problem solving skills. For example, you can't use subconscious thinking. And the pressure is much greater (which can really change things).

I think it's useful to devise a problem solving exercise in order to assess reasoning and capacity of the candidate to think on their feet.

I don’t think it does make sense since some people may take a little more time to solve a problem well even if they’re more qualified.

Short answer: If done well, yes. It's usually not done well.

How do you catch liars?

There's other evidence that would indicate a successful past dev career.

Such as?

A portfolio. Maybe a detailed conversation about a past project. Perhaps a git log. Maybe some references. Maybe a convo about fundamental skills.

All can be faked no?

Reply on news.ycombinator.com