How to pass a programming interview

[Nytro]

How to pass a programming interview

 

by Ammon Bartram

 

 

This post started as the preparation material we send to our candidates, but we decided to post it publicly.

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill [1]. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Running Triplebyte, I see this clearly. We interview engineers without looking at resumes, and fast-track them to on-sites at YC companies. We’ve interviewed over 1000 programmers in the last nine months. We focus heavily on practical programming, and let candidates pick one of several ways to be evaluated. This means we work with many (very talented) programmers without formal CS training. Many of these people do poorly on interviews. They eat large sprawling problems for breakfast, but they balk at 45-min algorithm challenges.

The good news is that interviewing is a skill that can be learned. We’ve had success teaching candidates to do better on interviews. Indeed, the quality that most correlates with a Triplebyte candidate passing interviews at YC companies is not raw talent, but rather diligence. 

I fundamentally do not believe that good programmers should have to learn special interviewing skills to do well on interviews. But the status quo is what it is. We’re working at Triplebyte to change this. If you’re interested in what we’re doing, we’d love you to check out our process. In the meantime, if you do want to get better at interviewing, this blog post describes how we think you can most effectively do so. 

1. Be enthusiastic

Enthusiasm has a huge impact on interview results. About 50% of the Triplebyte candidates who fail interviews at companies fail for non-technical reasons. This is usually described by the company as a “poor culture fit”. Nine times out of ten, however, culture fit just means enthusiasm for what a company does. Companies want candidates who are excited about their mission. This carries as much weight at many companies as technical skill. This makes sense. Excited employees will be happier and work harder.

The problem is that this can be faked. Some candidates manage to convince every company they talk to that it’s their dream job, while others (who are genuinely excited) fail to convince anyone. We’ve seen this again and again. The solution is for everyone to get better at showing their enthusiasm. This is not permission to lie. But interviewing is like dating. No one wants to be told on a first date that they are one option among many, even though this is usually the case. Similarly, most programmers just want a good job with a good paycheck. But stating this in an interview is a mistake. The best approach is to prepare notes before an interview about what you find exciting about the company, and bring this up with each interviewer when they ask if you have any questions. A good source of ideas is to read the company’s recent blog posts and press releases and note the ones you find exciting.

This idea seems facile. I imagine you are nodding along as you read this. But (as anyone who has ever interviewed can tell you) a surprisingly small percentage of applicants do this. Carefully preparing notes on why you find a company exciting really will increase your pass rate. You can even reference the notes during the interview. Bringing prepared notes shows preparation.

2. Study common interview concepts

A large percentage of interview questions feature data structures and algorithms. For better or worse, this is the truth. We gather question details from our candidates who interview at YC companies (we’ll be doing a in-depth analysis of this data in a future article), and algorithm questions make up over 70% of the questions that are asked. You do not need to be an expert, but knowing the following list of algorithms and data structures will help at most companies.

• 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

Depending on your background, this list may look trivial, or may look totally intimidating. That’s exactly the point. These are concepts that are far more common in interviews than they are in production web programming. If you’re self-taught or years out of school and these concepts are not familiar to you, you will do better in interviews if you study them. Even if you do know these things, refreshing your knowledge will help. A startlingly high percentage of interview questions reduce to breadth-first search or the use of a hash table to count uniques. You need to be able to write a BFS cold, and you need to understand how a hash table is implemented.

Learning these things is not as hard as many of the people we talk to fear. Algorithms are usually described in academic language, and this can be off-putting. But at its core, nothing on this list is more complicated than the architecture of a modern web app. If you can build a web app (well), you can learn these things. The resource that I recommend is the book The Algorithm Design Manual by Steven Skiena. Chapters 3 through 5 do a great job of going over this material, in a straightforward way. It does use C and some math syntax, but it explains the material well. Coursera also has several good algorithms courses. This one, in particular, focuses on the concepts that are important in interviews.

