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

251–260 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#251

Post by vineyardmike »

krtwllndr wrote: post #236
shinazueli wrote: post #199

Earlier quoted context omitted.

It’s ridiculously obvious when people have seen the question before. The way we do it is like this: we have like 3 or 4 different small variations on each question. Such that the solution is measurably different, in quite telling ways, but that the given problem looks almost identical. In one specific case the given is identical, but there are 3 variations to the question based on how the candidate asks questions abo…

Having been on both sides of interviews but fortunate enough to no have to do leetcode interviews I have a genuine question for those that do. Why do them? Are you really facing those problems frequently enough at FAANG to have know them? Is it uppity engineers? Gatekeeping? Or are you just getting so many applicants that you have to filter somehow and leetcode interviewing has some nice properties (easy to apply rem…

Its probably partially gatekeeping. "I had to invent a unique sorting algo in this interview so you will too".

But also, its a good measure of someones ability to take an abstract problem and solve it. Lots of mini events in a LC problem to critically think. Like you said, we need a filter and its really easy to use LC to be that.

That said, I've worked at fang with co-workers who had trouble using iterators or properly assessing complex Boolean logic (and I'm not talking about needing de Morgan), so sometimes LC skills are needed on the job. So getting a signal that "this person can't write loops" means "we don't trust this person not to write an infinite loop", however rare that day comes.

There's enough programmers who want FAANG jobs and its easy enough to apply and the pay is high enough that you should be free to gatekeep by someone who understands intro-to-java level data structures and algos. Maybe leetcode-hard is unnecessary, but easy should be doable.

Re: An Algorithm for Passing Programming Interviews (2020)

#252

Post by GistNoesis »

branko_d wrote: post #234
feoren wrote: post #228

Am I crazy or is the first answer terrible? I sat down and wrote out and answer for the problem and I initialized one integer and one timestamp. It should be O(1) time and O(1) memory easily, right? I'm seeing comments saying they'd use an array or a hash table -- why are you using any data structure? You don't need to remember how many times it was called 61 seconds ago; just keep a timestamp and the last time you r…

I don't think you can have a "sliding window" of time just based on that. The next time you call the function, you need to count how many of the old calls are still "unexpired". This number (potentially) gets lower with each passing quantum of time. How can you do that without holding a timestamp for each call? Please clarify if I misunderstood you.

