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

An Algorithm for Passing Programming Interviews (2020)

malisper.me

Post reply on HN
Print view View original

41–50 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#41

Post by travisjungroth »

dmurray wrote: post #24

There's a bit of a "draw the rest of the owl" thing going on here. If you have the experience to confidently eliminate the likely approaches that don't work, then you must know quite a bit about those approaches and their applications. And in particular, I'm not sure I can agree on eliminating recursion in the anagrams problem. He just says > Recursion – No way to apply recursion to the problem. but...there is? One p…

That's the nature of thought frameworks. You need to fill in the gaps yourself. It's still useful to have an organized approach. In my experience, people can know how well each technique would be suited to the task at hand if asked. But, they rarely consciously go through each technique they know and consider if it's the right approach. Most people would be well served to do this more often.

Btw, this is a big failing in interviewers who help. Asking the right questions (what data structure could you use here?) is incredibly helpful. So helpful that you're not testing them on a slow moving, relevant skill (structured thinking) but instead a fast moving, less relevant skill (what data structures do you know?). Bad move.

Re: An Algorithm for Passing Programming Interviews (2020)

#42

Post by malisper »

samspenc wrote: post #21

Good stuff. A couple of comments to the post: Rate limiter: I would probably use a hash table of this structure -- called[yyyy-mm-dd][hh-mm] and then increment the hashtable for that minute, for example, called[2022-01-02][22-01]++ and drop any entries for the last day at the end of the day. Post doesn't mention this, but one other common pattern I've seen requires a tree data structure, and those interview questions…

> Rate limiter: I would probably use a hash table of this structure -- called[yyyy-mm-dd][hh-mm] and then increment the hashtable for that minute, for example, called[2022-01-02][22-01]++ and drop any entries for the last day at the end of the day.

As Bradley said this implementation can be called more than 10 times within a 1 minute window. If it's called 9 times at the last second of one minute and 9 times at the start of the next minute, it will be called 18 times within a two second interval.

Re: An Algorithm for Passing Programming Interviews (2020)

#44

Post by vanusa »

avl999 wrote: post #19
hsavit1 wrote: post #11

Glad to hear that the software engineer selection method is determined by this very rigorous process of character assessment. No wonder why big corporations produce such amazing teams.

I am not gonna die on a hill defending these types of interviews but they are infinitely better than the alternatives. Alternatives are often subjective criteria like "culture fit" which can lead to nepotism/other types of biases or hiring being done by sorting resumes based on the prestige level of the college of the applicant and just running down the list from the top (which happens in other professions like law).…

Alternatives are often subjective criteria like "culture fit"

There's a vast territory of approaches that are neither leetcode hazing or culture fit tests. And which, while nuanced, are basically objective.

Work sample evaluations do quite well, for example. As do in-depth technical discussions about ... just about any subject the candidate claims to know about.

Neither of which have anything to do with "culture fit".

Re: An Algorithm for Passing Programming Interviews (2020)

#45

Post by Rebelgecko »

vanusa wrote: post #34
strstr wrote: post #13

Earlier quoted context omitted.

I’d turn that question back around at the candidate, unless it were for a junior candidate. I’ll give hints if the candidate is struggling, but I won’t just come out and tell them something like this. If they pushed me hard enough at the start, I would tell them and then fail them on the algorithms/reasoning component of the interview.

Yeah - why not just tell them? You know, like IRL. What this is supposedly about. Again, the question referred to the target performance, not the optimal performance.

When I implement something IRL (unless I'm implementing something from a paper or an algorithm that's well known), I typically can't just ask someone what the algorithmic complexity is. I have to determine if for myself.

Ed: to clarify a bit, in some cases the "non-optimal" solution is going to be the best one. And that's even before you start worrying about things like time/memory tradeoffs. When a candidate asks me questions along the lines of "which of the 2 input lists is bigger, what order of magnitude is the length, does XYZ fit in memory, etc", IMO it's a useful signal that shows they're aware of these tradeoffs.

Re: An Algorithm for Passing Programming Interviews (2020)

#46

Post by travisjungroth »

colechristensen wrote: post #16
kjgkjhfkjf wrote: post #3

Many interviewers ask candidates to explain their thinking. I don't think this dubious process of elimination would pass that test.

Right? When I’m interviewing I care most about the thought process and the ability to communicate in depth about something technical, the actual solution isn’t really that important at all.

This is the thought process. I use something very similar and have done well in interviews.

I found I did better in interviews when I showed my thinking less, or adapted it to the interviewer. Stating the things I'm not doing is useful, but too risky. Just hearing the words "linked list" in a problem that can't be solved with linked lists (even in the sentence "linked list doesn't seem to be right") startles some interviewers. A high enough percentage I don't want to roll that die six times during a round.

The silliest example is I like to work on problems by writing code. Yes, even if I don't understand the problem perfectly. Seeing some code helps clarify my thinking and I throw most of it away.

Freaks. People. Out.

Writing down some wrong line of code may as well be blasphemy. Strangely, not the case with comments. So my technique in interviews was to write comments that were as equivalent as possible to code and then convert it to regular code when I felt things were close enough. The biggest challenge in Python is not making it so similar that it becomes obvious what you're doing.

Re: An Algorithm for Passing Programming Interviews (2020)

#47

Post by henning »

arduinomancer wrote: post #5

Interviews are really a dumb game these days so if you want to really game it you can go with a statistical approach: * Practice questions by company on LeetCode, sort by frequency of last 6 months and work down the list, do maybe 75-100, the list updates once a week * Search for the company on the LeetCode forums and sort by most recent. If a question is not on LC yet it will likely get posted there, so you can get…

This is a great way to start off a business relationship with dishonesty and cynicism. Enjoy your career.

Re: An Algorithm for Passing Programming Interviews (2020)

#48

Post by diehunde »

arduinomancer wrote: post #5

Interviews are really a dumb game these days so if you want to really game it you can go with a statistical approach: * Practice questions by company on LeetCode, sort by frequency of last 6 months and work down the list, do maybe 75-100, the list updates once a week * Search for the company on the LeetCode forums and sort by most recent. If a question is not on LC yet it will likely get posted there, so you can get…

Many people say this. But the reality is that solving 100 LC questions and actually understand the solution enough to solve a variation of the problem is a lot of work. Especially if you are working full-time. I wouldn't call that "game it", just usual study and hard work.

Re: An Algorithm for Passing Programming Interviews (2020)

#49

Post by ThalesX »

henning wrote: post #47
arduinomancer wrote: post #5

Interviews are really a dumb game these days so if you want to really game it you can go with a statistical approach: * Practice questions by company on LeetCode, sort by frequency of last 6 months and work down the list, do maybe 75-100, the list updates once a week * Search for the company on the LeetCode forums and sort by most recent. If a question is not on LC yet it will likely get posted there, so you can get…

This is a great way to start off a business relationship with dishonesty and cynicism. Enjoy your career.

Can I have some of that ‘work through tens or hundreds of coding problems that are of no future relevance to me’ dishonesty and cynicism?
Post reply on HN