Studying algorithms and data structures helps not only because the material comes up in interviews, but also because the approach to problems taken in an algorithm course is the same approach that works best in interviews. Studying algorithms will get you in an interview mindset.

3. Get help from your interviewer

Interviewers help candidates. They give hints, they respond to ideas, and they generally guide the process. But they don’t help all candidates equally. Some programmers are able to extract significant help, without the interviewer holding it against them. Others are judged harshly for any hints they are given. You want to be helped.

This comes down to process and communication. If the interviewer likes your process and you communicate well with them, they will not mind helping. You can make this more likely by following a careful process. The steps I recommend are:

1. Ask questions
2. Talk through a brute-force solution
3. Talk through an optimized solution
4. Write code

After you are asked an interview question, start by clarifying what was asked. This is the time to be pedantic. Clarify every ambiguity you can think of. Ask about edge cases. Bring up specific examples of input, and make sure you are correct about the expected output. Ask questions even if you’re almost sure you know the answers. This is useful because it gives you a chance to come up with edge cases and fully spec the problem (seeing how you handle edge-cases is one of the main things that interviewers look for when evaluating an interview), and also because it gives you a minute to collect your thoughts before you need to start solving the problem.

Next, you should talk through the simplest brute-force solution to the problem that you can think of. You should talk, rather than jump right into coding, because you can move faster when talking, and it’s more engaging for the interviewer. If the interviewer is engaged, they will step in and offer pointers. If you retreat into writing code, however, you'll miss this opportunity. 

Candidates often skip the brute-force step, assuming that the brute-force solution to the problem is too obvious, or wrong. This is a mistake. Make sure that you always give a solution to the problem you’ve been asked (even if it takes exponential time, or an NSA super computer). When you’ve described a brute-force solution, ask the interviewer if they would like you to implement it, or come up with more efficient solution. Normally they will tell you to come up with a more efficient solution.

The process for the more efficient solution is the same as for the brute force. Again talk, don’t write code, and bounce ideas off of the interviewer. Hopefully, the question will be similar to something you’ve seen, and you’ll know the answer. If that is not the case, it’s useful to think of what problems you’ve seen that are most similar, and bring these up with the interviewer. Most interview questions are slightly-obscured applications of classic CS algorithms. The interviewer will often guide you to this algorithm, but only if you begin the process.

Finally, after both you and your interviewer agree that you have a good solution, you should write your code. Depending on the company, this may be on a computer or a whiteboard. But because you’ve already come up with the solution, this should be fairly straightforward. For extra points, ask your interviewer if they would like you to write tests.

4. Talk about trade-offs

Programming interviews are primarily made up of programming questions, and that is what I have talked about so far. However, you may also encounter system design questions. Companies seem to like these especially for more experienced candidates. In a system design question, the candidate is asked how he or she would design a complex real-world system. Examples include designing Google maps, designing a social network, or designing an API for a bank.

The first observation is that answering system design questions requires some specific knowledge. Obviously no one actually expects you to design Google maps (that took a lot of people a long time). But they do expect you to have some insight into aspects of such a design. The good news is that these questions usually focus on web backends, so you can make a lot of progress by reading about this area. An incomplete list of things to understand is: 

• HTTP (at the protocol level)
• Databases (indexes, query planning)
• CDNs
• Caching (LRU cache, memcached, redis)
• Load balancers
• Distributed worker systems

You need to understand these concepts. But more importantly, you need to understand how they fit together to form real systems. The best way to learn this is to read about how other engineers have used the concepts. The blog High Scalability is a great resource for this. It publishes detailed write-ups of the back-end architecture at real companies. You can read about how every concept on the list above is used in real systems. 

Once you’ve done this reading, answering system design questions is a matter of process. Start at the highest level, and move downward. At each level, ask your interviewer for specifications (should you suggest a simple starting point, or talk about what a mature system might look like?) and talk about several options (applying the ideas from your reading). Discussing tradeoffs in your design is key. Your interviewer cares less about whether your design is good in itself, and more about whether you are able to talk about the trade-offs (positives and negatives) of your decisions. Practice this.

