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

221–230 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#221

Post by mavelikara »

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…

> It's pretty obvious to interviewers if you've solved a problem before, and we appreciate the honesty.

> ..

> dishonesty is never a good fit.

If you rejected every such “dishonest candidate”, the paid services offering candidates practice questions would have gone out of business long ago.

Given the popularity of such services, have your considered the possibility that you overestimate your ability to spot candidates who have solved the problem previously?

Re: An Algorithm for Passing Programming Interviews (2020)

#222

Post by thaumasiotes »

vanusa wrote: post #212
thaumasiotes wrote: post #161

Earlier quoted context omitted.

The interviewer's goal is to evaluate the interviewee accurately. The interviewee's goal is to be evaluated inaccurately. If you really need an example, then look at it this way: 1. The interviewee's goal is to be hired. 2. Assuming there is no conflict of goals, then the interviewer's goal is to hire the interviewee. 3. This immediately implies that the interview is a pure waste of time. You can just make the hire w…

The interviewer's goal is to evaluate the interviewee accurately. More specifically: the interviewer's goal is to minimize (1) false positives and (2) the expenditure of the company's resources. Meanwhile, candidates hope to be evaluated "fairly", which is in direct conflict with criterion (1). They also naively expected to be treated "decently", which is in direct conflict with criterion (2) and which explains why e…

> which is in direct conflict with criterion (2) and which explains why employer-side ghosting is so widespread, along with other abusive practices like piling on lengthy take-homes, etc.

I don't think concerns about resource expenditure actually explain ghosting. I think that happens despite what the company would prefer, because the people involved find it unpleasant to notify candidates of a rejection.

Lengthy take-homes are easier to explain by reference to resource concerns.

Minimizing false positives is not a fundamental goal of interviewing -- accuracy is a goal in all settings, while minimizing false positives isn't. But minimizing resource expenditures is; you're right about that.

Re: An Algorithm for Passing Programming Interviews (2020)

#223

Post by the_arun »

AbbeFaria wrote: post #200
abswest wrote: post #146

Earlier quoted context omitted.

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

I recently interviewed with a startup. They had "outsourced" the first round to a 3rd party firm that specializes in taking tech interviews (Mostly Algorithm rounds). The interviewer posted an LC question and asked me to read it. Since I was already logged into my LC account, he first asked me to show if I had solved it. I said I did. He then posted 9-10 LC questions one by one, all of which I had solved (I was doing…

Unfortunately goal of interviews these days is to know what you don’t know, instead of what you know

Re: An Algorithm for Passing Programming Interviews (2020)

#224

Post by solididiot »

Interviewing has become a theater of the absurd.

You get examined on things that won't be useful in 99% of your work.

People put in hours to prepare and game it.

Overall countless hours go to waste to just play the role.

Most times it doesn't even show whether someone can think (what you might see as thinking might be well rehearsed "act as dumbfounded for a while").

Re: An Algorithm for Passing Programming Interviews (2020)

#225

Post by gnulinux »

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

> facebook and google have very hard leetcode interviews and are known for the best software

This has got to be a joke of some sorts. More like the worst software. Sure Google is super rich, they have unlimited engineers who produce a lot of code. Almost all Google products I used were crap, buggy, bloatware.

Re: An Algorithm for Passing Programming Interviews (2020)

#226

Post by strstr »

smus wrote: post #160
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.

> 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. I agreed with you up until this point, which seems unnecessarily harsh to me

There’s more to an interview than algorithms (e.g. coding, communication), so it’s not a death sentence.

In the hundred or so interviews I’ve given, I’ve never had a candidate persist in forcing questions along these lines from the very start, even after I have turned the question back around at them. If you force me to give you hints out of the gate, something very weird is going on.

Re: An Algorithm for Passing Programming Interviews (2020)

#227

Post by dvirsky »

Aeolun wrote: post #143
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! 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).

Yep, I did it a couple of times and I didn't get any credit, just got harder questions that the interviewer did not practice in a long time. You should only disclose this if you're getting the same question in the same interview round from the same company, or maybe if you're back for another round a couple of years after failing.

As an interviewer though, there were a few instances where I just told people "let's do this problem anyway, don't worry" and the candidates didn't always do a good job.

Re: An Algorithm for Passing Programming Interviews (2020)

#228

Post by feoren »

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 reset the timestamp. If you need it to be clock-minutes instead of rolling (it doesn't; whose clock, anyway?), then just round the timestamp. The obvious follow-up question is "ok, what if it needs to be limited to 10,000 calls per minute?" You're going to keep 10,000+ elements in some collection for no reason? I wouldn't immediately reject a candidate for coming up with this answer but I would seriously question their thought process on this one.

In fact it's kind of ironic that his first example exposes how bad this advice is: by trying to meta-game, starting from a few example data structures, he shows he completely misses the solution that is both simpler and much more performant.

Re: An Algorithm for Passing Programming Interviews (2020)

#229

Post by totololo »

vishnugupta wrote: post #175
jsiaajdsdaa wrote: post #141

Earlier quoted context omitted.

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…

> point is a collection of vertices, This is the first time I’ve come across this definition of a point. Geometrically point is defined as a zero dimensional shape (or something similar) if I recall correctly. Besides, I don’t see how it’s intuitive at all! It isn’t to me at least. Larger point being, if you pick such random domain without calibration you will run into such argument/discussions during an interview. N…

Point coordinates, not the point itself.

Re: An Algorithm for Passing Programming Interviews (2020)

#230

Post by strstr »

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.

Identifying a reasonable target runtime can be part of the problem. The longer they’ve been writing software, the more ambiguity I expect them to handle.

If the candidate wants to discuss performance, I’m obviously interested, but if they want me to serve a hint to them on a silver platter I’m just confused.

Post reply on HN