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

Re: An Algorithm for Passing Programming Interviews (2020)

#161

Post by thaumasiotes » Mon, Jan 03, 2022, 4:58 AM UTC

iampims wrote: post #157

thaumasiotes wrote: post #130

Earlier quoted context omitted.

> Interviews are not adversarial I'm struggling to imagine a definition of "adversarial" that would make this true. You have two parties with conflicting goals.

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 without having the interview.

If you don't believe that interviews are -- in every case -- nothing but a waste of time, then you must reject one of the two premises. You either believe that (1) The interviewee does not wish to be hired, or (2) there is a conflict between the interviewee's goals and the interviewer's goals.

We can make a similar observation purely by knowing that interviewers sometimes reject interviewees.

Re: An Algorithm for Passing Programming Interviews (2020)

#162

Post by asxd » Mon, Jan 03, 2022, 4:58 AM UTC

stathibus wrote: post #111

benlivengood wrote: post #110

Earlier quoted context omitted.

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…

A good way to avoid this conundrum is to ask questions that are worth solving in real life. If the candidate breezes through the discussion because they've actually had to solve the problem before , then their victory is well earned. If on the other hand its an academic question in the same vein as the data structures or algorithms puzzles you find on $interviewprepforum, then the fact that they've solved it before t…

I think this is on the right track. The best interviews I've been a part of involve the interviewer asking a question they don't fully know the answer to. Then the interview turns into a conversation where both parties are trying to work together to formulate an answer. The candidate should be scored based on how constructive that conversation is.

Re: An Algorithm for Passing Programming Interviews (2020)

#163

Post by smus » Mon, Jan 03, 2022, 5:02 AM UTC

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

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

...are they? whenever I go on facebook, I always have a slow, unresponsive, buggy experience just using the website, and that's on firefox with 32gb ram on a 10th gen core i7

Re: An Algorithm for Passing Programming Interviews (2020)

#164

Post by cvhashim » Mon, Jan 03, 2022, 5:03 AM UTC

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…

I’d bomb this interview.

Re: An Algorithm for Passing Programming Interviews (2020)

#165

Post by komaromy » Mon, Jan 03, 2022, 5:03 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 can get hired as a software engineer wherever, but I’m only mediocre at doing the job.

I feel exactly the same.

Mind if I ask how you deal with this?

I recently left software (not sure if temporary or permanent yet) and I'm pursuing tutoring in an unrelated field. So far I'm liking it more because I feel better than mediocre.

Re: An Algorithm for Passing Programming Interviews (2020)

#166

Post by nlh » Mon, Jan 03, 2022, 5:05 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…

So I'm not a part of this world at all and I'm super fascinated by this perspective. I hear your point entirely. How do you counter the issue with pre-structured interviews where the questions get distributed and you end up with candidates who learn how to answer your exact question (but lack the skills to actually be dynamic in their job, or even do their job)?

Re: An Algorithm for Passing Programming Interviews (2020)

#167

Post by codeisawesome » Mon, Jan 03, 2022, 5:06 AM UTC

46756e wrote: post #117

o10449366 wrote: post #112

Earlier quoted context omitted.

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…

Not especially experienced with interviewing, but definitely agree with this. Leetcode sucks, but I’ll take it over how finance jobs are where it’s all about connections and where you interned when you were 19.

(Not to mention that that internship might be gate-kept for reasons outside of expertise, to boot)

Re: An Algorithm for Passing Programming Interviews (2020)

#168

Post by ipaddr » Mon, Jan 03, 2022, 5:08 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…

The average employment length at a faang is 2 years or less. A job in a single top law firm is an endurance battle that can span your career. Switching firms is looked at differently a lot of times negatively.

Once you land that job in finance or as a lawyer you are on track to be set for life. At a faang after a few years you'll get pushed into management or pushed out.

It's not the same.

Re: An Algorithm for Passing Programming Interviews (2020)

#169

Post by godelski » Mon, Jan 03, 2022, 5:09 AM UTC

cleverwebble wrote: post #134

o10449366 wrote: post #95

Earlier quoted context omitted.

No, if you really want to game it you sign up for membership on Chinese forums where people post the questions word for word minutes after completing the interview. That or work exclusively with private recruiters that tell you the questions verbatim because they have a vested interest in you passing. Interview questions don't rotate that frequently, especially for smaller companies or more specialized roles, and a $…

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…

Why not just throw out the questions. They seem useless, easy to cheat, and as commenters are suggesting there's a "pay to win" component. What are you really getting from these questions? Why is software engineering so different to other industries when it comes to interviews? Is there really a positive to this type of interviewing? Why not do what everyone else does and look at previous work (which in software we have a lot more considering GithHub), ask some questions relevant to the job, and see if the person has a personality match. Most jobs don't need the best of the best.

I'm not convinced the coding interviews have improved upon the standard interview style in any meaningful way.

Re: An Algorithm for Passing Programming Interviews (2020)

#170

Post by asxd » Mon, Jan 03, 2022, 5:12 AM UTC

travisjungroth wrote: post #41

dmurray wrote: post #24

There's a bit of a "draw the rest of the owl" thing going on here. If you have the experience to confidently eliminate the likely approaches that don't work, then you must know quite a bit about those approaches and their applications. And in particular, I'm not sure I can agree on eliminating recursion in the anagrams problem. He just says > Recursion – No way to apply recursion to the problem. but...there is? One p…

That's the nature of thought frameworks. You need to fill in the gaps yourself. It's still useful to have an organized approach. In my experience, people can know how well each technique would be suited to the task at hand if asked. But, they rarely consciously go through each technique they know and consider if it's the right approach. Most people would be well served to do this more often. Btw, this is a big failin…

I kind of agree, in that a good candidate should probably already be thinking "what data structure should I use here" no matter what the problem is. Just always think about what data structure to use. Every problem requires one.

More in the vein of what you're getting at though, I think helping a nervous candidate by asking obvious questions like this can be helpful: "What data structure would you recommend using for this problem?", or "What programming paradigm do you think would fit this problem best?". It's a bit of an ice breaker, and can lead to more interesting conversation than the candidate just sitting there, quietly thinking (admittedly, possibly not a good sign for a candidate if they do this, but interviews should be built around making it a good experience for the candidate as well).