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

211–220 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#211

Post by visarga »

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

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

How do you compare candidate A with preferred subject 1 with candidate B with subject 2? And how do you get the candidate to talk sincerely and not bullshit around the topic, especially when testing ML - a modern alchemy more or less, no definitive answers, just a bag of tricks?

I have had problems with controlling the waste of time and directing the talk towards useful topics because the candidate wouldn't stop the bullshit talk. Maybe other fields have less bullshit maneuvering space.

I think it's better to go with a list of basic questions that remains the same between candidates. Only if they ace the basics I test for depth. Depth can be tricky to evaluate, especially for people who are not very bad - maybe just in ML.

Re: An Algorithm for Passing Programming Interviews (2020)

#212

Post by vanusa »

thaumasiotes wrote: post #161
iampims wrote: post #157

Earlier quoted context omitted.

How are they conflicting?

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 employer-side ghosting is so widespread, along with other abusive practices like piling on lengthy take-homes, etc.

Re: An Algorithm for Passing Programming Interviews (2020)

#213

Post by throwawaysea »

o10449366 wrote: post #107
nomy99 wrote: post #102

Earlier quoted context omitted.

can you give me a link to one of these forums?

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?

Re: An Algorithm for Passing Programming Interviews (2020)

#214

Post by Jensson »

vanusa wrote: post #51
sjburt wrote: post #40

Earlier quoted context omitted.

Because in the real world you don't know the runtime of the optimal solution, except for certain very well studied and simple problems. At best you might know the runtime of the best published solution. But in many cases your problem isn't something that anyone has studied in that kind of detail and it's going to be on you to determine whether your solution is satisfactory or whether you should go back and improve.

Because in the real world you don't know the runtime of the optimal solution, The question specifically referred to target performance, which IRL is almost always known and freely communicated (in at least ballpark terms). As in: "Find the median of this array of 10k integers in .01 seconds please. Not 10 billion, just 10k". You say: "OK, sort and done." IRL if someone at your job says: "Write some code to find the m…

Being told what to do is for juniors, anyone at intermediate or above should be able to recognize most compute waste and be able to fix it without being told what they are supposed to do or how fast the end result is supposed to run.

Re: An Algorithm for Passing Programming Interviews (2020)

#215

Post by sharpy »

jjj123 wrote: post #177
Aeolun wrote: post #143

Earlier quoted context omitted.

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

Yeah and often the interviewer won’t be prepared with a backup question so you waste time for them to find one. It sucks that it puts the interviewee in a worse position for being honest.

A advantage to having standard interview questions. Plus the questions we ask lend themselves to extensions (also predefined) so you can still see how they reason about and solve those. And given that our interviewers are familiar with them, we can calibrate across many candidates. We also have a pool of people who maintain the standard interview questions.

Re: An Algorithm for Passing Programming Interviews (2020)

#216

Post by Dylan16807 »

vlovich123 wrote: post #137
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 g…

It's possible to gradually resize a hash table to prevent spikes.

For collisions, if you use a good hash then you can adjust your load factor and chaining strategy to make sure it's never a problem. Where 'never' is 'less likely than the computer spontaneously self-destructing'.

Re: An Algorithm for Passing Programming Interviews (2020)

#217

Post by vanusa »

ldjkfkdsjnv wrote: post #86
Frost1x wrote: post #67

Earlier quoted context omitted.

>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

The problem is that soon enough, all these mediocre and wannabe companies started copying the FAANG process, thinking: "If we interview like FAANG, we must be like FAANG. Or at least candidates will think we're like FAANG." And: "If your process rejects 99 percent of all applications, then that mean we're hiring the top 1 percent."

Which is basically how the LC craze got started.

Re: An Algorithm for Passing Programming Interviews (2020)

#218

Post by jayd16 »

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…

The major frustration is that its endurance in an mostly irrelevant task. If the problems were more relevant, active software engineers wouldn't need to study outside their day to day duties, no?

Re: An Algorithm for Passing Programming Interviews (2020)

#219

Post by jayd16 »

o10449366 wrote: post #112
kache_ wrote: post #71

Earlier quoted context omitted.

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…

Software engineers that QQ about how unfair algorithm interviews are are clearly out of touch with how difficult and truly unfair interviews are for other high paying industries like law or medicine (in the US) where getting interviews is based on pedigree and getting one or two rejections can permanently deny you from top firms/positions. There are always things that can be improved about interview processes, but ma…

What is the relevance of this whataboutism? Some other industries have bad or worse interview practices as well. That doesn't make this process good. What is the point you're trying to make?

Its immature to think we can do better because others have it worse? Rubbish.

Re: An Algorithm for Passing Programming Interviews (2020)

#220

Post by vanusa »

Jensson wrote: post #214
vanusa wrote: post #51

Earlier quoted context omitted.

Because in the real world you don't know the runtime of the optimal solution, The question specifically referred to target performance, which IRL is almost always known and freely communicated (in at least ballpark terms). As in: "Find the median of this array of 10k integers in .01 seconds please. Not 10 billion, just 10k". You say: "OK, sort and done." IRL if someone at your job says: "Write some code to find the m…

Being told what to do is for juniors, anyone at intermediate or above should be able to recognize most compute waste and be able to fix it without being told what they are supposed to do or how fast the end result is supposed to run.

It isn't "telling them what to do"; it's basic professionalism.

If someone has cleared their day to come into your office and talk to you -- you should respect their time. Don't make them guess at the goalposts, don't use implicit or hidden metrics. If they ask you what the expected latency is for an API response, or whether they should worry about hostile string injection attacks -- just tell them.

As you would in a normal, respectful, professional setting.

Post reply on HN