> 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!
How to solve a hard programming interview question
41–50 of 84 posts
Re: How to solve a hard programming interview question
#42I 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.
Re: How to solve a hard programming interview question
#43Hey Lawrence, might wanna point out that the result should be sorted too. Currently, that is not listed as a requirement.
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
#44Earlier 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.
Re: How to solve a hard programming interview question
#45It 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
#46Am 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.
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…
Re: How to solve a hard programming interview question
#48A 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?
// 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
#49A 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?
Re: How to solve a hard programming interview question
#50Earlier 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.
Smells like cargo-culting of BigCo whiteboard interviews to me.