5. Highlight results

The third type of question you may encounter is the experience question. This is where the interviewer asks you to talk about a programming project that you completed in the past. The mistake that many engineers make on this question is to talk about a technically interesting side-project. Many programmers choose to talk about implementing a neural network classifier, or writing a Twitter grammar bot. These are bad choices because it’s very hard for the interviewer to judge their scope. Many candidates exaggerate simple side projects (sometimes that never actually worked), and the interviewer has no way to tell if you are doing this.

The solution is to choose a project that produced results, and highlight the results. This often involves picking a less technically interesting project, but it’s worth it. Think (ahead of time) of the programming you’ve done that had the largest real-world impact. If you’ve written a iOS game, and 50k people have downloaded it, the download number makes it a good option. If you’ve written an admin interface during an internship that was deployed to the entire admin staff, the deployment makes it a good thing to talk about. Selecting a practical project will also communicate to the company that you focus on actual work. Programmer too focused on interesting tech is an anti-pattern that companies screen against (these programmers are sometimes not productive).

6. Use a dynamic language, but mention C

I recommend that you use a dynamic language like Python, Ruby or JavaScript during interviews. Of course, you should use whatever language you know best. But we find that many people try interviewing in C , C++ or Java, under the impression these are the “real’ programming languages. Several classic books on interviewing recommend that programmers choose Java or C++. At startups at least, we’ve found that this is bad advice. Candidates do better when using dynamic languages. This is true, I think, because of dynamic languages’ compact syntax, flexible typing, and list and hash literals. They are permissive languages. This can be a liability when writing complex systems (a highly debatable point), but it’s great when trying to cram binary search onto a whiteboard.

No matter what language you use, it’s helpful to mention work in other languages. An anti-pattern that companies screen against is people who only know one language. If you do only know one language, you have to rely on your strength in that language. But if you’ve done work or side-projects in multiple languages, be sure to bring this up when talking to your interviewers. If you have worked in lower-level languages like C, C++, Go, or Rust, talking about this will particularly help.

Java, C# and PHP are a problematic case. As we described in our last blog post, we’ve uncovered bias against these languages in startups. We have data showing that programmers using these languages in the interview pass at a lower rate. This is not fair, but it is the truth. If you have other options, I recommend against using these languages in interviews with startups.

7. Practice, practice, practice

You can get much better at interviewing by practicing answering questions. This is true because interviews are stressful, but stress harms performance. The solution is practice. Interviewing becomes less stressful with exposure. This happens naturally with experience. Even within a single job search, we find that candidates often fail their initial interviews, and then pass more as their confidence builds. If stress is something you struggle with, I recommend that you jumpstart this process by practicing interview stress. Get a list of interview questions (the book Cracking the Coding Interview is one good source) and solve them. Set a 20-minute timer on each question, and race to answer. Practice writing the answers on a whiteboard (not all companies require this, but it’s the worst case, so you should practice it). A pen on paper is a pretty good simulation of a whiteboard. If you have friends who can help you prepare, taking turns interviewing each other is great. Reading a lot of interview questions has the added benefit of providing you ideas to use when in actual interviews. A surprising number of questions are re-used (in full or in part).

Even experienced (and stress-free) candidates will benefit from this. Interviewing is a fundamentally different skill from working as a programmer, and it can atrophy. But experienced programers often (reasonably) feel that they should not have to prepare for interviews. They study less. This is why junior candidates often actually do better on interview questions than experienced candidates. Companies know this, and, paradoxically, some tell us they set lower bars on the programming questions for experienced candidates.

8. Mention credentials

Credentials bias interviewers. Triplebyte 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). I don’t like this. It’s not meritocratic and it sucks, but if you have these credentials, it’s in your interest to make sure that your interviewers know this. You can’t trust that they’ll read your resume.

9. Line up offers

