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

321–330 of 352 posts

Re: An Algorithm for Passing Programming Interviews (2020)

#321

Post by bradlys »

xtracto wrote: post #310
angarg12 wrote: post #233

Almost all advice online about interviewing is written from the point of view of the candidate. Sometimes this is good advice, but sometimes it devolves into some kind of astrology, where candidate are just guessing how things work. I've done +300 interviews at FAANG so I can share bit of advice from the interviewer's side. The caveat is that this is based on how I conduct interviews, so YMMV with other people. * Alw…

> and even while you code As an interviewer I explicitly ask candidates NOT to do this (or only doing it if they want). For some reason there is this expectation in coding interviews. I challenge anyone that pushes their interviewees to do this, to sit down during one of their own coding sessions and vocalize the stuff they are coding while doing it. In my opinion it is stupid, and unnecessary. When my interviewees s…

You’re rare as far as expectations go in the Bay Area. Most interviewers want explanations the whole way. Basically don’t stop talking ever.

Re: An Algorithm for Passing Programming Interviews (2020)

#322

Post by bradlys »

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…

Most things in interviews are wildly overrepresented compared to their usage though. I haven’t done any shortest path, binary search, topological sort, or many other things in most of my time in industry. I would have a hard time remembering even one instance for many algorithms.

Re: An Algorithm for Passing Programming Interviews (2020)

#323

Post by tubby12345 »

ironman1478 wrote: post #293
tubby12345 wrote: post #88

Earlier quoted context omitted.

>second-raters to grind their stats so sayeth the people on the outside of companies building the most complex software in the world.

Most of the engineers at those companies (and really all companies) don't work on those projects. Some people work on truly complex projects, but those people are a tiny fraction of the entire workforce. It wouldn't even make sense for a company to allocate people that way. Also, I'd contest the statement that Google or Facebook works on the most complex software. They don't work in fintech, medical, hard real time t…

i mean do you speak from experience or is this just more conjecture? what people on the outside fail to realize is that while individual projects might not seem complex (maybe frontend engineering on FB is less complex than pytorch) it's the scale of the systems you have to orchestrate that is incredibly complex.

Re: An Algorithm for Passing Programming Interviews (2020)

#324

Post by vineyardmike »

o10449366 wrote: post #268
vineyardmike wrote: post #255

Earlier quoted context omitted.

> Why? You're testing their ability to produce the right answer to a given problem - not their problem solving ability. To that end it shouldn't matter if they've seen the problem or not. Pretty sure most people want to test problem solving ability, and hopefully your problem solving ability solves the problem correctly. If you method to solve the problem is to find the answer online and repeat it... that may not be…

Really? In my position as a senior member on my team, one of the biggest mentoring costs is just teaching junior members how to search and find answers for themselves. Yes, day to day I'm not copy and pasting huge blocks of code from Stack Overflow, but when I need an answer and I don't immediately know it my first move is always to search internally or externally for others who may have already shared it. Why is bei…

Yes really.

Go ask your manager if you should copy and paste something you found on a chinese forum as 100% of the output you generate. Nothing original, no actual thoughts for yourself, JUST copy paste.

Search and find answers for themselves is not the same as blindly copy/pasting, which is basically what the scripted forum answers are.

Re: An Algorithm for Passing Programming Interviews (2020)

#325

Post by hinkley »

titanomachy wrote: post #186
hinkley wrote: post #154

Earlier quoted context omitted.

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.

Caching creates a mature product, no matter what your product roadmap says. If a rewrite is the tool of last result, caching is the second to last. Like pruning shears, once you use them, your world of options collapses considerably. All of those opportunities are gone and nature won't let you put them back.

Critically, caches are global shared state. That's why cache invalidation is the hardest thing. Global state also means people stop trying to have a data flow/architecture. None of these call trees need to advertise that they use a particular value because I can just grab it from a global if I need it. You don't know where things are actually used anymore because they all come from cache lookups, and because the lookup is so cheap (under typical system load, but catastrophic under high load), people don't even try to hold onto previously acquired data. They just fetch it again. Which is another boundary condition for cache invalidation (what if half a transaction has the old value and half the new value?)

They make flame graphs essentially useless. Sometimes immediately, or once the above starts happening. You quickly have no clear idea what the cost of anything is, because you never pay it, or if you try to pay it you end up amplifying the cost until there is no signal. Once people are promiscuously fetching from the cache, they don't even attempt to avoid duplicate lookups, so activities will end up fetching the same data 6 times. If you turn off the cache entirely for perf analysis then the cost skyrockets and the flame chart is still wrong.

