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

131–140 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#131

Post by est31 »

hemloc_io wrote: post #59
travisjungroth wrote: post #46

Earlier quoted context omitted.

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

lol yeah having been through these loops and training to do these loops it really seems like most people say they want to see “thought process”, but what they’re really looking for are the usual cues you see in all the prep info online. E.g. ask some clarifying questions before coding, write or suggest a brute force, and then write an optimized algo.

Without clarifying questions, often you assume something about the problem that's not actually the case. And a brute force solution is often very useful to learn more about the problem domain. Personally I really like doing a bad solution before a better one. Especially in the setting where it's not completely whiteboard, so I have the ability to run and test my code, then having a brute force solution around to debug the problem is useful.

Re: An Algorithm for Passing Programming Interviews (2020)

#132

Post by [deleted] »

thaumasiotes wrote: post #130
benlivengood wrote: post #110

Earlier quoted context omitted.

I've interviewed folks for FAANG roles. If you know how to solve the problem already, just tell the interviewer up front. Either they have another question or they will go deeper into a discussion about why and how you solved it the way you did, testing it, other approaches and why they are or are not good tradeoffs, etc. It's pretty obvious to interviewers if you've solved a problem before, and we appreciate the hon…

> Interviews are not adversarial I'm struggling to imagine a definition of "adversarial" that would make this true. You have two parties with conflicting goals.

[deleted]

Re: An Algorithm for Passing Programming Interviews (2020)

#134

Post by cleverwebble »

o10449366 wrote: post #95
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…

No, if you really want to game it you sign up for membership on Chinese forums where people post the questions word for word minutes after completing the interview. That or work exclusively with private recruiters that tell you the questions verbatim because they have a vested interest in you passing. Interview questions don't rotate that frequently, especially for smaller companies or more specialized roles, and a $…

As an interviewer, this is so incredibly frustrating - we don't change our questions often and because of that the questions and answers are all over these forums. With that said, it is incredibly easy to spot someone cheating - they often write the most perfect optimal solution from start to finish, helper functions first, often with the same function names as the forums themselves. The trick I've learned is to ask "why" - "why did you decide to use a linked list for this problem?" - the real cheaters often freeze up and can't give an explanation at all. It's rare, but still too common.

If you've seen the question/answer before just say so! I will totally appreciate the honesty and it goes a long way.

Re: An Algorithm for Passing Programming Interviews (2020)

#135

Post by hailwren »

shp0ngle wrote: post #133

What kind of hash table is O(1)? Or did I forgot everything from university already? You cannot have a general O(1) hash Well maybe in best case/average case, when you design the hash space big enough. Ugh I really did forgot everything.

The trick with O and hash tables is to remember that they're amortized O(1). Imagine a bag with the cost of resizing sitting inside it. Then, spread the cost across all inserts. There are always more inserts than the cost of resizing, so you end up w/ amortized O(1).

Re: An Algorithm for Passing Programming Interviews (2020)

#136

Post by esyir »

vanusa wrote: post #44
avl999 wrote: post #19

Earlier quoted context omitted.

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

>As do in-depth technical discussions about ... just about any subject the candidate claims to know about.

Having attempted to do this after reading all the HN screeds, I found that this failed horribly. You'll find a large number of people who seemingly know the theory, but can't execute worth a damn. They can happily talk on and on about normalization, regularization, imbalanced datasets and so on. Then they fail fizzbuzz.

I then put the programming screen first.

Re: An Algorithm for Passing Programming Interviews (2020)

#137

Post by vlovich123 »

shp0ngle wrote: post #133

What kind of hash table is O(1)? Or did I forgot everything from university already? You cannot have a general O(1) hash Well maybe in best case/average case, when you design the hash space big enough. Ugh I really did forgot everything.

Not sure I understand your concern. Are you asking about worst case? All hash tables I believe are O(n) worst case because of the possibility of collisions (or the need to resize in the case of an insert). Most people talk about amortized performance though (ie when you are successful at reducing the likelihood of worst case to a rare event). Amortized time is obviously dangerous if you’re in a real-time system (eg games) where it’ll manifest as stuttering or latency spikes or potentially even worse if you’re having to respond to hardware events in a timely manner for proper operation.

Re: An Algorithm for Passing Programming Interviews (2020)

#138

Post by renewiltord »

fermentation wrote: post #119
o10449366 wrote: post #107

Earlier quoted context omitted.

1point3acres is the most prolific, but there are many others.

Wow there seems to be an absolutely massive amount of useful information, maybe I should learn how to read it!

Google translate is sufficient. They’ll do it pretty carefully, complete with “pretend you get stuck at this specific point and if you get asked why to use a hashmap, act baffled for a moment, and then say X”

Re: An Algorithm for Passing Programming Interviews (2020)

#139

Post by Lamad123 »

kadoban wrote: post #74
netizen-936824 wrote: post #66

Earlier quoted context omitted.

Why would you want to seem like you're struggling?

The interviewers are ideally trying to get a sense of how you think through problems, not just that you can spit out an answer you know. At least that's what they say.

What if you happen to be an unlucky genius like J. von Neumann or something?

Re: An Algorithm for Passing Programming Interviews (2020)

#140

Post by xkgt »

kache_ wrote: post #71
diehunde wrote: post #48

Earlier quoted context omitted.

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.

When gaming it is just passing by studying, a repeatable process that anyone (with a CS degree) can do, just means the interview process is quite well designed. The interview process is a test of endurance, not intelligence. And it should be exactly that, since software engineering is mostly an exercise of endurance and focus. Every time a friend of mine QQs about failing a FANG interview, I give them the study presc…

I felt the same when I failed a leetcode interview. The reason behind my annoyance was that I had spent considerable amount of time over the past few years improving my skills in the areas I thought mattered (practicing TDD, design patterns,learning FP etc.,) I felt disappointed when none of these mattered compared to an artificial set of challenges setup in an unreal environment.

I can't say for sure that such challenges (array manipulation, backtracking etc.,) are not typical for a software job but I know that they aren't relevant for my line of work. Even if they are, the challenge of solving problems in a live coding session is not the same for all. Different people need different settings to perform or excel.

But now I am committing myself to leetcode and getting better at it, but it has become one among hundred other things I want to get good at. At some point of time, I will feel the burnout. But I sincerely hope the acquired skills are useful in my professional setting.

Post reply on HN