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

171–180 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#171

Post by thaumasiotes »

baskethead wrote: post #156
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…

This is how dumb these interviews are. "We expect you to study and be prepared for algorithmic questions, BUT NOT TOO PREPARED! Only just enough. We will give you a random question of our choosing, but if you already studied this, then you will be deducted points, unless you tell us, so that we can ask you a question you've never studied before." A true interview would give the candidate their choice of question with…

I was always kind of confused about how advice for interviewers always comes along with warnings of the type "Some people talk a good game about programming, but they can't actually do it. You have to watch out for these people. Never hire one. This is the biggest trap you can stumble into as an interviewer."

After getting some interview coaching, I think I understand how this complaint arose. The whole problem is an artifact of the interview format, in which the design intent is for the candidate to be unable to solve the problem on their own. So you get scored based on how well you can charm the answer out of your interviewer while making them feel like everything they said was your idea. Instead of a test of how well you can program or solve math problems, it's a test of how good you are at cold reading. ( https://en.wikipedia.org/wiki/Cold_reading )

And unsurprisingly, a test of cold reading will end up delivering people who are good at cold reading without reference to whether they're good at other things. If you want to avoid this problem, just start giving assessments that don't involve interaction with the interviewer.

Re: An Algorithm for Passing Programming Interviews (2020)

#172

Post by [deleted] »

komaromy wrote: post #165
titanomachy wrote: post #81

Earlier quoted context omitted.

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.

[deleted]

Re: An Algorithm for Passing Programming Interviews (2020)

#173

Post by asxd »

hinkley wrote: post #154
troutwine wrote: post #73

There’s also two additional programming techniques you should be aware of: * Dynamic Programming How often do folks here use dynamic programming techniques in their professional lives? My own niche is systems programming. Dynamic programming is an important technique, sure, but given how rarely I see it used in practice compared to, say, statistical estimation it feels very overrepresented in interviews. But, maybe t…

More than my coworkers, not often enough, and not very often. Many people think DP and caches are synonymous, unfortunately.

Yeah, it's not commonly necessary for real world engineering, but it's certainly good to know, at least as a mental exercise. There's a nice free algorithms textbook used at UC Berkeley that covers the concept pretty well: http://algorithmics.lsi.upc.edu/docs/Dasgupta-Papadimitriou-...

Re: An Algorithm for Passing Programming Interviews (2020)

#174

Post by titanomachy »

komaromy wrote: post #165
titanomachy wrote: post #81

Earlier quoted context omitted.

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.

Haven’t really figured it out yet. Working on something I care about seems to help, although it’s not always easy to find. Having a strong, trusting relationship with my coworkers also helps. Easy to get detached otherwise.

Having other sources of meaning in life keeps me going during periods where my career isn’t going as well, gives me perspective and keeps me from getting depressed (I’m prone to it).

Working at top companies has helped me meet a lot of amazing people, including many of my closest friends, so I’m grateful for that at least.

Also, this gets thrown around a lot on HN, but if you’re brilliant at hard programming puzzles but not good at engineering jobs you might have ADHD. I do. Medication and/or ADHD-targeted treatments and accommodations could help. They’ve been modestly helpful for me.

Re: An Algorithm for Passing Programming Interviews (2020)

#175

Post by vishnugupta »

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…

> 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. Not sure what data point could be derived from such discussion when you are looking for someone who can write a decent maintainable code.

I must say that I’m terrible with geometry/graphics which hasn’t stopped me from creating value through software development in my domain, online payments.

If your intention is to gather signal for collaboration then I suggest picking something you are likely to collaborate on a day to day basis. Let’s say code review or architecture review. You could discuss why such and such an architectural pattern is useful, under what conditions, what are the pitfalls to watch out for etc etc.

Re: An Algorithm for Passing Programming Interviews (2020)

#176

Post by vanusa »

esyir wrote: post #136
vanusa wrote: post #44

Earlier quoted context omitted.

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

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

Re: An Algorithm for Passing Programming Interviews (2020)

#177

Post by jjj123 »

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

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.

Re: An Algorithm for Passing Programming Interviews (2020)

#178

Post by jaredsohn »

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

Re: An Algorithm for Passing Programming Interviews (2020)

#179

Post by baskethead »

nlh wrote: post #166
baskethead wrote: post #152

Earlier quoted context omitted.

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

If I could answer that question, I would be a billionaire already.

Programming interviews are almost exactly akin to actor's auditions. Just because you flunk an audition doesn't mean that you're a bad actor. Also, auditioning takes a special skill and it's not very much like being a real actor. But they still do it to this day. Programming interviews are similar.

The best hiring model I can come up with is the Netflix model. Pay top of the market, hire and fire people quickly if they don't meet expectations, with a generous severance. Have high expectations, reward the ones that can fulfill those expectations, and quickly get rid of those that don't. It's ruthless, but the Netflix engineers I know love working there.

Re: An Algorithm for Passing Programming Interviews (2020)

#180

Post by titanomachy »

smallnamespace wrote: post #115
titanomachy wrote: post #81

Earlier quoted context omitted.

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…

No matter what the filtering process is, the average person in [industry] will be mediocre by definition.

Sure. But I’m (by my own estimation) a mediocre software engineer who is very above-average at solving fun coding puzzles, and therefore at interviewing. Usually these threads are full of people complaining that they are good engineers who aren’t good at interviews; I’m suggesting that the opposite isn’t uncommon, even if it’s more rarely admitted.
Post reply on HN