You are back to dead reckoning and manually adding telemetry to potential hotspots to sort it out. This is very slow, and can be demoralizing. Quickly this becomes the fastest our app will be for a very long time.

Re: An Algorithm for Passing Programming Interviews (2020)

#326

Post by angarg12 »

emotional_fool wrote: post #319
angarg12 wrote: post #301

Earlier quoted context omitted.

Of course. Contrary to popular belief you don't need to ace all interviews to get an offer. It's fairly common to make a hire decision with one person not inclined.

So your assessment was "inclined no hire" when the person gave brute force solution, am I wrong?

Most often, but not always.

To understand why here is another bit of my philosophy: the aim is to find a good match between candidate and company. The interview is a (very flawed) proxy for this, so don't overindex on it.

For instance, recently I was inclined for a candidate although he didn't make it past brute force. The reason is that he did very well in the behavioural round, and wrote a very good brute force solution. Also, during coding, he explained in detail the internals of some data structures (e.g. hash maps), which shows they know their stuff. Lastly, they had an intuition about how to approach the problem optimally, even if they didn't manage to write the code.

Re: An Algorithm for Passing Programming Interviews (2020)

#327

Post by ficklepickle »

MauranKilom wrote: post #272
visarga wrote: post #184

Earlier quoted context omitted.

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

I program in C++ daily and wouldn't know the currently accepted way to read lines from a text file in it off the top of my head. It's simply not something I ever have to do. A good candidate should still manage to figure it out in 30 minutes, but your programming experience is most likely a lot less universal than you think.

They didn't specify needing to read the file line-by-line. You could read the whole file at once. There might not even be any new line characters in the file. You invented a requirement.

Re: An Algorithm for Passing Programming Interviews (2020)

#328

Post by raydev »

dvirsky wrote: post #227
Aeolun wrote: post #143

Earlier quoted context omitted.

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

Yep, I did it a couple of times and I didn't get any credit, just got harder questions that the interviewer did not practice in a long time. You should only disclose this if you're getting the same question in the same interview round from the same company, or maybe if you're back for another round a couple of years after failing. As an interviewer though, there were a few instances where I just told people "let's do…

> there were a few instances where I just told people "let's do this problem anyway, don't worry" and the candidates didn't always do a good job

Which should be a clear indicator that interviews aren't only judging problem solving skills, but also the candidate's ability to withstand the pressure of being watched and judged while they solve complicated problems.

For the interviewer, it's just another day and sure, they "want the candidate to succeed" and all that, but for the candidate, their future and livelihood are on the line and that's tough for some of us to just ignore while we focus on the not-easy school quiz problem of merging overlapping intervals or whatever.

Re: An Algorithm for Passing Programming Interviews (2020)

#329

Post by ALittleLight »

acedio wrote: post #235
feoren wrote: post #228

Am I crazy or is the first answer terrible? I sat down and wrote out and answer for the problem and I initialized one integer and one timestamp. It should be O(1) time and O(1) memory easily, right? I'm seeing comments saying they'd use an array or a hash table -- why are you using any data structure? You don't need to remember how many times it was called 61 seconds ago; just keep a timestamp and the last time you r…

That's a better solution in general IMO, but the author's approach can guarantee that you'll never go over N calls in a sliding window rather than fixed windows. I don't believe that's possible with the timestamp + count solution. Gotta bring up both solutions and ask the interviewer what they want :)

What's the problem with a sliding window and the timestamp + count solution? lastTime is the timestamp of the last call. newTime is the timestamp of the incoming call. If newTime - lastTime > 60 seconds then you're good to proceed, set count to 1 change lastTime to newTime and go on. Otherwise, check whether count is less than n and proceed accordingly (incrementing count if so). This accomplishes the sliding window and rounding down to the last whole minute handles the fixed window - right?

Re: An Algorithm for Passing Programming Interviews (2020)

#330

Post by throwaway123x2 »

gnulinux wrote: post #225
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,…

> facebook and google have very hard leetcode interviews and are known for the best software This has got to be a joke of some sorts. More like the worst software. Sure Google is super rich, they have unlimited engineers who produce a lot of code. Almost all Google products I used were crap, buggy, bloatware.

My Google Voice app lags for seconds... _seconds_... while typing out a text. It's insane.
Post reply on HN