If you’ve ever read fund-raising advice for founders, you’ll know that getting the 1st VC to make an investment offer is the hardest part. Once you have one offer, more come pouring in. The same is true of job offers. If you already have an offer, be sure to mention this in interviews. Mentioning other offers in an interview heavily biases the interviewer in your favor.

This brings up the strategy of making a list of the companies you’re interested in, and setting up interviews inreverse order of interest. Doing well earlier in the process will increase your probability of getting an offer from you number one choice. You should do this.

Conclusion

Passing interviews is a skill. Being a great programmer helps, but it’s only part of the picture. Everyone fails some of their interviews, and preparing properly can help everyone pass more. Enthusiasm is paramount, and research helps with this. As many programmers fail for lacking enthusiasm as fail for technical reasons. Interviewers help candidates during interviews, and if you follow a good process and communicate clearly, they will help you. Practice always helps. Reading lots of interview questions and inuring yourself to interview stress will lead to more offers.

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. We help programmers get jobs without looking at resumes. We let programmers pick one of several areas in which to be evaluated, and we study and improve our process over time. We’d love to help you get a job at a startup, without jumping through these hoops. You can get started here. But the status quo is what it is. Until this changes, programmers should know how to prepare. 

Thanks to Jared Friedman, Emmett Shear, Garry Tan, Alexis Ohanian and Daniel Gackle for reading drafts of this.

 

Sursa: http://blog.triplebyte.com/how-to-pass-a-programming-interview

[tjt]

Articolul e un copy paste cu mici modificari din cartea Cracking the Code Interview.

 

Sa treci de un interviu e usor, greul incepe dupa.

[DrMengele]

Mie mi se rupe de cum se poata omu la interviu.Imi dau seama in perioada de proba ce si cum.Multi au emotii sau sunt ok la interviu dar dupa 8h de codat nu mai sunt in stare de nimic.

[tjt]

12 minutes ago, Dr.Mengele said:

Mie mi se rupe de cum se poata omu la interviu.Imi dau seama in perioada de proba ce si cum.Multi au emotii sau sunt ok la interviu dar dupa 8h de codat nu mai sunt in stare de nimic.

8h de codat ? Cine face coding in sensul asta al cuvantului ? 

 

Multi programatori in ziua de azi in "8h de munca"  :

• 1 ora stau pe facebook;
• 1 ora pe 9gag, youtube sau orice alt site;
• 1 ora isi bat capul cum se face respectiva chestie;
• 3 ore cauta pe stackoverflow raspunsul;
• 2 ore baga cod copy-paste de pe forumuri si alte surse.

Din cauza asta au inceput sa fie cautati security testeri, software testeri si in general tot ce tine de testarea unui produs software. Multi programatori au probleme in a isi face cum trebuie task-urile.

Edited March 9, 2016 by tjt

[QuoVadis]

De asta fiecare contract mai "modern" care este pe perioada nedefinita de obicei include un "probation" period, timp in care poate sa ti se dea jet fara nici o despagubire salariala, justificare, etc. Cu cat e postul mai important/mai sus, cu atat e probation period-ul mai lung. E un fel de "honeymoon" intre angajator si angajat.. si daca nu se potrivesc atunci Cand am aplicat pentru job-ul meu actual scria in descriere ca probation period-ul este de 6 luni de zile.. insa de obicei se pune undeva la 1-3 luni.

 

[Nytro]

Da, dar exista si avantajul ca daca tie ca angajat nu iti place, iti iei jucariile si pleci fara probleme.

[DrMengele]

@tjt:Ai dreptate,dar eu ca patron nu prea am de unde alege,sunt foarte putini cei care sunt pasionati si isi iau munca in serios.Chiar ma gandesc serios sa ii dau pe toti afara si sa bag proiectele pe upwork.Am avut la interviu oameni care au gatat facultatea cu medie peste 9 si nu stiu sa scrie o clasa corect.

 

