How to pass an interview for a programming position
Surprisingly little importance is placed on programming expertise when it comes to passing interviews. In order to be a productive programmer, you must be able to solve large, sprawling problems over weeks or months. In contrast, each interview question takes less than one hour. Therefore, in order to perform well in an interview, you must be able to solve small problems quickly while articulating your thoughts clearly. This skill is distinct. In addition, interviewers are frequently untrained and inattentive (they would rather be programming) and ask questions that are unrelated to the actual work. They introduce prejudice, pattern matching, and a lack of standardization.
Good news is that interviewing is a skill that can be acquired. We have had success teaching candidates how to perform better during interviews. In fact, diligence, not raw talent, correlates most strongly with developer candidates.
Good programmers should not be required to acquire special interviewing skills in order to perform well in job interviews. The status quo, however, is as it is.
1. enjoy yourself
Interview outcomes are greatly affected by enthusiasm. Approximately fifty percent of Developer candidates who fail interviews with companies do so for non-technical reasons. This is typically referred to by the company as 'poor cultural fit.' However, nine times out of ten, culture fit simply entails enthusiasm for the work of a company. Employers seek applicants who are enthusiastic about their mission. In many companies, this carries equal weight to technical expertise. This makes sense. Motivated employees will be happier and more productive.
The issue is that it is possible to fake this. Some candidates are able to persuade every employer they speak with that the position is their dream job, while others (who are genuinely enthusiastic) are unable to do so. This has occurred repeatedly. Everyone must become more adept at expressing their enthusiasm. This does not authorize lying. But interviewing is like dating. No one wants to be told on a first date that they are merely one of many options, despite the fact that this is typically the case. Likewise, the majority of programmers are only interested in a well-paying position. However, it is improper to state this in an interview. The best strategy is to prepare notes about what excites you about the company prior to the interview, and bring this up when each interviewer asks if you have any questions. Read the company's most recent blog posts and press releases, and make note of the ones that you find intriguing.
This concept appears simple. I assume you are nodding in agreement as you read this. But (as anyone who has ever participated in an interview can attest), a surprisingly small number of applicants do so. Preparing notes on the reasons why you find a company intriguing will increase your passing rate. You can even consult your notes during the interview. Notes brought in advance demonstrate readiness.
2. examine typical interview techniques
The majority of interview questions involve data structures and algorithms. This is the truth, for better or worse. Most companies will benefit from your familiarity with the following algorithms and data structures, although expertise is not required.
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 one's background, this list may appear trivial or extremely daunting. This is the exact point. These concepts are far more prevalent in job interviews than in actual web development. If you are self-taught or have been out of school for several years and these concepts are unfamiliar to you, studying them will help you perform better in interviews. Refreshing your knowledge will be helpful even if you already possess this information. A startlingly high proportion of interview questions are reducible to breadth-first search or the utilization of a hash table to count uniques. You must understand how a hash table is implemented and be capable of writing a BFS cold.
These things are not as difficult to learn as many of the people with whom we converse fear. This can be off-putting. Algorithms are typically described in academic language. The architecture of a modern web application is, however, the most complex item on this list. You can learn these things if you can (properly) construct a web application. The book The Algorithm Design Manual by Steven Skiena is the recommended resource. These topics are presented in a straightforward manner in Chapters 3 through 5. It utilizes C and some math syntax, but it explains the material well. Additionally, Coursera offers a number of excellent courses in algorithm design. Particularly, this one focuses on the concepts that are essential for interviews.
Studying algorithms and data structures is beneficial not only because the material is covered in interviews, but also because the approach taken to problems in an algorithm course is the most effective approach for interviews. Algorithm study will prepare you for an interview.
3. ask your interviewer for assistance
Interviewers assist job candidates. They provide hints, respond to suggestions, and guide the process in general. However, not all candidates are helped equally. Certain programmers are able to receive significant assistance without the interviewer holding it against them. Any hints given to others are evaluated harshly. You desire assistance.
Process and communication are central to this. If the interviewer likes your process and you communicate effectively with them, they will not object to assisting you. By following a thorough procedure, you can increase the likelihood of this happening. I suggest the following actions:
Ask questions
Talk through a brute-force solution
Talk through an optimized solution
Write code
After you are asked an interview question, you should begin by elaborating on its meaning. The time has come to be meticulous. Clarify every possible area of ambiguity. Investigate edge cases. Bring up specific examples of inputs, and ensure that your understanding of the expected output is accurate. Ask questions even if you are nearly certain you already know the answers. This is beneficial because it allows you to consider edge cases and fully specify the problem before beginning to solve it. Additionally, it gives you time to collect your thoughts before you begin to solve the problem.
Next, you must describe the simplest brute-force solution to the problem that you can imagine. You should converse rather than immediately begin coding because you can move more quickly when speaking and the interviewer will be more engaged. If the interviewer is actively involved, they will offer advice. However, you will miss this opportunity if you retreat into writing code.
Assuming that the brute-force solution to the problem is too obvious or incorrect, candidates frequently skip the brute-force step. This is incorrect. Always provide a solution to the problem for which you have been asked (even if it takes exponential time, or an NSA super computer). When you have described a brute-force solution, ask the interviewer if they want you to implement it or if you can come up with a more efficient solution. Typically, you will be instructed to develop a more efficient solution.
Similar to brute force, the procedure for the more efficient solution is the same. Again, communicate with the interviewer and do not write code. With any luck, the question will be similar to something you've already seen, and you'll already know the answer. In the event that this is not the case, it is helpful to consider what problems you've encountered that are most similar and bring them up during the interview. The majority of interview questions are applications of classic computer science algorithms that are only slightly obscured. If you initiate the process, the interviewer will frequently direct you to this algorithm.
After you and your interviewer have agreed that your solution is satisfactory, you should then write your code. This may be done on a computer or a whiteboard, depending on the company. However, given that you've already devised a solution, this should be relatively straightforward. For bonus points, inquire if the interviewer would like you to complete tests.
4. discuss compromises
The majority of programming interviews consist of programming questions, and that is what I've discussed thus far. However, system design questions may also be encountered. Especially for more experienced candidates, employers appear to favor these. A system design question asks the candidate how they would design a complex real-world system. Designing Google Maps, a social network, or an API for a bank are examples of such endeavors.
The first observation is that specific knowledge is required to answer system design questions. Obviously, nobody actually anticipates you to design Google Maps (that took a lot of people a long time). They do, however, anticipate that you have some understanding of the design's components. The good news is that these questions typically focus on web backends, so you can make substantial progress by reading about this subject. A list of things to comprehend that is incomplete is:
HTTP (at the protocol level)
Databases (indexes, query planning)
CDNs Caching (LRU cache, memcached, redis)
Load balancers
Distributed worker systems
These concepts must be grasped by you. Moreover, you must comprehend how they fit together to form actual systems. Reading about how other engineers have utilized the concepts is the best way to acquire this knowledge. This topic is well covered on the blog High Scalability. It publishes in-depth descriptions of the back-end architecture of actual corporations. You can read about the practical applications of each of the aforementioned concepts.
After completing this reading, answering system design-related questions becomes a matter of procedure. Beginning at the top, proceed downwards. At each level, ask your interviewer for specifications (should you suggest a simple starting point or describe how a mature system might appear?) and discuss a number of possibilities (applying the ideas from your reading). In your design, it is vital to discuss tradeoffs. Your interviewer is less concerned with whether your design is good in and of itself and more concerned with your ability to discuss the trade-offs (positives and negatives) of your decisions. Repeat this.
5. feature outcomes
Experience questions are the third type of question you may encounter. Here, the interviewer will ask you to describe a previous programming project you completed. Many engineers make the error of discussing a technically fascinating side-project in response to this question. Many programmers prefer to discuss the implementation of neural network classifiers or the creation of Twitter grammar bots. It is difficult for the interviewer to evaluate the scope of these responses. There is no way for the interviewer to determine if you are one of the many candidates who exaggerate simple side projects (some of which never actually worked).
The solution is to select a project that yielded results and emphasize those outcomes. This frequently necessitates choosing a less technically intriguing project, but it is worthwhile. Consider (ahead of time) the programming you've created that has had the greatest impact in the real world. If you've created an iOS game with 50,000 downloads, it's a viable option. If you've written an administrative interface during an internship that has been deployed to the entire administrative staff, the deployment makes it an interesting topic of conversation. Selecting a practical project will also demonstrate to the employer that you are dedicated to actual work. Companies screen against the anti-pattern of a programmer who is overly focused on cool technology (these programmers are sometimes not productive).
use a dynamic tone while mentioning c
During interviews, I recommend using a dynamic language such as Python, Ruby, or JavaScript. Obviously, you should use the language in which you are most proficient. Many interviewees, however, believe that C, C++, and Java are the 'real' programming languages and attempt to conduct their interviews in these languages. Several classic interviewing books recommend Java or C++ to programmers. We've discovered that this is bad advice, at least for startups. Candidates perform better when utilizing dynamic linguistics. This is true, in my opinion, due to the concise syntax, flexible typing, and list and hash literals of dynamic languages. These languages are tolerant. This can be a disadvantage when writing complex systems (this is a highly debatable point), but it's great when trying to fit a binary search algorithm onto a whiteboard.
It is advantageous to mention work in other languages, regardless of the language employed. Individuals who only speak a single language are a red flag for employers. If you only know a single language, you must rely on your proficiency in that tongue. However, if you have performed work or completed side projects in multiple languages, be sure to mention this to your interviewers. If you have experience with lower-level programming languages such as C, C++, Go, or Rust, discussing this will be especially beneficial.
Java, C#, and PHP present a difficult situation. According to our previous blog post, we've discovered bias against these languages in startup companies. We have data indicating that programmers using these languages have a lower rate of interview success. This is unfair, but the truth nonetheless. If you have other options, I advise against using these languages in startup interviews.
7. practice, practice, practice
By practicing answering questions, you can become a much better interviewee. This is true due to the fact that interviews are stressful, but stress impairs performance. Practice is the solution. Exposure reduces the anxiety associated with interviewing. With experience, this occurs naturally Even within a single job search, candidates frequently fail their initial interviews before passing more as their confidence increases. If you struggle with stress, I recommend that you practice interview stress in order to expedite this process. Obtain a list of interview questions (Cracking the Coding Interview is a good source) and answer them. Set a 20-minute timer for each question and respond quickly. Practice writing the answers on a whiteboard (some companies do not require this, but it is the worst-case scenario, so you should practice). A whiteboard can be simulated fairly well with a pen and paper. If you have friends who can help you prepare, it is a good idea to interview each other in turn. Reading a large number of interview questions has the added advantage of providing you with interviewing strategies. An astonishing number of questions are recycled (in full or in part).
This is beneficial for even seasoned (and stress-free) candidates. Interviewing is a skill that is fundamentally distinct from programming and is susceptible to atrophy. However, experienced programmers often (reasonably) believe they should not have to prepare for interviews. They studied less. This is why junior candidates frequently perform better than their more experienced counterparts on interview questions. Companies are aware of this, and paradoxically, we have heard from a few that they lower the bar for experienced candidates on programming questions.
describe qualifications
Credentials bias interviewers. Developer candidates who have worked for a top company or attended a top school are 30% more likely to pass interviews than programmers who lack these qualifications (for a given level of performance on our credential-blind screen). I'm not fond of this. It's not meritocratic and it stinks, but if you have these credentials, it's in your best interest to make sure your interviewers are aware of them. You cannot believe they will read your resume.
place offers in order
If you've ever read advice on fund-raising for founders, you'll know that getting the first venture capitalist to make an investment offer is the most difficult step. As soon as you receive one offer, numerous others follow. The same applies to job offers. Be sure to mention this in interviews if you have a job offer. Mentioning other offers during an interview significantly favors your candidacy.
This brings up the strategy of creating a list of the companies in which you are interested and scheduling interviews in reverse order of interest. You will have a greater chance of receiving an offer from your top choice if you perform well early in the process. You should do so.
conclusion
Interview success requires skill. Being a skilled programmer is beneficial, but it is only part of the equation. Everyone fails some interviews, but adequate preparation can help everyone pass more. Research facilitates enthusiasm, which is of paramount importance. As many programmers fail for lack of motivation as for technical reasons. During interviews, interviewers assist candidates, and they will assist you if you follow a good process and communicate clearly. Always, practice helps. Reading a large quantity of interview questions and acclimating yourself to interview anxiety will result in more job offers.
This is not an ideal circumstance. Preparing for interviews is time-consuming, and requiring programmers to acquire skills other than developing excellent software is a waste of everyone's time. Companies should modify their interview procedures to be less biased by academic CS, memorized facts, and rehearsed interview procedures.Without jumping through these hoops, we'd love to help you land a job at a startup. This is the beginning point. The status quo, however, is as it is. Programmers must know how to prepare until this situation changes.