How to Pass a Programming Interview • Hacker News Board

Re: How to Pass a Programming Interview

#541

Post by rhizome » Wed, Mar 09, 2016, 10:47 PM UTC

NotSammyHagar wrote: post #427

rhizome wrote: post #310

Earlier quoted context omitted.

This is special pleading, though, right? It being relevant to "any" large scale project really just means that projects can get big enough for it to matter, but how many jobs involve this family of software? How many interviews for positions directly related? Very few, I would guess.

I find myself having to think about efficiency at least a couple times a week. I'm working on database implementation, and in the query processor we have to consider all the time how to evaluate various things efficiently.

Taking this at face value, were any of the techniques you use in these tasks directly addressed during your interview there?

Re: How to Pass a Programming Interview

#542

Post by sratner » Wed, Mar 09, 2016, 11:15 PM UTC

braythwayt wrote: post #486

sratner wrote: post #135

Earlier quoted context omitted.

Yet it is certainly false that if you are able to get CS basics right, you will be any good at deep engineering.

I hope you mean that: It is certainly false that if you are able to get CS basics right, you will NECESSARILY be any good at deep engineering. There are people who get the basics right and are good at deep engineering. The question is whether one predicts the other.

Right; my "false" applies to the entire statement (if p then q).

Re: How to Pass a Programming Interview

#543

Post by Retra » Thu, Mar 10, 2016, 12:01 AM UTC

sgift wrote: post #443

Retra wrote: post #398

Earlier quoted context omitted.

It demonstrates that you have a passing familiarity with probably _the_ most fundamental tool of the trade.

The most fundamental tool of the trade is a profiler. The tool which is used in reality to find performance problems, unlike BigO, which is used in theory to find performance problems. Does BigO help? Sure. Is it the silver bullet people seem to think it is? No.

It's not a silver bullet, it's only a model of the problem. If you profiler tells you some code is slow, you can model why it must be slow by using big-O. In fact it's the standard way of explaining such things. Without it, you must spend your time babbling about special cases.

It's like, yeah, you don't "technically" need to know any 2+ syllable words to be a programmer, but you're really not helping yourself by avoiding them.

Re: How to Pass a Programming Interview

#544

Post by democracy » Thu, Mar 10, 2016, 1:19 AM UTC

digler999 wrote: post #346

pessimizer wrote: post #200

Earlier quoted context omitted.

Honestly, I consider an instinct for complexity analysis the most important thing I learned in school, and the thing that I've gotten the most use out of. I don't know what case you're making here: are you saying that high-level architecture is so hard that choosing a map or a hashmap should be a coinflip, or the one you see first? Having had some criteria for making the choice makes my life a lot better when everybo…

To me it was a bunch of rote memorization, just like a biology course. I never - never - have needed to know how bubblesort/heapsort/mergesort actually work , except to appease interviewers. I'm not saying I'm pro writing-inefficient-code, but if you want to talk big-O during an interview, I"m going to roll my eyes about as much as you asking me who the 19th president was.

I ask such questions at the end of an interview, but mostly to see the sanity/reaction or thinking process - wrong answer would do, rolling eyes - would not :)

Re: How to Pass a Programming Interview

#545

Post by mattkrause » Thu, Mar 10, 2016, 3:42 AM UTC

eiopa wrote: post #214

oriolid wrote: post #112

Earlier quoted context omitted.

It is widely believed that if you are able to do deep engineering you should also be able to get the basics right. It takes a lot of time evaluate a real world project and most of applicants would not agree to do one anyway, so basic CS is the easy approximation.

What makes implementing qsort/bsearch/etc "the basics"? It seems rather arbitrary, and it mostly measures how well you are able to recite from CS books.

The weird thing is that some of the "basics" aren't even particularly basic. Finding cycles in a linked list was an open research problem for a while. One can argue that interviewees need to know about the Tortise and Hare algorithm, but it's crazy to think that someone who hasn't should be able to come up with it on the spot.

Re: How to Pass a Programming Interview

#546

Post by yoklov » Thu, Mar 10, 2016, 7:30 AM UTC

BinaryIdiot wrote: post #114

> This situation is not ideal. Preparing for interviews is work, and forcing programmers to learn skills other than building great software wastes everyone’s time. Companies should improve their interview processes to be less biased by academic CS, memorized facts, and rehearsed interview processes. This is what we’re doing at Triplebyte. Thank you! This is a good write up and just like it concludes it's far from ide…

I've always heard there's a substantial legal risk in saying anything other than 'no'. Not sure how true it is, though.

Re: How to Pass a Programming Interview

#547

Post by yoklov » Thu, Mar 10, 2016, 7:33 AM UTC

cableshaft wrote: post #201

illicium wrote: post #69

Earlier quoted context omitted.

> Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? "Please arrange these colors in complementary, analogous, and triadic color schemes". This is color theory 101 -- something every visual designer should now. > Why is red font on blue background bad, please justify? Again, a valid question. It all depends on the brightness/saturation of the colors, and…

I have a portfolio of past work (I made games that are still available, I even bring an iPad with them playable on them). I still get asked a ton of technical questions, and I'm lucky if I can even show them my past projects, because they never trust that I was the actual programmer on these projects (even though in the credits for a couple of them it says 'Lead Programmer: [cableshaft]'). It's a totally broken perce…

Why wouldn't they trust you? Sounds bizarre. Especially if you're listed in the credits.

Re: How to Pass a Programming Interview

#548

Post by cyphar » Thu, Mar 10, 2016, 11:32 AM UTC

krackers wrote: post #422

eranation wrote: post #415

Earlier quoted context omitted.

My bad, I meant for a variant of the question that uses chars and not numbers. With numbers the hashmap will be still constant memory just like you said, but it's a big constant (2^32) - but still O(1) memory. This is because the input is of ints, and it can only be one of ~2^32 numbers for either values or keys. And since we only count the number, we don't need a map, we can just use a set (a map with boolean value…

Ah that makes sense. And what was the intended solution for finding if an unsorted list of numbers is an arithmetic series in constant memory? You say it's the same xor trick, but I don't see how it's applicable. Do you xor all the values with all the values shifted over by the common difference?

"arithmetic series" and "unsorted list" are mutually exclusive statements. Unless you mean something like "the sorted version is an arithmetic series".

Re: How to Pass a Programming Interview

#549

Post by eranation » Thu, Mar 10, 2016, 1:41 PM UTC

cyphar wrote: post #548

krackers wrote: post #422

Earlier quoted context omitted.

Ah that makes sense. And what was the intended solution for finding if an unsorted list of numbers is an arithmetic series in constant memory? You say it's the same xor trick, but I don't see how it's applicable. Do you xor all the values with all the values shifted over by the common difference?

"arithmetic series" and "unsorted list" are mutually exclusive statements. Unless you mean something like "the sorted version is an arithmetic series".

Yes Or a randomly shuffled arithmetic series

Re: How to Pass a Programming Interview

#550

Post by krzyk » Thu, Mar 10, 2016, 1:59 PM UTC

cgh wrote: post #362

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.

Almost all of those are handled by a standard library, so why bother. When issue arises then you look for a book/website and fix the problem. Source: Doing backend (and some frontend) web stuff for the last 10 years.