Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to solve a hard programming interview question

dailycodingproblem.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: How to solve a hard programming interview question

#71

Post by Double_a_92 »

twelve40 wrote: post #61
virgilp wrote: post #29

Earlier quoted context omitted.

I concur - it does matter. I'm not looking for "thinks the same way that I do" - I'm looking for "thinks". And specifically, how. I want to see you evaluate & discard ideas. I want to know that you quickly identified the "brute force"solution and discarded it, rather than sitting there for 10 minutes, not knowing how to even start. You must realize, if the problem is hard, I don't even expect you to solve it. You're…

and that's what makes it ridiculous. In my whole career I have not been forced to vocalize hard problems on a whiteboard in one hour, getting judged for how good of a dog and pony show I put on with "evaluating and discarding ideas" on the fly, out loud, in an interrogation setup. This is so artificial. Not even close to how real teams work. My best ideas start to really form after thinking about a hard problem for d…

That's why I think that interview challenges should be "easy". E.g. something like "Make a number guessing game."

1. It's easy enough so you can talk and explain while solving it.

2. It can show your ability to split problems into smaller subproblems.

3. It maybe filters people that just memorize a bunch of solutions, since it's open how exactly you solve it.

Re: How to solve a hard programming interview question

#72

Post by virgilp »

Scarblac wrote: post #67
virgilp wrote: post #29

Earlier quoted context omitted.

I concur - it does matter. I'm not looking for "thinks the same way that I do" - I'm looking for "thinks". And specifically, how. I want to see you evaluate & discard ideas. I want to know that you quickly identified the "brute force"solution and discarded it, rather than sitting there for 10 minutes, not knowing how to even start. You must realize, if the problem is hard, I don't even expect you to solve it. You're…

And the candidate has no way of knowing what you expect, he's just been given a problem to solve. One time I was rejected for not identifying and discarding some particularly stupid attempt at doing something (it involved assuming that it was safe to trust input coming to the server over HTTP), but I have explained to people not to do that so many times that I really don't consider doing things that way in the first…

That's why he can ask if he doesn't know what we expect. Silence is the worst option - we're there to form an impression on you (an accurate one, hopefully) - if you just sit there silently, it won't help us.

