Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

Post reply on HN
Print view View original

361–370 of 570 posts

Re: How to Pass a Programming Interview

#361

Post by potatolicious »

ljk wrote: post #238
staunch wrote: post #108

> candidates who have worked at a top company or studied at a top school go on to pass interviews at a 30% higher rate than programmers who don’t have these credentials (for a given level of performance on our credential-blind screen). Welcome to Silicon Valley meritocracy. And it's much worse for founders seeking investment, where there are no hard skills to test at all. It's almost purely about being the same class…

this is different than other fields how? it's the same old since the beginning :\

It's different because other fields haven't built up an entire mythos about how it's way more meritocratic than everyone else.

Tech prides itself in being more objective, more rational than other fields but in reality is no different.

In other fields the effects of class and network are openly acknowledged, in tech you to even address the issue you first have to punch through the mythos.

In other fields the open acknowledgment of these issues has resulted in some action to de-bias the system (see: blind auditions for orchestras, residency matching for doctors). These efforts are imperfect, but nonetheless still way further along than anything we have.

Re: How to Pass a Programming Interview

#362

Post by cgh »

hoodoof wrote: post #313

I've built alot of stuff and apart from hash tables, never really needed to understand: Hash tables Linked lists Breadth-first search, depth-first search Quicksort, merge sort Binary search 2D arrays Dynamic arrays Binary search trees Dynamic programming Big-O analysis I guess it depends if you are going for a job that REQUIRES these techniques then yes it is important, but for web application development - even soph…

You should know a number of things on this list if you do back-end webapp development, particularly for large/hairy enterprise stuff. So maybe you are referring to front-end only.

Re: How to Pass a Programming Interview

#363

Post by nathanaldensr »

digler999 wrote: post #128
quanticle wrote: post #72

Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…

> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…

Here's how you should reply: "Sorry, I don't have those complexities memorized. When I really need to look them up (which is nearly never), I refer to bigocheatsheet.com."

Re: How to Pass a Programming Interview

#364

Post by shasta »

Cakez0r wrote: post #335
shasta wrote: post #327

Earlier quoted context omitted.

> But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yesterday)? This is actually a trivially easy question that gets to the heart of whether you understand the point of moving averages or not (that you can update a sum by subtracting out the value leaving the window and adding in the value enteri…

It's not so much specifically about the moving average problem. I would want to see that a candidate can reason about the performance of some code / algorithm. I would not expect them to be able to recite the performance for specific algorithms from memory, however.

I agree, but I suspect "recite" was editorializing by the parent.

Re: How to Pass a Programming Interview

#365

Post by _nh_ »

Omnipresent wrote: post #36

The practice section doesn't mention anything other than the book. Are there any other resources that people use to prep for an interview? Looking for something that tests algorithms and data structures more than solving tricky problems.

If you're looking for a visual guide with code in (c++, java, python or javascript), check out Coderust (https://www.educative.io/collection/5642554087309312/5679846...)

Re: How to Pass a Programming Interview

#366

Post by throwaway12324 »

bm1362 wrote: post #352
throwaway12324 wrote: post #244

Earlier quoted context omitted.

Ironically enough, Triplebyte's own take-home projects were some of the worst I've ever had, and did a horrible job of respecting the candidate's time. When I went through the their take-home interview process, there were 4 projects to choose from, with only one having anything remotely to do with my area of expertise (it was a multiplayer game, and I was looking to work as a web front-end/full-stack developer). For…

Anecdotally, I had a really positive experience writing the HTTP server with TripleByte. I use interview projects to learn new skills and domains, doing so aligns my interest such that even if it doesn't go well I'm better for trying. My project review went reasonably well- we caught a bug, fixed it and tested. I turned down round two due to taking another offer, but genuinely felt like these guys cared about my prog…

> I use interview projects to learn new skills and domains

There probably lies the disconnect. For me, interview projects should assess how well I could perform in the position I'm applying to. And thus, if nothing else, interview projects should be relevant and practical.

It seems to me that Triplebyte's project choices were made based on how interesting developers might find them, and sheer technical challenge. Some might appreciate this, but personally, I'd rather learn new skills and challenge myself on my own terms.

Re: How to Pass a Programming Interview

#367

Post by BinaryIdiot »

zodiac wrote: post #277
BinaryIdiot wrote: post #98

Earlier quoted context omitted.

Alternatively we could come up with a better system for interviewing. Instead of concentrating on being able to remember algorithms and write them out in a completely non-normal way (white board) we could, instead, give them a very small project to do then have them come in and explain it, walk someone through extending it and / or work through a problem together. You'd get real experience seeing how they write their…

> we could, instead, give them a very small project to do one objection to this I've heard is that it disproportionately disadvantages people who don't have the free time to do it

While true in the end I would expect it to take less time to do a small project, come in and review / work with it than the typical 1-2 days of interviews. Not sure if it would actually happen that way in practice I admit.

I'd like to try it and attempt to gather data in either case.

Re: How to Pass a Programming Interview

#368

Post by cyphar »

krackers wrote: post #347
eranation wrote: post #33

If you have an unbounded abundance of good candidates, it is a different story then when you are a new startup fighting for talent. At highly targeted companies such as Google, Facebook et al, I'm sure that if they have a dryspell of good candidates in a given month (can't think of a reason why), then they revert to things like: "We don't care if you don't get the 'trick' immediately, we'll give you hints" and "we ju…

>But the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps) Wait why is it O(1) memory for the frequency map? As you keep adding elements doesn't the hashmap have to resize to prevent too many hash collisions? > finding if an unsorted list of numbers is an arithmetic series with just O(1) memory Is the strategy to solve this to first find the common difference `d` with one pass th…

> >But the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps)

> Wait why is it O(1) memory for the frequency map? As you keep adding elements doesn't the hashmap have to resize to prevent too many hash collisions?

Presumably because you'll have a constant number of keys (I'm not sure what the exact problem he's referring to is).

Re: How to Pass a Programming Interview

#369

Post by lisivka »

bm1362 wrote: post #352
throwaway12324 wrote: post #244

Earlier quoted context omitted.

Ironically enough, Triplebyte's own take-home projects were some of the worst I've ever had, and did a horrible job of respecting the candidate's time. When I went through the their take-home interview process, there were 4 projects to choose from, with only one having anything remotely to do with my area of expertise (it was a multiplayer game, and I was looking to work as a web front-end/full-stack developer). For…

Anecdotally, I had a really positive experience writing the HTTP server with TripleByte. I use interview projects to learn new skills and domains, doing so aligns my interest such that even if it doesn't go well I'm better for trying. My project review went reasonably well- we caught a bug, fixed it and tested. I turned down round two due to taking another offer, but genuinely felt like these guys cared about my prog…

I wrote 4 http servers in 20+ years (perl, java, shell, js). I don't want to write new one because I will develop no new skills.

Re: How to Pass a Programming Interview

#370

Post by pjscott »

sklogic wrote: post #291
jerf wrote: post #139

Earlier quoted context omitted.

"Or had to find the O(x^n) and replace it with O(x^2)" The other thing that really seals the deal for me as an inferior interview question is that you don't need to have a clue what O(x^n) is to wrap some code in a simple time call, see that the code you think ought to run in microseconds is running in seconds, by visual inspection notice stupid nested loops, and fix it. Self-taught programmers may not be able to say…

Are you going to profile everything for the entire nearly infinite range of possible input values, including all the pathological cases?

This is a very under-appreciated point. If you profile a program on non-pathological input, the profiler won't tell you what's going to explode later on when your program hits a rare case that you hadn't expected. Theoretical upper bounds don't have this problem.
Post reply on HN