Question

Why are most people who just got their BS in Computer Science unable to pass coding interviews?

Answer 1

1. Bad programmers are over-represented in interviews because they don’t get jobs through former colleagues and aren’t accepted by the first places they apply to.
2. CS departments stopped failing the 30–70% of students who couldn’t program because it was bad for revenue.

Joel Spolsky writes eloquently about both topics.

In Finding Great Developers he states

for the most part, almost every hiring manager in Palo Alto right now with 1000 resumes on their desk has the same exact set of 970 resumes from the same minority of 970 incompetent people that are applying for every job in Palo Alto, and probably will be for life

Conversely, the hit rate is much higher recruiting for internships before students graduate because you’re getting a representative sample, not mostly people who haven’t passed an interview yet. This is why big companies have large internship programs.

Joel discusses the degeneration of CS education in The Perils of JavaSchools. In the good old days many people failed

I’ve seen all kinds of figures for drop-out rates in CS and they’re usually between 40% and 70%. The universities tend to see this as a waste; I think it’s just a necessary culling of the people who aren’t going to be happy or successful in programming careers.

because classes were hard as he discussed in Hitting the High Notes. CS 323 at Yale had five 2-week projects with the top quartile averaging 21 hours per assignment. On the longest those students averaged 37 hours, with the fastest finishing in 23 and slowest 77.

Most schools got rid of individual hands-on assignments like that, leading to the current situation where Joel writes

As an employer, I’ve seen that the 100% Java schools have started churning out quite a few CS graduates who are simply not smart enough to work as programmers on anything more sophisticated than Yet Another Java Accounting Application, although they did manage to squeak through the newly-dumbed-down coursework.

Answer 2

The simple answer is because they have never done it before.

I have never met a developer who writes syntactically correct code on a whiteboard in marker, at work, to solve an actual problem. I have seen pseudo code where a Senior was describing a concept to a Junior Dev or an Intern but, never something like traversing a binary tree or anything of that nature.

A whiteboard interview tells the interviewer you have practiced and/or solved enough problems of that type to recall how to do them off the top of your head. This can mean a few things.

———————————————————————————————————

If you get it correct it shows you either:

1. A developer with enough practice or experience to use these concepts in the real world.
2. Someone who has memorized enough basic algorithms and data structures and practiced writing them on a whiteboard in enough timed sessions to correctly answer their question.

If you get it wrong it shows you either:

1. You lack a variety of experience to solve the problem their business needs you to solve.
2. You get nervous coding in front of others.
3. You lack experience coding on a whiteboard.
4. You rely on your IDE or the internet to help you find libraries and fix your syntax.
5. You didn’t have the specific knowledge or maybe a potential weakness in the one or two algorithms or data structures you needed to solve the problem in the time frame you were given.

———————————————————————————————————

The problems are varied with whiteboard interviewing but, you can already see from what you gain from the interview is a small window of information about a very specific part of just one of the many skill sets a developer needs.

Let’s HYPOTHETICALLY say that a Developer’s skills are mixed 50/50 between technical and professional. Soft skills are things like your professionalism, communication skills, knowledge of the Software Development Life Cycle, your knowledge of SCRUM, ability to learn, teach, lead, and learn, your time and stress management skills to list a few.

Now your technical skills are also fairly varied depending on the role and your seniority level. So let’s go with a Full Stack Web Developer for this example. There is quite a list from front to back end and everything in between but bare minimum your gonna need a firm grasp of HTML, CSS, JavaScript, probably a server-side language like PHP, C#, Python, Java, etc, familiarity with Databases and SQL, knowledge of how servers like Apache, Nginx, TomCat, etc work, knowledge of different hosting options like AWS, Azure, etc. familiarity with whatever JS framework(s) your company is using, Version Control through Git or another VC, a familiarity with at least basic networking and system concepts, a firm understanding of object-oriented design patterns, experience in debugging concepts, experience in code refactoring, knowledgeable about different testing methodologies and experience in implementing them AND KNOWING ALGORITHMS AND DATA STRUCTURES.

