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

Re: An Algorithm for Passing Programming Interviews (2020)

#201

Post by namdnay » Mon, Jan 03, 2022, 6:40 AM UTC

o10449366 wrote: post #155

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…

There's a certain irony to exploiting an ethically questionable method to obtain a job and, once you've obtained that position, using your authority as a gatekeeper to attempt to prevent others from entering the same way.

Like a company recruiting a hacker to manage their security

Re: An Algorithm for Passing Programming Interviews (2020)

#202

Post by AbbeFaria » Mon, Jan 03, 2022, 6:41 AM UTC

xkgt wrote: post #140

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…

I felt the same when I failed a leetcode interview. The reason behind my annoyance was that I had spent considerable amount of time over the past few years improving my skills in the areas I thought mattered (practicing TDD, design patterns,learning FP etc.,) I felt disappointed when none of these mattered compared to an artificial set of challenges setup in an unreal environment. I can't say for sure that such chall…

Skills such as design patterns etc do matter. There are separate rounds for testing just that, think Design rounds (LLD or HLD) but you usually have to pass the Algorithm rounds before to get to that stage.

Re: An Algorithm for Passing Programming Interviews (2020)

#203

Post by AbbeFaria » Mon, Jan 03, 2022, 6:45 AM UTC

titanomachy wrote: post #81

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…

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…

I don't want to underestimate the skill of being good at LC. In the past couple of months, I have solved about 200+ LC and I have been interviewing vigorously too. Its a tough skill for sure but beyond a certain point, you start seeing patterns you have applied before and once you are in the flow, it becomes slightly easier.

I only wish the real Software Engineering job was as simple as being good at LC, because it clearly isn't.

Re: An Algorithm for Passing Programming Interviews (2020)

#204

Post by namdnay » Mon, Jan 03, 2022, 6:45 AM UTC

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…

I don’t think anybody is complaining about the initial barrier to entry. These interviews would be more like asking a surgeon who’s worked for 10 years in one hospital to pass an anatomy multiple choice quiz when transferring to another hospital

Re: An Algorithm for Passing Programming Interviews (2020)

#205

Post by rixed » Mon, Jan 03, 2022, 6:46 AM UTC

baskethead wrote: post #152

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…

This is exactly the type of question that is the worst for interviews. It's a completely uncalibrated, completely subjective, esoteric type of question where you can't say exactly why you liked a candidate or why you didn't like her. There's no data underneath it except for "I liked how the conversation went." It completely gives an advantage to candidates who know 3D and completely gives a disadvantage to candidates…

I do not believe the hard data you are looking for exist for real. Interviewing is assessing what value an individual will bring to a project. Ideally we want this assessment to not depend on the interviewer and as a unidimensional real number so it's easy to do comparisons.

But the reality is:

- future performance depends on the team (and more largely on everything else in the business) and that varries unpredictably and is usually not part of the evaluation anyway.

- future performance also depends on how the project itself is going to evolve, which is hard enough to evaluate in itself (not just the timeline but oftentimes the involved technologies)

- assessing the value of anything is its whole can of worms (it's intrinsically subjective, you can't measure a physical "value" in SI units)

I prefer data over opinions like everyone else, but this may be a case where it is eventually safer to rely on as many as possible individual opinions and weight them, with just the amount of process in place to avoid common biases? (friends-of-friends, judging on look, country of origin, gender, ...)

I've seen big companies that takes hiring very seriously rely equaly on some preset metrics (based on prewritten questions thus easily gamed) as well as the gut feeling of several interviewers who are free to ask whatever additional questions, and I think it's the correct approach.

Re: An Algorithm for Passing Programming Interviews (2020)

#206

Post by Jensson » Mon, Jan 03, 2022, 6:53 AM UTC

vanusa wrote: post #176

esyir wrote: post #136

Earlier quoted context omitted.

