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

191–200 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#191

Post by dang »

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…

You have some good points, but can you please make your good points without crossing into personal attack? I'm sure you didn't mean to, and I'm sure you have good reason to feel strongly, but what you posted here is already aggressive and a step away from what the HN guidelines call for.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit more to heart, we'd appreciate it. Note this one:

"Have curious conversation; don't cross-examine."

Re: An Algorithm for Passing Programming Interviews (2020)

#192

Post by technological »

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…

Can you share your prescription

Re: An Algorithm for Passing Programming Interviews (2020)

#193

Post by travisjungroth »

asxd wrote: post #170
travisjungroth wrote: post #41

Earlier quoted context omitted.

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…

I have completely the opposite opinion of your second paragraph. I’m fine with candidates quietly thinking in an interview. It’s a big part of the job. I’m not optimizing for interesting, but for signal. And dropping the signal of “can get themselves going with structured thinking” is not worth it to make it a better experience for the candidate in that moment. I’m okay with a candidate feeling uncomfortable while they’re failing an interview. If anything, I think it’s better than the standard which is to give hints, act like everything is great and then thumbs down them later. Makes people so confused. There’s also a whole thing about who gets hints fastest, confirming biases. But that’s another giant thread.

Re: An Algorithm for Passing Programming Interviews (2020)

#194

Post by dang »

henning wrote: post #47
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…

This is a great way to start off a business relationship with dishonesty and cynicism. Enjoy your career.

Please don't cross into personal attack, no matter how wrong's interview preparation strategy is or you feel it is. Perhaps you don't feel you owe them better, but you owe this community better if you're participating here.

https://news.ycombinator.com/newsguidelines.html

Re: An Algorithm for Passing Programming Interviews (2020)

#195

Post by outloudvi »

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.

Interesting. I had never expected 1P3A mentioned on HN. It's mainly a forum for Chinese overseas to discuss their life and so on. Surrounding this topic they have also developed side features like COVID-19 statistics and some system for school applicants.

Re: An Algorithm for Passing Programming Interviews (2020)

#196

Post by cookie_monsta »

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…

1point3acres just added this question in their "wildcards" section - j/k

Re: An Algorithm for Passing Programming Interviews (2020)

#197

Post by thaumasiotes »

jaredsohn wrote: post #178
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 interviewee's goal is to be evaluated inaccurately. Only if the interviewee doesn't think they should be hired. I think a better way to think of this is: 1. The interviewer's goal is to hire somebody that will provide value at the company, using the hiring criteria as a way of judging it. 2. The interviewee's goal is to get an offer at a company that makes sense for their career goals. These aren't necessarily a…

>> The interviewee's goal is to be evaluated inaccurately.

> Only if the interviewee doesn't think they should be hired.

Nope. The interviewee would always like to be evaluated as better than they actually are, regardless of whether they meet the notional hiring threshold.

> These aren't necessarily adversarial.

The goals you list are still necessarily adversarial, because the interviewee's goal is always to get an offer and the interviewer's goal is to stymie them.

Re: An Algorithm for Passing Programming Interviews (2020)

#198

Post by [deleted] »

ipaddr wrote: post #168
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…

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.

[deleted]

Re: An Algorithm for Passing Programming Interviews (2020)

#199

Post by shinazueli »

renewiltord wrote: post #138
fermentation wrote: post #119

Earlier quoted context omitted.

Wow there seems to be an absolutely massive amount of useful information, maybe I should learn how to read it!

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 about it (if they don’t ask questions the question is not possible to solve as we don’t give all of the information you need.)

We started doing it this way precisely because we kept running into people who would have 3 nearly perfect interviews and one “hard fail”, and we eventually realized it was because they were so good at faking that they’d seen it before but if they hadn’t seen it before they bombed it hard.

So now that we have the “variations”, at least once a month someone will “hard fail” the interview because they’re obviously cheating and will quite literally give the right answer to the wrong question, just rote memorizing it.

It’s an arms race. And one that I enjoy.

Re: An Algorithm for Passing Programming Interviews (2020)

#200

Post by AbbeFaria »

abswest wrote: post #146
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 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 LC regularly then). In the end he got tired, and posted a question from another website (Hackerearth) which I hadn't solved. We ended up taking ~5 minutes just going through different LC questions and he was disappointed that I had solved all of them.

I have also faced situations where I have seen an LC question that I solved but couldn't solve it in an interview setting, mostly because of the pressure.

Post reply on HN