An Algorithm for Passing Programming Interviews (2020) • Hacker News Board

Re: An Algorithm for Passing Programming Interviews (2020)

#141

Post by jsiaajdsdaa » Mon, Jan 03, 2022, 4:20 AM UTC

renewiltord wrote: post #138

fermentation wrote: post #119

Earlier quoted context omitted.

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”

As someone who has studied and passed before in this manner, and is now an interviewer, I have a simple solution that other companies should follow:

for at least one round of interviewing, let me (the interviewer) use my own custom question, where the goal is not so much to solve it but rather to reason outloud collaboratively about many different aspects of the question.

I like to use 3d graphics as a domain that candidates most likely havent seen before, but sufficiently motivated/smart ones can hold their own in. If someone doesn't quickly and intuitively grasp that a shape is a collection of faces, and a face is a collection of points, and a point is a collection of vertices, I'm not sure that they have what I am personally looking for (even though we dont do any 3d graphics in our project)

Re: An Algorithm for Passing Programming Interviews (2020)

#142

Post by Drew_ » Mon, Jan 03, 2022, 4:22 AM UTC

benlivengood wrote: post #110

mrfusion wrote: post #56

Earlier quoted context omitted.

I’ve gotten interview questions I’d recently solved and my problem was it was too easy. I had trouble acting like it was the right amount of struggle. Is there a trick for that?

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…

Be honest: a candidate that works through a seemingly novel problem correctly is getting a much better review than another candidate that admitted they've done the question before and breezes through it. And this is assuming your interview round doesn't get thrown out entirely to begin with.

Re: An Algorithm for Passing Programming Interviews (2020)

#143

Post by Aeolun » Mon, Jan 03, 2022, 4:22 AM UTC

cleverwebble wrote: post #134

o10449366 wrote: post #95

Earlier quoted context omitted.

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…

> If you've seen the question/answer before just say so!

In my experience failing to answer the alternative question you give me has (on average) a much more negative impact than pretending I don’t know your question (especially when I can explain it).

Re: An Algorithm for Passing Programming Interviews (2020)

#144

Post by avl999 » Mon, Jan 03, 2022, 4:28 AM UTC

malisper wrote: post #32

avl999 wrote: post #12

I would also add heaps/priority queues to this list. They don't come up as often as HashTables/LinkedLists but come up often enough. If you wanna be thorough (esp if you are applying at companies known for harder interviews) I would add practicing backtracking problems where you are doing a full exhaustive search of the problem space as well (often O(k^n) or O(n!) complexity). Yes these are often mostly just DFS + Re…

There's a specific reason I didn't mention priority queues in the post. In most cases, anything you can do with a heap you can do with a binary tree instead! A binary tree has O(log(n)) insert and deletion which is the same as a traditional heap. The only advantage a traditional heap has is you can construct a heap in O(n) time whereas a binary tree takes O(nlog(n)) time. Of course there are even more niche data stru…

That's reasonable, makes a lot of sense.

Re: An Algorithm for Passing Programming Interviews (2020)

#145

Post by heywintermute » Mon, Jan 03, 2022, 4:28 AM UTC

cleverwebble wrote: post #134

o10449366 wrote: post #95

Earlier quoted context omitted.

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…

>If you've seen the question/answer before just say so!

In reality no one will do this though. There is way to much of an incentive on the candidate side to lie and work through as if they haven't seen it before.

Re: An Algorithm for Passing Programming Interviews (2020)

#146

Post by abswest » Mon, Jan 03, 2022, 4:29 AM UTC

cleverwebble wrote: post #134

o10449366 wrote: post #95

Earlier quoted context omitted.

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…

> If you've seen the question/answer before just say so!

I did that once at FAANG interview, instead of honesty credits I felt like the interviewer just got annoyed by having to come up with another question.

Re: An Algorithm for Passing Programming Interviews (2020)

#147

Post by kadoban » Mon, Jan 03, 2022, 4:32 AM UTC

Lamad123 wrote: post #139

kadoban wrote: post #74

Earlier quoted context omitted.

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?

You still should need to ask clarifying questions, because the specification of many problems is intentionally incomplete.

Beyond that though, you can just be honest and say you know a problem and they can either pick another or just talk about it anyway.

Re: An Algorithm for Passing Programming Interviews (2020)

#148

Post by kristopolous » Mon, Jan 03, 2022, 4:35 AM UTC

diehunde wrote: post #48

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.

If somebody has been doing something for 20 years and an assessment test can yield dramatically different results with 20 minutes of preparation, then the assessment test is total bullshit. It's going to yield a false characterization and is fundamentally garbage input

I know that's pretty strongly stated and it matches the strength of my convictions here. I've tried many methods. Asking someone to figure out something is a sliding window is a garbage test

Re: An Algorithm for Passing Programming Interviews (2020)

#149

Post by creato » Mon, Jan 03, 2022, 4:36 AM UTC

stathibus wrote: post #111

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…

A good way to avoid this conundrum is to ask questions that are worth solving in real life. If the candidate breezes through the discussion because they've actually had to solve the problem before , then their victory is well earned. If on the other hand its an academic question in the same vein as the data structures or algorithms puzzles you find on $interviewprepforum, then the fact that they've solved it before t…

I don't think there's much difference either way. In both cases, a candidate gained a large advantage in a way that tells you very little about their ability.

I think this is why contrived questions gained popularity in the first place - they eliminated noise due to candidates randomly having solved similar problems before (that and "real life" problems usually can't be explained and solved in 1 hour).

Re: An Algorithm for Passing Programming Interviews (2020)

#150

Post by ironman1478 » Mon, Jan 03, 2022, 4:37 AM UTC

ldjkfkdsjnv wrote: post #10

Before people start complaining about leetcode and how it doesnt exemplify skills: its a proxy for a combination of: intelligence and how hard you are willing to study the computer science knowledge shown is just a bonus EDIT: One last thing to throw in, its pretty clear that theres a correlation between the top software companies and how hard their leetcode interviews are. You can claim all you want it doesnt work,…

They are known for the highest paying salaries + providing stability relative to a high paying start-up. They aren't known for the 'best' software (how do you even quantify that) and Google specifically has a reputation for not maintaining software and letting products die. Generally not a hallmark of good software.

Also, the computer science shown asked in these questions is a very subset of computer science. I've never been asked an image processing question, non-trivial concurrency/parallelism, or numerical optimization questions (all things I've actually used in my job, I've never had to do strange linked list manipulations unfortunately). Those are all CS or CS adjacent but never get asked in my experience. I've also never been asked low level networking questions.

Instead it's just tricky graph questions and list/tree manipulation questions (that aren't that hard, but they are incredibly boring). CS is such a huge field, it's truly baffling that the technical interview questions at Google and Facebook are so miopic.