How to Pass a Programming Interview • Hacker News Board

Re: How to Pass a Programming Interview

#381

Post by krackers » Wed, Mar 09, 2016, 1:09 AM UTC

cyphar wrote: post #368

krackers wrote: post #347

Earlier quoted context omitted.

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

The problem was to find the only non duplicate number in a list.

I'm not sure how you would have a constant number of keys. I mean I guess if you consider a worst-case hash table with bucket for each integer you would have 2^32 keys (which is technically O(1) space since the size remains fixed regardless of list length).

But using Big-O in this case is clearly disingenuous since the space allocated is far, far more than the one for xor solution.

Re: How to Pass a Programming Interview

#382

Post by FLUX-YOU » Wed, Mar 09, 2016, 1:13 AM UTC

EpicEng wrote: post #220

digler999 wrote: post #128

Earlier quoted context omitted.

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

That's fine, as long as you _never_ need to trust said dev to do anything complex. It's fine to have mediocre developers perform mediocre tasks, but if you want more from them someday you may be in trouble.

That's not really fair, people don't grow unless they're challenged.

Some people really do never advance past a certain point, but a lot of people write someone off as mediocre when they're just still in the process of gaining skill. Also, they only assess ONCE, which is pretty bad if we're trying to establish how good you are forever and always.

Re: How to Pass a Programming Interview

#383

Post by yueq » Wed, Mar 09, 2016, 1:17 AM UTC

tl;dr -- current programming interview format should be drastically changed.

I have interviewed 100+ candidates so far. I'm doing interview less and less recently simply because I found those coding/design questions less meaningful to judge how good a candidate is.

With websites like leetcode.com/lintcode.com that collect interview questions and provide online judge, all you need is to put enough time practicing. 10-years ago we use "reverse a linked-list" and nowadays we maybe use questions like "topo-sorting". The latter is significantly harder than the previous one -- but if candidate saw solution beforehand, it's actually easier to implement.

Re: How to Pass a Programming Interview

#384

Post by jerf » Wed, Mar 09, 2016, 1:21 AM UTC

tomjen3 wrote: post #197

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…

What if it isn't stupid code? What if it is straight forward and simple and looks correct but is just slow because it has to traverse a list instead of using a hash-table or some other data-structure. You can't get there by intermediate steps, you have to rip out the code that uses it and rewrite it with a hashmap. You can only do that if you know the space complexity and when a hash and a list is appropriate.

"You can only do that if you know the space complexity and when a hash and a list is appropriate."

You seem to be confusing "knows how to say 'oh of enn squared'" with "the loop gets slow when I iterate over a lot of things". One is generally a product of education, the other, merely experience.

The idea that a thing can only be learned in a classroom is perhaps in the top ten most pernicious ideas in the modern world, and probably one of the more surprising ones to show up in that list. You do not need special courses to discover that your code runs slowly, and as I've seen often enough, having had those special courses does not confer immunity against writing slow code.

Now, I am also a believer that formal education has its place, and if you are going to get a formal education in computer science, big-O analysis absolutely must be part of it or you are literally missing out on an entire rather important sub-discipline. But the idea that it's some sort of touchstone between Good and Bad programmers is just ludicrous nonsense. Slow code is slow. There are abundant tools that can be used to figure out why. If you can't work out why your O(n^3) loop is running slowly after a couple of years of practicing the art, you don't need formal education, you need a different job.

Re: How to Pass a Programming Interview

#385

Post by FLUX-YOU » Wed, Mar 09, 2016, 1:32 AM UTC

eecks wrote: post #322

emodendroket wrote: post #242

Earlier quoted context omitted.

Sure they do. "Model a parking garage in code" or "design a database with customers, orders, etc" are classic interview questions.

What is expected from something like "model a parking garage in code?" Something like a garage class that has properties like numberOfCars, maxAmountofCars, maxHeight and methods for insertCar(), removeCar(), isGarageFull() ?

Probably keeping track of how many parking spots are available as cars enter/exit, and denying entrance if you're full up.

Re: How to Pass a Programming Interview

#386

Post by bogomipz » Wed, Mar 09, 2016, 1:33 AM UTC

