Live data from Hacker News

How to solve a hard programming interview question

dailycodingproblem.com

41–50 of 84 posts

Re: How to solve a hard programming interview question

#41

> I often find it’s not enough to just be able to solve the question; you really need to vocalize your thought process. I interview candidates regularly, and I can't overstate how important this is. If I ask you a hard interview question, and you sit silently for 10 minutes and then write out a perfect solution on the board without any discussion of how you got there, all I've learned is that you knew the answer. I h…

On the other hand, if you're cargo-culting interview practices from third-hand accounts of what BigCo tech companies do, you've demonstrated that you're probably not someone I want to work for. So it evens out!

You are the one making an assumption that the GP is parroting BigCo tech company interviews.

Re: How to solve a hard programming interview question

#42
post #38

I tend to find problems like this one, where the brute force solution is straightforward and then you can improve it by using a special data structure, easy. The ones I struggle with are the puzzle-like ones, where solving the problem depends on having some single flash of insight.

Conversely, if you just happen to know the answer because you saw it before, it feels a little bit like cheating. Quite honestly, I wonder how useful those kind of questions are to test someone's capacity to do the job.

Re: How to solve a hard programming interview question

#43

Hey Lawrence, might wanna point out that the result should be sorted too. Currently, that is not listed as a requirement.

Yeah, I was reading through and when he talked about the output being sorted it jumped out at me as a "Wait, what? No, probably not" thing. Perhaps his definition of "merge" is different from mine.

Even for his example I don't believe it's correct - he comes out with 10, 12, 15, 15, 17, 20 but I believe if it's basically zipping the lists I'd expect it to be 10, 12, 17, 15, 15, 20.

Re: How to solve a hard programming interview question

#44
post #39

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.

strong and silent is fine, as long as they are on the same page as you and you as them. It might take magic to do that. Communicating effectively is an important thing to avoid wasting time in red herrings.

Re: How to solve a hard programming interview question

#45
IMO, the first thing one needs to do in order to be high functioning with challenge is take the mindset that it is ok to underperform in an interview session and not get a particular job. Taking the stress out and focusing on clarity of deep thought helps almost everyone in almost all situations (I hesitate to say everyone since some people do thrive under pressure).

It is one thing to read disciplined approaches to solving a problem - it is another thing to control oneself while under strong emotional states.

Re: How to solve a hard programming interview question

#46
post #32

Am I missing something, or couldn't you just merge the lists like you would in merge sort? Begin with a pointer at the start of each list, find the minimum of the elements being pointed at and increment that pointer, until all pointers are at the end of their respective lists. You could possibly even do it in place. That was my first thought anyway.

It can be done on O(nk log k) if you always merge two shortest list. If all the lists have length k initially it can be easily done with couple of loops as all the lists will have the same length - n in the beginning, 2n after fist iteration, 4n after second.

Here is a quick implementation https://gist.github.com/karliss/ebc27b0b2baa3e6fc0f50fadda73...

Re: How to solve a hard programming interview question

#47

> I often find it’s not enough to just be able to solve the question; you really need to vocalize your thought process. I interview candidates regularly, and I can't overstate how important this is. If I ask you a hard interview question, and you sit silently for 10 minutes and then write out a perfect solution on the board without any discussion of how you got there, all I've learned is that you knew the answer. I h…

There are other thinking styles beside verbal. You're basically throwing out a large portion of candidates, including very talented ones (as having visual/logical thinking style comes with its own perks, sometimes very valuable).

Re: How to solve a hard programming interview question

#48
post #33
post #21

A systematic approach like this or others (Gayle Laakmann Macdowell’s BUD) seem to reduce the risk of underperforming, but I haven’t had success with it. Instead, problem identification has been most helpful to me. The approaches for solving Dynamic Programming problems are different than those that require a fundamental data structure (like a heap). Recognizing the heart of the problem is harder, probably what the i…

Care to elaborate how do you go about problem identification?

Hm, here is an example:

// 1. Explore the possibility of a recurrence relation. If the problem can be solved as a function of sub problems, then candidate techniques are DP, backtracking, greedy, and divide/conquer

// 1a. Explore DP. If it’s DP, then optimal solutions of its subproblems are all that’s necessary. Confirm that subproblems are repeated so that I can reason for memoization and later leave room for a bottom up implementation.

// 1b. Explore backtracking. If it’s a backtracking problem, then I should be able to test for the viability of a partial solution quickly.

...and so on

Re: How to solve a hard programming interview question

#49
post #33
post #21

A systematic approach like this or others (Gayle Laakmann Macdowell’s BUD) seem to reduce the risk of underperforming, but I haven’t had success with it. Instead, problem identification has been most helpful to me. The approaches for solving Dynamic Programming problems are different than those that require a fundamental data structure (like a heap). Recognizing the heart of the problem is harder, probably what the i…

Care to elaborate how do you go about problem identification?

Solve problems. Hopefully, after solving a problem several times, you'll be able to recognize it.

Re: How to solve a hard programming interview question

#50

Earlier quoted context omitted.

On the other hand, if you're cargo-culting interview practices from third-hand accounts of what BigCo tech companies do, you've demonstrated that you're probably not someone I want to work for. So it evens out!

You are the one making an assumption that the GP is parroting BigCo tech company interviews.

Their comment referred to a hard problem with a solution written on the "board".

Smells like cargo-culting of BigCo whiteboard interviews to me.

Post reply on HN