Although my list isn’t comprehensive and you can argue about what belongs on there or not if you count off concepts I listed there are 10 soft skills and 14 technical ones. Knowledge of Algorithms and Data Structures are one of those subjects, so it makes up about 4% of what you need to know to be a Full Stack Developer.

Now, this IS NOT a statement saying how important or unimportant that subject is, I’m just trying to make the point that there are a lot of subjects and the whiteboard coding interview only test for one, and it does so IN AN INCOMPLETE WAY! You can not get an accurate read on a developers knowledge of Algorithms and Data Structures by asking two or three questions. You have tested a dev’s knowledge to work without access to a search engine or an IDE, tools he/she would have access to in a real-world situation.

So many people wanna blame the schools, or blame the students when maybe the process is broken? Sure, memorization skills and a strong knowledge of Algorithms and Data Structures are great things to have but, do they always signal a good developer? Is the reason about 50% of Google SE’s fail their first attempt at getting into Google because they aren’t smart enough or the fact they didn’t specifically prep for the event of having to write code on a whiteboard?

Why are more people in the industry not using coding katas? I know there is some BS about not having people work for free but, what is a coding interview if not that? Here’s my suggested interview flow:

———————————————————————————————————

1. Initial phone screen with the candidate
2. First round easy code kata to evaluate basic skills
3. Harder coding kata (depending on experience and role)
4. Bring the candidate on site for a code review and conversation

———————————————————————————————————

This will tell you so much more about your candidate. Were they able to set up the proper environment to code in? How to do they comment, how do they test, how do they design a solution, how did they deploy the solution, how optimized is the solution, was their code cohesive, could it be abstracted more, etc? You can dig deep and talk to your potential new developer/coworker about what they were thinking, why did they make the choices they did, what they wish they could’ve done with more time, what they would refactor, you can see how they respond to critical feedback, etc.

Now doesn’t that sound like a more comprehensive evaluation than you asking a candidate how to invert a binary tree off the top of their head on a white board and waiting for them to do it on the clock?

Answer 3

My colleague Pete and I had prepared for a technical interview for a web developer on our team. We two questions ready — questions that we had asked candidates multiple times before.

The candidate came in and sat down. He had a degree in Computer Science, and a long list of credentials that would prepare him for a senior level job, and we were prepared to interview a mid-level developer job (a position he was overqualified for). He came in, sat down, and Pete asked him a technical question.

Pete explained the first question, handed the candidate a dry erase marker and asked him to approach the whiteboard and get started.

This question is too easy — I’ve done this type of work all the time at my last job. We can skip this question.

The candidate said, as he handed the dry erase marker back to Pete. Pete stood surprised and in shock — we both had interviewed many other candidates and had never had someone flat out refuse to even try to answer a technical question.

We continued to discuss the problem with the candidate and finally got the candidate to attempt the problem.

The candidate got to the whiteboard and struggled to write simple code on the board.

The candidate struggled and eventually left the interview.

When the interview was finished Pete and I discussed what had happened and we figured out a valuable lesson that has stuck with me ever since.

As an interviewer, it is your job to identify candidates that are both smart and get things done. It turns out there are very few people who are both of these things that are interviewing for programming positions.

Software development is something that is difficult and that is why good programmers are in demand. Getting the skills to become an in-demand programmer actually isn’t that difficult at all.

There are only three takeaways that you need to be an in-demand developer, regardless of if you have a degree in Computer Science or not!

The developers who focus on mastering these three skills have huge advantages in their programming career. Here’s what actually matters.

• Self sufficient developers are able to achieve their coding goals on their own — making them both smart and able to get things done. Becoming a self-sufficient developer will pay off in the long term.
• Technology is constantly changing, but mastering timeless programming concepts will ensure that you have the skills to succeed — regardless of the flavors of the weak.
• Entry level developers are generally hired as an investment in potential instead of immediate payoff — go into your first position as a developer with a growth mindset and always seeking to improve your craft.

Once you understand these concepts and work improve yourself, you’ll find that you’re the type of in-demand developer who is able to pass coding interviews with ease.