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

181–190 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#181

Post by lavishlatern »

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.

This comment is incredibly out of touch with the world of big law. Not only do associates get cut, but many people stall out and can't make partner.

(also the whole concept of "Up or out" comes from Big Law/Consulting... https://en.wikipedia.org/wiki/Up_or_out)

You are just as "set for life" in big tech as big law. In fact, if you're looking at the last decade, big tech won hard considering tech stocks and how big law froze (and even slightly cut) salaries during the great recession.

Re: An Algorithm for Passing Programming Interviews (2020)

#182

Post by jallen_dot_dev »

aurelianito wrote: post #4

The first example test given (rate limiter) gives a bad answer. I wouldn't use this method.

Instead of a linked list I would have:

allocated an array of size 10

an int i that increments on every call mod 10

Each successful call puts the current timestamp in array[i] and increments i. On each attempt to call, you check if array[i] is > 1 minute ago. This way you are only ever checking 1 array element instead of potentially deleting multiple list items and counting.

Re: An Algorithm for Passing Programming Interviews (2020)

#183

Post by titanomachy »

someelephant wrote: post #125
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.

If you throw out a time complexity most interviewers will tell you if they expect something better. For big companies, it's always a crap shoot. For smaller companies, if the person isn't willing to have a conversation with you it's a sign they would be difficult to work with.

Not just throwing out a time complexity to see what sticks, but if you sketch out an approach and give the complexity then I agree, they will probably either tell you “implement that approach” or ask “can we do better?”.

Re: An Algorithm for Passing Programming Interviews (2020)

#184

Post by visarga »

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…

> If someone doesn't quickly and intuitively grasp that a shape is a collection of faces, ..., I'm not sure that they have what I am personally looking for

I was doing the same to weed out the bad candidates - asking them something they should know, something logical and basic - but got bad feedback once, been asked to instead focus my questions on the strong points described in the CV. I mean, for the practical part the candidate wasn't able to count the unique words in a text file in 30 minutes. I thought opening files and reading strings and splitting are so basic anyone should know them.

Re: An Algorithm for Passing Programming Interviews (2020)

#185

Post by asxd »

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…

Agreed. Ideally both parties want to form a symbiotic relationship.

Re: An Algorithm for Passing Programming Interviews (2020)

#186

Post by titanomachy »

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.

I usually reach for caching first because it’s more intuitive (for me and my reviewers) and because we often have well-known size bounds and relaxed enough performance requirements that make an “analytical” solution unnecessary.

Re: An Algorithm for Passing Programming Interviews (2020)

#187

Post by gls2ro »

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

How do you know that Facebook and Google have best software because of the way they do their interviews?

At their size (number of employees, number of people who want to work there) they could probably just randomly pick (or add here any other way of selecting candidates) software engineers and still get some of the best in the market that will create amazing software. Not saying this is what is happening but I am just providing an alternative explanation to underline that the conclusion hard interview => best software needs more evidence to be true.

I think the way interviews are done is a function of:

- company culture (first and foremost)

- size (how big is the company and how many people they are hiring) and churn

- their believes about building software (some people believe math is required, some people think engineering is required, some people believe no pre-requisite is required)

- employer attraction: how much/how many people want to work there

- availability/support of employed engineers to be part of interview process

- how it started (usually big companies inherit the conception about interviews from their original founders as they where the ones hiring the Cs)

- the country culture where the C level and top management is located

Re: An Algorithm for Passing Programming Interviews (2020)

#188

Post by barry-cotter »

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.

> The average employment length at a faang is 2 years or less

Because if you're hiring 40% of your current headcount a year and some people leave that gets you to very short average tenure very quickly.

Re: An Algorithm for Passing Programming Interviews (2020)

#189

Post by mavelikara »

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…

> As someone who has studied and passed before in this manner, and is now an interviewer,

Why do you believe now that the path you took is no longer ideal for other candidates?

Re: An Algorithm for Passing Programming Interviews (2020)

#190

Post by milkey_mouse »

Supermancho wrote: post #54

The anagram solution leaves the actual hard part unfinished^. Also, to solve in O(n) you need a bit array (or a database like Postgres that can do an XAND on a string). > Sort the characters of the words alphabetically. Since anagrams are all made up of the same letters. This will give us the same string for any pair of words that are anagrams of each. Correct. > Produce a dictionary of the number of times each lette…

You could use a lookup table to turn the nth letter of the alphabet into the nth prime number, then multiply those primes together. This "hash" would be unique up to reordering of the primes/letters.
Post reply on HN