>As do in-depth technical discussions about ... just about any subject the candidate claims to know about. Having attempted to do this after reading all the HN screeds, I found that this failed horribly. You'll find a large number of people who seemingly know the theory, but can't execute worth a damn. They can happily talk on and on about normalization, regularization, imbalanced datasets and so on. Then they fail f…

Try talking about execution, not theory.

You can't communicate experience like you can communicate theory, if you could then it would be called theory instead of practice. Theory is great since it is something we can communicate, whatever instincts you developed working on a big codebase can't be communicated. Some people thing you can, there are lots of talks about these things etc, but in practice you can't teach practice, you need to experience it yourself. And if you distil practice into pure enough droplets of wisdom that others can recognize as the truth without being your in-group, guess what, that is what we call theory!

Re: An Algorithm for Passing Programming Interviews (2020)

#207

Post by vanusa » Mon, Jan 03, 2022, 6:55 AM UTC

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…

No post body was provided.

Re: An Algorithm for Passing Programming Interviews (2020)

#208

Post by dnpp123 » Mon, Jan 03, 2022, 6:57 AM UTC

malisper wrote: post #151

dnpp123 wrote: post #108

Earlier quoted context omitted.

It's not specified in the article? Do that for rate limiting and it'll be super easy to DoS you - just show how fundamentally you can't brute force your way out of algorithmic questions despite the article suggestion (or how interviews are fundamentally flawed, but this is another debate ;)

> It's not specified in the article? From the article: > The function should have expected O(1) performance. > Do that for rate limiting and it'll be super easy to DoS you How so? The rate limiter has the same performance as, for example, a hash table. Operations are usually O(1), but are periodically O(n). It's not like every service that uses a hash-table is DoS-able.

Geniusly curious: does "expected" in English necessarily means average? My understanding was that expected is dependent of the application domain, so it can mean best or worst or average.

If you have an implementation that is O(N) in worst case it's (theoretically) DoSable since an attacker would always hit that case - so the expected complexity in case of an attack is O(N).

A trivial solution in O(60)=O(1) for worst case is to store the number of call everything second in a fixed size array and loop over it. With some arithmetic you can even avoid looping over it.

Re: An Algorithm for Passing Programming Interviews (2020)

#209

Post by Jensson » Mon, Jan 03, 2022, 7:02 AM UTC

arduinomancer wrote: post #69

malisper wrote: post #32

Earlier quoted context omitted.

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…

Wouldn't that mean you have to implement the binary tree as part of your solution? Seems way easier/time efficient to just use the built-in heap/priority queue of the language standard lib

C++ has built in binary trees with fast iteration. The C++ binary tree is my favourite standard library data structure of any language I've used, it isn't the fastest out there but it has so many useful things you can do with it. You can use it as a heap, you can use it as a dictionary, you can use it to sort things, you can insert items at the same time you iterate through it and if they are after where you are in the tree then you will find them in your iteration etc. It does so many things right that others don't do, I'm sure the others data structures are slightly faster but the C++ binary tree is so powerful and still fast enough for basically every problem.

Re: An Algorithm for Passing Programming Interviews (2020)

#210

Post by taneq » Mon, Jan 03, 2022, 7:10 AM UTC

gannon- wrote: post #30

LewisVerstappen wrote: post #2

> After being given the algorithm problem, ask for the specific runtime your solution will need to have. Almost certainly, the interviewer will tell you. In my experience, interviewers will rarely tell you the runtime of the optimal solution. Regardless, very interesting blog post.

+1, got me thinking about this one Elon quote that's roughly about how we're trained in school to solve the problem given to us, even if it's not a valuable problem to solve. Can save a lot more time and complexity by realizing the 'problem' isn't really a problem than any solution.

The thing that people like Elon sometimes forget is that most companies have far less room for first principles multidisciplinary problem solving than for the people who then implement the plan that comes out of said problem solving. It can still be helpful but it comes with the added cost that every time you ask someone to do a task you have to explain the entire decision tree that lead to the task, and then even if they do come up with a valid improvement you probably have to throw out a bunch of other decisions that other people are already working on implementing.