I'm sorry but could someone explain who tripplebyte is and why they are so "precious"? This blog post in my opinion is symptomatic of of this bizarre silicon valley interview culture. This whole "how to ace the programming interview" bullshit is really disturbing. Are you looking for people who are good at test taking or people that can produce good product? Yes CS fundamentals are important - data structure/algorithms, but I'm much more interested in whether a candidate understands the problem space and can reason about it. I want to know about systems they've designed in the recent past why they made the choices they made. Being able to code up Kruskal's spanning tree perfectly on a white board while being timed is a neat parlor trick but if you don't understand the bigger holistic picture of systems I don't think it means that much.

As far as these take home assignments go, I find this a disturbing trend as well. Especially egregious is telling someone there is a time limit on your working for free. If you're going to pay me for my time awesome lets talk, otherwise lets maybe look at some code I've already written.

This industry seems to get more up its own ass every day.

Re: How to Pass a Programming Interview

#387

Post by bliti » Wed, Mar 09, 2016, 1:40 AM UTC

bogomipz wrote: post #386

I'm sorry but could someone explain who tripplebyte is and why they are so "precious"? This blog post in my opinion is symptomatic of of this bizarre silicon valley interview culture. This whole "how to ace the programming interview" bullshit is really disturbing. Are you looking for people who are good at test taking or people that can produce good product? Yes CS fundamentals are important - data structure/algorith…

From their website:

We help programmers find great jobs at Y Combinator startups. No resumes, just show us you can code.

* Our Company

We believe hiring should be about what you can do, not what you say you can do. Our mission is to build the world's best technical hiring process.

We don't care where you went to school or which companies you've worked at. We only care if you can code. If you can, we'll do everything we can to find you the best startup to work at. *

That mission statement plus the blog post means that they are recruiters for financially unstable companies (aka startups). Makes the blog post that much harder to believe since startups are beggars not choosers when it comes to hiring.

Re: How to Pass a Programming Interview

#388

Post by robryan » Wed, Mar 09, 2016, 1:44 AM UTC

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…

You should have an intuitive idea around complexity and when it makes sense to optimise.

I don't think though you need to know that for example fastsortx is n log n in the best case off the top of your head in an interview situation. You should be able to reason your way through why it is faster than some other sort though.

Re: How to Pass a Programming Interview

#389

Post by blisterpeanuts » Wed, Mar 09, 2016, 1:52 AM UTC

My solution has always been pretty simple -- I do poorly in exam interviews, and usually I don't get the job. Regurgitating Algorithms 301 -- nope, not for me. They'll end up with someone who's great at regurgitating. They're happy and I'm happy.

I can explain very clearly how I would go about solving a problem, maybe whiteboard it, flesh out a design, ask them some key questions to show I'm a thinker and not just a follower. That kind of interview usually goes well for me.

As a result, I usually end up with jobs where I have a lot of creative latitude, where I can think up new product ideas and prototype them out, where I can solve problems my own way.

I wish I could pass those Google tests, though. It would be nice to have it all. But some of us just have limitations, I guess. Luckily, it hasn't held me back from having an enjoyable and relatively well compensated career.

Probably today the thing is to have a couple of apps on the Android or Apple appstore, a Github page with some interesting toys and experiments, some open source contributions, and of course the old-fashioned networking that is how many of us still get our best jobs and most successful business relationships.

Re: How to Pass a Programming Interview

#390

Post by bottled_poe » Wed, Mar 09, 2016, 2:07 AM UTC

jerf wrote: post #384

tomjen3 wrote: post #197

Earlier quoted context omitted.

What if it isn't stupid code? What if it is straight forward and simple and looks correct but is just slow because it has to traverse a list instead of using a hash-table or some other data-structure. You can't get there by intermediate steps, you have to rip out the code that uses it and rewrite it with a hashmap. You can only do that if you know the space complexity and when a hash and a list is appropriate.

"You can only do that if you know the space complexity and when a hash and a list is appropriate." You seem to be confusing "knows how to say 'oh of enn squared'" with "the loop gets slow when I iterate over a lot of things". One is generally a product of education, the other, merely experience. The idea that a thing can only be learned in a classroom is perhaps in the top ten most pernicious ideas in the modern worl…

I've found that employees who are able to discuss the benefits of certain data structures and their associated time complexity are generally able to solve problems quicker than those who struggle to discuss these fundamentals. That said, the thing that matters most to me when hiring programmers is proof that they can write decent code.