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

Re: An Algorithm for Passing Programming Interviews (2020)

#81

Post by titanomachy » Mon, Jan 03, 2022, 1:50 AM UTC

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 don’t know if it’s as useful a signal as you imply. For me, it’s easy to be motivated studying leetcode: small, self-contained puzzles with just the right amount of challenge and immediate gratification. Actually doing a FAANG job can be a slog where it takes months to see results from your work.

I can get hired as a software engineer wherever, but I’m only mediocre at doing the job. I’m not the only person I know like this.

Re: An Algorithm for Passing Programming Interviews (2020)

#82

Post by austincheney » Mon, Jan 03, 2022, 1:51 AM UTC

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

In small companies or startups I have come to believe the quality and objectivity of the interview is a fair reflection of the maturity of the thought leaders at the company. I then use that assessment as a primary indicator to drop out.

As someone who has a current stable employment I have the freedom and flexibility to fail at numerous interviews with only minor frustration of time wasted. If I were out of a job and a bit more desperate I would just lie through my teeth on all elements that of a job interview except education and employment history like a super brown-nose narcissist. Since most all programming interviews are maximally subjective intentionally injected bias goes both ways and is easily applied.

Re: An Algorithm for Passing Programming Interviews (2020)

#83

Post by [deleted] » Mon, Jan 03, 2022, 1:52 AM UTC

malisper wrote: post #37

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.

The "algorithm" I wrote in this post is a formalized version of some problem solving techniques I picked up from the classic book "How to Solve It"[0]. In particular "working backwards". You start from the goal you want and see what you know that is applicable to getting you to goal. [0] https://en.wikipedia.org/wiki/How_to_Solve_It

[deleted]

Re: An Algorithm for Passing Programming Interviews (2020)

#84

Post by shahbaby » Mon, Jan 03, 2022, 1:55 AM UTC

This type of top down learning doesn't work for interviews.

Just like how you can't learn math by reading high level summaries written by others.

You have to grind through it and see the connections yourself.

The author's lack of depth shows when he says that no graph means you can rule out DFS.

I also disagree on asking interviewer for the expected runtime. You're needlessly adding another constraint on yourself by doing that. You should ask for the input size and then figure out the best runtime that you can reach. A working suboptimal solution is more likely to get you to the next round than an incomplete attempt at an optimal solution.

Re: An Algorithm for Passing Programming Interviews (2020)

#85

Post by titanomachy » Mon, Jan 03, 2022, 1:58 AM UTC

mrfusion wrote: post #56

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…

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?

Just tell them it’s familiar. Depends on the company, but they can often tell. If you blast through a tough question and then struggle on easier ones, it’ll show up in hiring committee (or equivalent).

It could easily cost you the offer if they think you’re being dishonest.

If you say it’s familiar and they ask you to do it anyway, just solve it very quickly and thoroughly. They’ll give you points for your performance and probably ask you another.

Re: An Algorithm for Passing Programming Interviews (2020)

#86

Post by ldjkfkdsjnv » Mon, Jan 03, 2022, 1:58 AM UTC

Frost1x wrote: post #67

posharma wrote: post #15

Earlier quoted context omitted.

You've to be a genius to solve a "hard" unseen leetcode problem in 15 mins correctly. Facebook is notorious at expecting candidates to regurgitate solutions to problems in 15 mins. Intelligence plays a lesser role than exhaustive and painful practice which involves solving the same problem multiple times. It's a full-fledged examination that expects you to excel while being constantly watched and judged.

>It's a full-fledged examination that expects you to excel while being constantly watched and judged. and interrupted, frequently, because that's also perfectly normal. It's comical how this industry now thinks these arcane and often quite difficult DS&A interview question processes are reasonable and how it's been so normalized people just study this for weeks before applying to a new position, sacrificing evenings…

Made an edit to my post:

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, but facebook and google have very hard leetcode interviews and are known for the best software

Re: An Algorithm for Passing Programming Interviews (2020)

#87

Post by shahbaby » Mon, Jan 03, 2022, 2:00 AM UTC

mrfusion wrote: post #56

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…

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?

Practice with a friend.

Re: An Algorithm for Passing Programming Interviews (2020)

#88

Post by tubby12345 » Mon, Jan 03, 2022, 2:03 AM UTC

gopher_space wrote: post #78

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

It's a great way for second-raters to grind their stats instead of actually building something.

>second-raters to grind their stats

so sayeth the people on the outside of companies building the most complex software in the world.

Re: An Algorithm for Passing Programming Interviews (2020)

#89

Post by Supermancho » Mon, Jan 03, 2022, 2:03 AM UTC

malisper wrote: post #72

Supermancho wrote: post #54

The anagram solution leaves the actual hard part unfinished^. Also, to solve in O(n) you need a bit array (or a database like Postgres that can do an XAND on a string). > Sort the characters of the words alphabetically. Since anagrams are all made up of the same letters. This will give us the same string for any pair of words that are anagrams of each. Correct. > Produce a dictionary of the number of times each lette…

> "Produce a dictionary of the number of times each letter occurs in each word." is heading the wrong direction. You want an encoding that does not care about the number of times each letter occurs in each word. How so? "aab" is an anagram of "baa", but they are not anagrams of "ab".

100000 00000 00000 00000 00000 100000 00000 00000 00000 00000 010000 00000 00000 00000 00000

aab and baa

100000 00000 00000 00000 00000 010000 00000 00000 00000 00000 000000 00000 00000 00000 00000

ab

You aren't "counting" the number of characters. You're making an encoding that includes that information, without the aggregation. The aggregation is irrelevant as is the order of duplicate characters.

Re: An Algorithm for Passing Programming Interviews (2020)

#90

Post by [deleted] » Mon, Jan 03, 2022, 2:04 AM UTC

spekcular wrote: post #70

Supermancho wrote: post #54

The anagram solution leaves the actual hard part unfinished^. Also, to solve in O(n) you need a bit array (or a database like Postgres that can do an XAND on a string). > Sort the characters of the words alphabetically. Since anagrams are all made up of the same letters. This will give us the same string for any pair of words that are anagrams of each. Correct. > Produce a dictionary of the number of times each lette…

Sorry, I don't understand your comment. Why would the proposed "naive" solution of generating a dictionary not work in O(n) time? What is gained by this bit encoding? And as far as I know, XAND does not exist?

[deleted]