Nu stiu daca chestia asta e doar in ro sau peste tot.Am fost si eu la randul meu angajat de multe ori stateam peste program,scriam cod si in pauza de masa.

Edited March 9, 2016 by Dr.Mengele

[fallen_angel]

Dacă te gândești să-ți dai oamenii afară și să bagi proiectele pe upwork, ești mare patron.

[DrMengele]

Reduc cu mult costurile,mai bine indieni de cat romani idioti cu multe pretentii.

[SticKyWoX]

Nu am stat sa citesc articolul, dar imi permit sa-mi dau cu parerea.

Ca sa treci cu brio de un interviu pentru orice job ce tine de programare, trebuie sa ai bun simt si sa stii sa faci treaba. Restul sunt derivate.

[tjt]

57 minutes ago, Dr.Mengele said:

@tjt:Ai dreptate,dar eu ca patron nu prea am de unde alege,sunt foarte putini cei care sunt pasionati si isi iau munca in serios.Chiar ma gandesc serios sa ii dau pe toti afara si sa bag proiectele pe upwork.Am avut la interviu oameni care au gatat facultatea cu medie peste 9 si nu stiu sa scrie o clasa corect.

 

Nu stiu daca chestia asta e doar in ro sau peste tot.Am fost si eu la randul meu angajat de multe ori stateam peste program,scriam cod si in pauza de masa.

E peste tot. Cunosc persoane ce au terminat facultati de it in strainatate si sunt mai slab pregatiti decat unul din Ro.

E o problema si la multi angajatori. Multi dintre ei prefera 5 persoane nu foarte bine pregatite sa lucreze la o chestie decat o persoana foarte bine pregatita. E altceva cand zici clientului 5 persoane lucreaza la produs si e altceva cand zici ca e doar o persoana. Industria IT a ajuns ceva de genul mai bine multi si prosti pt a mai scoate ceva bani de la client, decat putini si buni.

[Meteosensibilul]

Imi dau si eu cu parerea, ca tot omul: Partea cu evita C si baga-te pe alea dinamice( Python, Ruby, plm...) e bullshit. Te prezinti cu ce stii tu cel mai bine si cu ce crezi ca ti-ar placea sa faci, degeaba are briz briz daca nu iti place.

[SynTAX]

On 3/8/2016 at 10:06 PM, Dr.Mengele said:

Reduc cu mult costurile,mai bine indieni de cat romani idioti cu multe pretentii.

Imi cer scuze ca-ti zic, dar trebuie sa ai in vedere anumite lucruri, ca "patron", cum se zice.

 

1. Trebuie sa inveti limba romana. Nu ti-o zic ca un atac, dar faptul ca nu stii gramatica denota nivelul de cultura.

 

2. Nu stiu ce firma ai, cu ce te ocupi, nu ma intereseaza. Romani idioti gasesti o multime, pentru ca asta cauti tu. Daca te pui sa cauti oameni capabili, nu o sa poti sa-i platesti. Si este normal sa fie pretentiosi. 

 

3. Ca sfat: lucreaza cu indienii o luna iar apoi da-le acelas lucru romanilor sa-l lucreze. O sa-i apreciezi mai mult pe ai nostri.

[DrMengele]

56 minutes ago, SynTAX said:

Imi cer scuze ca-ti zic, dar trebuie sa ai in vedere anumite lucruri, ca "patron", cum se zice.

 

1. Trebuie sa inveti limba romana. Nu ti-o zic ca un atac, dar faptul ca nu stii gramatica denota nivelul de cultura.

 

2. Nu stiu ce firma ai, cu ce te ocupi, nu ma intereseaza. Romani idioti gasesti o multime, pentru ca asta cauti tu. Daca te pui sa cauti oameni capabili, nu o sa poti sa-i platesti. Si este normal sa fie pretentiosi. 

 

3. Ca sfat: lucreaza cu indienii o luna iar apoi da-le acelas lucru romanilor sa-l lucreze. O sa-i apreciezi mai mult pe ai nostri.

