How to Pass a Programming Interview

As a junior in university looking for internships this summer, I can attest that going through the programming interview process is a pretty foreign process compared to traditional interviews. I just stumbled through my first programming interview last week.

I believe in the future point 3 will be especially helpful. The hardest parts for me were trying to figure out how appropriate it was for me to be rambling as I coded (something I'm not used to doing at all), and trying to understand what was and wasn't appropriate to ask the interviewers about my code.

Time to brush up on breadth-first search and hash tables!

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 just want to see how you think and how you code" and "just talk through the problem" and "you should not learn specific problems and if you see one you know just tel your interviewer" or "cracking the code interview type of questions are banned".

But the reality is that people who apply to Google (or Apple or Amazon or Facebook or Microsoft...), are very smart, and want to work there very much, so while they can probably do well without preparation, due to the fact they will have competition with all this year's new Stanford / MIT / CMU graduates on a limited amount of positions, they take no chances. I have a friend who has a masters degree from a target school and it took him 4 attempts to get into Google. He is smart, he probably did well in the interviews, but you are being compared to others, so until he went and worked on those pretty useless skills of: practicing writing fast on a whiteboard, getting interview books and practicing tricky problems, doing a lot of online judge problems, he didn't get in. Why? because if you have two candidates, both smart, one has practiced whiteboard coding for all of the problem sets on geeksforgeeks / careercup / glassdoor, and one haven't, then even if both are presented with a new problem, most chances it might be a variant of one of those other "usual suspects". e.g. after I solved the famous water trapping problem (tough one if you don't get hints), the idea for the largest water container problem just pops to mind, and if you know that you can find the only non duplicate number in a list in O(1), then the problem of finding if an unsorted list of numbers is an arithmetic series with just O(1) memory is practically the same trick.

So think of two developers, both are awesome, both know CS and both are fast coders.

One practiced whiteboard coding and knows the XOR trick for duplicate numbers, his code for such a question will be written in 1 minute

    public int findDupe(int[] nums){
        int dup = 0;
        for (int num : nums){
            dup ^= num;
        }
        return dup;
    }

The other guy, who didn't see these kinds of problems will probably use a hashmap and x2 more lines for the same problem.

Both are O(N) time an O(1) complexity, but the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps)

Bottom line, both are good candidates, and the only reason the first one thought of the XOR solution in 1 minute without a hint is that they either saw it before (it's not that rare) or a real genius (statistically less likely, but still possible)

If you don't have enough good candidates, you might have the time and energy to really see which one of these will perform better at work using work related questions other than tricks like this.

But if you have unlimited good candidates coming in, the one that will solve it in 2 minutes will be the one that will stand out from the crowd, there is simply no other good way to filter out so many people. I'm sure they have tons of false negatives. (and probably also a few false positives, but I doubt it's too many)

So the system is broken, but also SATs and GREs are broken. Popular schools, popular jobs, will have to put filtering systems that are not only directly related to the ability to do the job. Someone at Google is simply writing CRUD apps for a living all day, I'm sure. But I'm sure his interview tested him on a much harder set of problems.

To past a sane interview with sane people, focus your mind on the "how to be a good programmer" question - programming as a cooperative human endeavor.

Of course, it may that a bit of craziness may be involved and they'll ask ridiculous little or big problems but someone with a reasonable amount of can answer those.

Or it may be that a lot of craziness is involved, things veer into bit-twiddling assembly, top management steps in unannounced to shoot random questions, suddenly syntax or whether you are "server side oriented" or whatever matters a lot - "we want the absolute best programmers on the market and we cement their loyalty by paying well under market rates..." etc.

Now, the more craziness appears, the less you'll actually want the job. But markets being what they are, you may need the job. By the end, there are no easy answers. Keeping is probably the main advice.

It gets better! After a few interviews you start to get the hang of things and can begin to read the situation and understand what's in your best interest to do. Some interviewers like to test your knowledge of C.S. curriculum like you just mentioned, others prefer a friendly person who isn't afraid to ask questions and be honest about what you can and cannot do, others prefer both.

It gets better.

You're not being compared to people who lack hundreds of hours of programming projects. You're being compared to people who have that same experience, either at a worse school, or on their own. Credentials correlate with being good, absolutely. But many, many more people lack credentials than have them. This means that there is a large number of great programmers who don't have them (I think a larger number than who do). There are also bad people with good credentials. Strong filtering on credentials harms companies who miss good programmers, and harms programmers who can't get jobs. Using credentials as one factor among many in a screening step, however, makes good sense (although we don't do this at Triplebyte because we want to force ourselves to get as good at possible at directly measuring skill).