(I actually ask the candidate to talk us through his thinking process if I see him sitting there; I start asking questions if he still refuses. I realize that it's an artificial setting, where many people feel pressure to "perform well" rather than just be themselves; unfortunately, I have found no better solution to hiring, that would make the interview unnecessary in all situations)

Re: How to solve a hard programming interview question

#73

Post by virgilp »

Double_a_92 wrote: post #71
twelve40 wrote: post #61

Earlier quoted context omitted.

and that's what makes it ridiculous. In my whole career I have not been forced to vocalize hard problems on a whiteboard in one hour, getting judged for how good of a dog and pony show I put on with "evaluating and discarding ideas" on the fly, out loud, in an interrogation setup. This is so artificial. Not even close to how real teams work. My best ideas start to really form after thinking about a hard problem for d…

That's why I think that interview challenges should be "easy". E.g. something like "Make a number guessing game." 1. It's easy enough so you can talk and explain while solving it. 2. It can show your ability to split problems into smaller subproblems. 3. It maybe filters people that just memorize a bunch of solutions, since it's open how exactly you solve it.

Depends what you're testing for. If I'm testing for problem-solving skills, I will pick increasingly harder problems, until you can't solve them. I will judge you on how well you performed on the one you couldn't solve.

Re: How to solve a hard programming interview question

#74

Post by Double_a_92 »

Why are those interview questions mostly random algorithms?

Wouldn't it be more sensible to ask for design patterns? At least you can use them in real life.

Or refactoring patterns. Like give them a page of shitty code and ask them to make it nice.

Forcing people to memorize obscure algorithms and solve them on a whiteboard seems like the worst possible solution. Unless you are really looking for some expert on algorithms.

Re: How to solve a hard programming interview question

#75

Post by Double_a_92 »

virgilp wrote: post #73
Double_a_92 wrote: post #71

Earlier quoted context omitted.

That's why I think that interview challenges should be "easy". E.g. something like "Make a number guessing game." 1. It's easy enough so you can talk and explain while solving it. 2. It can show your ability to split problems into smaller subproblems. 3. It maybe filters people that just memorize a bunch of solutions, since it's open how exactly you solve it.

Depends what you're testing for. If I'm testing for problem-solving skills, I will pick increasingly harder problems, until you can't solve them. I will judge you on how well you performed on the one you couldn't solve.

The problem is that you can't just solve the hard problems (e.g. those from hackerrack) like that by just thinking about it for some time (it would probably need hours or days of research).

You just have to learn and remember some obscure algorithm to solve them. That just filter for "unexperienced" people that have enough time to actually learn a lot of algorithms by heart.

I.e. that would be fresh graduates. But then you could just look at their uni grades, if you want people who are good at learning.

Re: How to solve a hard programming interview question

#76

Post by blt »

speedplane wrote: post #60
blt wrote: post #54

Earlier quoted context omitted.

Yeah, I do not think they are very useful. I know a lot of people, myself included, who perform worse than their true ability during interviews. It can be an anxiety thing, but also some people just prefer to take their time and deliver solutions in writing vs. work things out in real time on a whiteboard. I think a good alternative is to give the candidate a nontrivial project that should take around 8 hours, and pa…

That's better, but probably still not exactly indicative of real-world work... so much of on-the-job work is teamwork. Perhaps you could interview a group of candidates together and as a group assign a project that you know no one person could finish on their own, but would be manageable broken up. The people that form groups and work well together could presumably bubble up.

But then if one candidate is an asshole, they ruin it for everyone...

Re: How to solve a hard programming interview question

#77

Post by Juliate »

mplewis wrote: post #39
zaptheimpaler wrote: post #25

Earlier quoted context omitted.

Problem solving is pattern matching/recognition. Many of us solve problems wordlessly in our head with no explainable "thought process". After solving it, i can explain quite clearly but not during. One does NOT need to be able to simultaneously solve & explain how you solve an abstract algorithm problem to be a good engineer either. Dont kid yourself its only an "important skill" because you like to test for it.

Part of hiring is finding out if someone can work well with a team. Lots of teams need everyone to be able to communicate well during collaborative problem solving sessions. I've worked with the strong, silent type of coworker who has a solution in their head. But because they don't vocalize what they're thinking, I can't participate or help. That's not what I'm looking for in a good engineer and a good coworker.

It's not "good" versus "bad" engineer/coworker. It's a different way of functioning.

Some people (I'd guess introverts, although I'm not sure) need to internalize to think and can't interact much at this point. Some can think and discuss at the same time.

From these two sets of people, some can afterward verbally explain the reasoning and the solution, some can't. Some may also only require a context warm-up.

That makes 4 sets of people already.

"Technical" phone interviews that screen candidates that can solve whatever riddle, filter for a very specific set of people. Not necessarily the best in any context. But a specific set that works for them. Just admit/accept it.

Re: How to solve a hard programming interview question

#78

Post by virgilp »

Double_a_92 wrote: post #75
virgilp wrote: post #73

Earlier quoted context omitted.

Depends what you're testing for. If I'm testing for problem-solving skills, I will pick increasingly harder problems, until you can't solve them. I will judge you on how well you performed on the one you couldn't solve.

The problem is that you can't just solve the hard problems (e.g. those from hackerrack) like that by just thinking about it for some time (it would probably need hours or days of research). You just have to learn and remember some obscure algorithm to solve them. That just filter for "unexperienced" people that have enough time to actually learn a lot of algorithms by heart. I.e. that would be fresh graduates. But th…

> The problem is that you can't just solve the hard problems

Which is why I said I don't expect them to solve the problem, I'm interested to see:

- the general thought process - whether the candidate is inclined to jump at the solution or clarify the problem (neither approach is "disqualifying", btw! but for a senior position I do kinda' expect the candidate to recognize when a specification is incomplete, and I will provide increasingly ambiguous problems/questions to see when he stops making assumptions) - that the candidate is capable to identify some "leads"/ subproblems that need to be solved first/ to reduce the problem to a different one/ etc.

> But then you could just look at their uni grades, if you want people who are good at learning.

If only it was so simple... some people are good at learning, they just don't have good grades (e.g. they have to work to support themselves and don't care much about some grades); while others are good at getting generally good grades without actually being good learners (extreme example: cheaters).

Re: How to solve a hard programming interview question

#79

Post by oldandtired »

The first question one should be asking is:

What relevance does the question actually have to do with the job in question?

The second question to ask is:

Will this be of benefit for the end-user population?

I find that I have no wish to join an IT related part of the organisation when it becomes obvious during the interview that they have no interest in serving the end-user community. They rather want to dictate what the end-user will be using, irrespective of all end-user needs.

So for many years, I have worked on behalf of the end-user to get them to a point that they can do their actual jobs. With the advent of large corporate IT systems, one has seen an increasing amount of null work being required of the company staff (its purpose is to feed the egos of management, instead of actually getting things done). What was that movie??

If what you are doing doesn't enable the end-user to be more productive then what on earth are you doing? Interviewers who are not focussed on building teams to solve end-user problems are failing in their jobs.

End rant.

Re: How to solve a hard programming interview question

#80

Post by mattm »

virgilp wrote: post #72
Scarblac wrote: post #67

Earlier quoted context omitted.

And the candidate has no way of knowing what you expect, he's just been given a problem to solve. One time I was rejected for not identifying and discarding some particularly stupid attempt at doing something (it involved assuming that it was safe to trust input coming to the server over HTTP), but I have explained to people not to do that so many times that I really don't consider doing things that way in the first…

That's why he can ask if he doesn't know what we expect. Silence is the worst option - we're there to form an impression on you (an accurate one, hopefully) - if you just sit there silently, it won't help us. (I actually ask the candidate to talk us through his thinking process if I see him sitting there; I start asking questions if he still refuses. I realize that it's an artificial setting, where many people feel p…

Please be comfortable and be yourself...but we'll have you vocalize your thought process even though this is something you never do while working, you have no experience doing and it makes it tougher to think while you're talking.

If someone was a great coder but a mute, your process would weed them out.

Post reply on HN