Ma refer la tipul de roman care e proaspat absolvent de facultate,cere salariu de 2500 ron dar el nu stie sa faca o schema logica si habar nu are de MVC.Ce cacat sa fac cu el,eu nu pot sa scot profit cu asemenea oameni.

[Robert1995]

56 minutes ago, Dr.Mengele said:

Ma refer la tipul de roman care e proaspat absolvent de facultate,cere salariu de 2500 ron dar el nu stie sa faca o schema logica si habar nu are de MVC.Ce cacat sa fac cu el,eu nu pot sa scot profit cu asemenea oameni.

 

Da undei cauti ? Ca is curios cum iti dai seama ca is proaspeti absolventi

[Robert1995]

11 minutes ago, badluck said:

Glumesti ? Incearca sa gasesti un programator php.

 

- Da-ti o nota la php/mysql/javascript

- 9, 10, 8

 

- Ce este o functie recursiva ? (cam ce ar trebui sa faca - hint)

- Aaaaaa, bbbbbb, c, d, sigur am folosit dar nu mai stiu pe unde si in ce context.

 

- Care este diferenta dintre un left si un inner join ?

- Eu stiu wordpress, lucrez cu linux (cpanel - ftp si file manager)

 

- De prototype ai auzit ?

- E php nu ?

 

- Ce te recomanda pentru acest job?

- Talentul si valoarea - 1500 avans, 1800 lichidare.

 

Morala? Dupa 1-2 luni actualizeaza facebook-ul: "Started working at X Company". Poate nu stim sa apreciem/platim programatorii entry, poate stiu mai mult decat afiseaza, poate ....

 

Ok, si unde ii gasesti pe astia, is curios

 

[DrMengele]

1 hour ago, badluck said:

 

 

Asta ar trebui sa fie morala discutiei.

 

Partea buna: dupa doua luni, cu o anume experienta dobandita, programatorii entry se impart in:

- angajati la MC'

- Senion Vasile Gheorghe - 5 ani experienta lucru PHP/MySQL/si alte tehnologii - parser de produse ? sigur ca da, 2 saptamani deadline - 200$ 

- se poate, pentru pretul corect se face orice

 

Tu vorbesti de programatorii competenti insa fara experienta de lucru cu clientul. Programatorii carora iti face placere sa le rasfoiesti github-ul, care comenteaza codul cu if(1==2) si folosesc bitwise/algoritmi in cod, care nu vor lucra pe un salariu bazat pe performanta, pentru ca e o chestiune de timp pana ajung sa managerieze cele mai frumoase/complexe proiecte.

Si aici apare problema micilor anteprenori: de a treia categorie de programatori nu te poti atinge - nu iti permiti sa le oferi un living cu playstation, un salariu direct proportional cu potentialul lor, o asigurare de sanatate privata, o pensie privata si alte beneficii oferite de multinationale. Tot ce poti spera e sa gasesti o persoana din a doua categorie de programatori trecuti prin experienta de lucru ca freelancer, care spune NU STIU dar VREAU SA INVAT, care a constientizat ca nu-i face pielea 1.5kE/luna insa are un scop in viata, vrea sa invete, sa se dezvolte, vrea mai mult! Care odata gasit, trebuie motivat: un bonus pe proiect, o crestere salariala bazata pe performanta, un training platit etc.

 

Citisem zilele trecute intr-un post pe forum ca cineva spunea ca prefera sa externalizeze proiectele pe upwork, freelancer la indieni. Si ii dau foarte mare dreptate, pentru frontend personal fac acelasi lucru, 99designs este mai ieftin si mai profesional ca un designer roman, care la implementare pune background-image:(imagine de 300kb.jpg) in loc sa puna un #000. 

 

Prima categorie ramane la MC sau la "sclavit" pe 1300 lei, acolo le e locul si nu intra in prezenta discutie.

 

Just my two cents.

Genial,parca suntem frati,sunt curios,din ce zona esti?Gandesti ca mine.