I think you can have a more performant algorithm if you soften the constraint a little. (see my previous comment https://news.ycombinator.com/item?id=29776678 )

TLDR : You have a maximum of N credits, when time pass you earn credit at a rate of N credit by window_size, but if the time since previous request is less than window_size/N you lose 1 credit.

I don't think you can have more than 2*N requests in any sliding window without tripping the filter, but you can't consume more than the average of N requests / window_size without tripping the filter.

I think it's a better solution than the question asked by the author, because when you are rate limiting, you and the client may not have exactly the same time, and you might have edge cases like where the client batch 60 requests in a few ms every minute. If there is some time-jitter in the requests you may have 120 requests in 59.9 seconds. (Bonus question : What time-stamping of the request should be used ?)

Whereas with my solution it is more forgiving, it allow the client to use all its rate credit without risking to trip the filter if he respect the rate intent.

Re: An Algorithm for Passing Programming Interviews (2020)

#253

Post by jokethrowaway »

o10449366 wrote: post #159
cleverwebble wrote: post #134

Earlier quoted context omitted.

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 will totally appreciate the honesty and it goes a long way. Why? You're testing their ability to produce the right answer to a given problem - not their problem solving ability. To that end it shouldn't matter if they've seen the problem or not. I always find it hilarious when recruiters say that "getting the optimal solution isn't everything." I've failed nu…

> "getting the right answer is important, but we also want to see your thought process and how you might work with another engineer on the team."

That's how it works in all the companies I've hired in.

It doesn't matter if you don't get to the end of the problem, I just need to see you can think and that you know how to code. Do you think your daily job will require you more than that?

And believes me, this is enough to filter out plenty of bad apples.

Poor performance in my experience was never about not being able to solve a technical problem, it was always personal issues / not having motivation / hating the environment.

Re: An Algorithm for Passing Programming Interviews (2020)

#254

Post by bryanrasmussen »

jsiaajdsdaa wrote: post #141
renewiltord wrote: post #138

Earlier quoted context omitted.

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

Are you very knowledgeable in 3d graphics yourself, some of the replies here suggest that you may have a superficial knowledge (which is what I would have), if you choose an example domain that you have some knowledge about but not deep knowledge what happens if by accident your interviewee has significantly deeper knowledge than you? I worry that person might end up sounding overly technical or even like they're BS'ing their way through the interview.

Re: An Algorithm for Passing Programming Interviews (2020)

#255

Post by vineyardmike »

o10449366 wrote: post #159
cleverwebble wrote: post #134

Earlier quoted context omitted.

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 will totally appreciate the honesty and it goes a long way. Why? You're testing their ability to produce the right answer to a given problem - not their problem solving ability. To that end it shouldn't matter if they've seen the problem or not. I always find it hilarious when recruiters say that "getting the optimal solution isn't everything." I've failed nu…

> Why? You're testing their ability to produce the right answer to a given problem - not their problem solving ability. To that end it shouldn't matter if they've seen the problem or not.

Pretty sure most people want to test problem solving ability, and hopefully your problem solving ability solves the problem correctly. If you method to solve the problem is to find the answer online and repeat it... that may not be how the company wants you to solve their problems.

Re: An Algorithm for Passing Programming Interviews (2020)

#256

Post by sydthrowaway »

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…

Whats your technique?

Re: An Algorithm for Passing Programming Interviews (2020)

#257

Post by shankr »

throwawaysea wrote: post #213
o10449366 wrote: post #107

Earlier quoted context omitted.

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

Is this common among immigrant communities? For example do Vietnamese or Indian or Nigerian communities exist to give each other exclusive support on finding jobs or other such advantages?

Just another kind of networking.

Re: An Algorithm for Passing Programming Interviews (2020)

#259

Post by unbanned »

shinazueli wrote: post #199
renewiltord wrote: post #138

Earlier quoted context omitted.

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”

It’s ridiculously obvious when people have seen the question before. The way we do it is like this: we have like 3 or 4 different small variations on each question. Such that the solution is measurably different, in quite telling ways, but that the given problem looks almost identical. In one specific case the given is identical, but there are 3 variations to the question based on how the candidate asks questions abo…

>It’s ridiculously obvious when people have seen the question before

>We started doing it this way precisely because we kept running into people who would have 3 nearly perfect interviews and one “hard fail”

So which is it? Obvious they've seen the question before, or only obvious after they fail on an unseen problem...

Your arrogance and hostility is hilarious.

Re: An Algorithm for Passing Programming Interviews (2020)

#260

Post by usrbinbash »

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.

Problem is, there is not a lot of incentive for people looking for a job to use LC and similar to understand algorithms and data structures, and with good reason;

Many interviewers do not ask the questions to check for thought process or problem solving ability, they treat it like some TV quiz: Ask question, get answer, compare answer to note in hand, applaud if its the same answer, next question. Why? Because its a lot easier to sit there watching the candidate squirm at the whiteboard, while thinking about what's for lunch, than engaging the candidate and gasp talking to him/her.

This creates incentive for people taking these BS interviews to learn-for-the-test: Get a list of the current top50 questions asked regularly at interviews (there are resources for that) and memorize them.

Why? Two reasons:

1. It is alot easier than understanding the concepts and purpose of different algos and data structures.

2. Trying to solve them by applying actual understanding, runs the risk of getting stuck on an unfamiliar problem, or producing a slightly sub-par solution instead of the "correct" answer, and getting booted out despite demonstrating the exakt thing aka."problem solving ability" the interviewers allegedly look for

And, unsurprising, because there is money involved, an industry has sprung up around this: Pay-For-Tech-Interview-Training is a thing, including regular updates on popular questions.

The result of course: Companies running the risk of hiring people who are great at answering LC questions but fail when they actually have to solve a problem where they cannot copypaste the solution from SO.

Post reply on HN