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

21–30 of 84 posts

Re: How to solve a hard programming interview question

#21

Post by reyg »

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 interviewer is really testing for, and in my opinion differentiates oneself better than following a step by step guide.

Re: How to solve a hard programming interview question

#24

Post by CobrastanJorji »

mattm wrote: post #19
CobrastanJorji wrote: post #17

> 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…

Does it really matter though? What if I solve problems by eating a piece of toast? There's really no way you can understand how someone else thinks in an hour. All you're really going to look for is "Does this person think the same way that I do?"

It matters a lot! If I could reduce your toast-based problem solving technique to something we could implement on silicon and gluten, imagine the applications!

Also yes, hearing you reason also matters a lot. I need to see how you refine my lousy problem statement into a solvable problem. Do you make a lot of assumptions about the problem without noticing? Can you consider alternatives or do you get completely stuck on the first solution you encounter? Can you explain a technical idea to someone reasonably clearly and concisely?

I don't need you to be like me, but if we can't brainstorm together about technical problems, we're going to have trouble working together as a team.

Re: How to solve a hard programming interview question

#25

Post by zaptheimpaler »

CobrastanJorji wrote: post #17

> 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…

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.

Re: How to solve a hard programming interview question

#26

Post by celdon25 »

This is not new advice. People have been giving this same advice for years. And frankly, people are sick of hearing it, and it borders on patronizing.

However, that's not to say that it's a bad idea to aim for. The problem with this kind of advice though, is it only tells you what proficiency to aim for, and not how to get there.

People only have so much brainpower to use during an interview. If you have to use every ounce of it in order to solve a "hard" problem in the first place, then diverting some of it to explaining things will distract the candidate.

The real secret here is to make sure that you have that extra brainpower, so that you do not have to expend your brain's full capacity while solving that hard problem. So the first step is to practice interview problems until they're second nature. The second step is to practice doing those same problems, while explaining a thought process. Once that is second nature, you can further practice by throwing in unique types of explanations, or using the opportunity to make the conversation more interesting, to make the interviewer more impressed.

I hope that some readers out there understand as well as I do, that the entire job interview process is a farce, and selects for sales skills more than it does for engineering skills. The pervasive idea that you have to explain your work only serves those who learn the type of methodology I described above. There are many brilliant candidates out there who believe that it would be a huge waste of their time to refine these skills, instead of engineering skills or other things that they may want to learn. After all, it would only serve to increase your odds of getting your foot in the door at those companies that use such irrational means to select their employees, and why would a brilliant engineer want to join such a team?

This is the ultimate tragedy for (some, but not all) who are passionate about engineering and rationality, but not necessarily passionate about money. I think we can do better, folks.

Re: How to solve a hard programming interview question

#27

Post by ToJans »

With all do respect, I think the author is missing an important point: he is talking about communication, but he seems to be the only one talking... IMHO you should first figure out why it's needed, and optimise for it's use case. F.e. if it's only used once a year and a simple merge+sort takes half an hour, it wouldn't be worth implementing it yourself.

IME good (10x?) developers are way more efficient because they reason from first principles: don't start from the solution space, but from the problem space, and optimise based on constraints and requirements.

Re: How to solve a hard programming interview question

#28

Post by warent »

Vendan wrote: post #15
warent wrote: post #13

In my experience, when interviewers do grade based on algorithmic performance, they want to see low time complexity, and care much less about space complexity. In this example, you could actually accomplish the solution in linear time using a hashmap and keeping track of the min/max vals; O(max-min) Something like... let map = {}; let minVal = null; let maxVal = null; for (let a of arrays) { for (let v of a) { if (mi…

But you have to quantify the max-min, cause it's quite easy for the data to make that way more expensive then "merge then sort". I.e., run your algo on [[0, 1000000000], [1, 2]]

Good point :)

Perhaps add a check to see if min-max is greater than K*N, and if so then use alternative method (e.g. merge sort)

Re: How to solve a hard programming interview question

#29

Post by virgilp »

mattm wrote: post #19
CobrastanJorji wrote: post #17

> 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…

Does it really matter though? What if I solve problems by eating a piece of toast? There's really no way you can understand how someone else thinks in an hour. All you're really going to look for is "Does this person think the same way that I do?"

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 suspicious if you do. I don't have half an hour to sit on a single problem - that's not the purpose of the interview.

Re: How to solve a hard programming interview question

#30

Post by myegorov »

warent wrote: post #28
Vendan wrote: post #15

Earlier quoted context omitted.

But you have to quantify the max-min, cause it's quite easy for the data to make that way more expensive then "merge then sort". I.e., run your algo on [[0, 1000000000], [1, 2]]

Good point :) Perhaps add a check to see if min-max is greater than K*N, and if so then use alternative method (e.g. merge sort)

What about continuous data (real numbers, strings)? Your approach has rather limited application. On a different note, merge/sort approach (O(n log n)) is in general less efficient than the heap approach (O(n log a)), and may be impractical or wasteful of space (O(n) vs O(a)) if dealing with realtime data for example.
Post reply on HN