Here in the Challenges subcategory of the forums, we have brain teasers and puzzles in code to test your scripting skills so that you can stay sharp. We also have featured challenges every week that are the types of questions featured in job interviews. For those weekly challenges we use resources like Glassdoor to ensure that our questions are actual examples (or inspired by examples) of real-world questions asked in interviews at top tech companies.
Some frequently asked questions about our code challenges include:
- How do these challenges work in in a job interview situation?
- Why do interviewers use challenges to assess job candidates?
- Why does Codecademy structure code challenges in the way that it does? (see here)
On occasion you meet a developer who seems like a solid programmer. They know their theory, they know their language. They can have a reasonable conversation about programming. But once it comes down to actually producing code they just don’t seem to be able to do it well.
You would probably think they’re a good developer if you’ld never seen them code. This is why you have to ask people to write code for you if you really want to see how good they are. It doesn’t matter if their CV looks great or they talk a great talk. If they can’t write code well you probably don’t want them on your team.
Most good programmers should be able to write out on paper a program which [solves the FizzBuzz Challenge] in a under a couple of minutes. Want to know something scary? The majority of comp-sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.
I’m not saying these people can’t write good code, but to do so they’ll take a lot longer to ship it. And in a business environment that’s exactly what you don’t want.
This sort of question won’t identify great programmers, but it will identify the weak ones. And that’s definitely a step in the right direction.
Dan Kegel had similar reflections on his experience hiring developers:
A surprisingly large fraction of applicants, even those with masters’ degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. For example, I’ve personally interviewed graduates who can’t answer “Write a loop that counts from 1 to 10” or “What’s the number after F in hexadecimal?” Less trivially, I’ve interviewed many candidates who can’t use recursion to solve a real problem. These are basic skills; anyone who lacks them probably hasn’t done much programming.
Speaking on behalf of software engineers who have to interview prospective new hires, I can safely say that we’re tired of talking to candidates who can’t program their way out of a paper bag. If you can successfully write a loop that goes from 1 to 10 in every language on your resume, can do simple arithmetic without a calculator, and can use recursion to solve a real problem, you’re already ahead of the pack!
These challenges may well be simple to some, but as Jeff Atwood (co-founder of Stack Overflow) states on his blog, Coding Horror, easy challenges are blindingly, intentionally easy, but they are also necessary:
I’m more than willing to cut freshly minted software developers slack at the beginning of their career. Everybody has to start somewhere. But I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That’s a slap in the face to anyone who writes software for a living.
The vast divide between those who can program and those who cannot program is well known. I assumed anyone applying for a job as a programmer had already crossed this chasm. Apparently this is not a reasonable assumption to make. Apparently, FizzBuzz style screening is required to keep interviewers from wasting their time interviewing programmers who can’t program.
This is why Jeff uses code challenges for hiring at his companies:
Maybe it’s foolish to begin interviewing a programmer without looking at their code first… we require a code sample before we even proceed to the phone interview stage. And our on-site interview includes a small coding exercise. Nothing difficult, mind you, just a basic exercise to go through the motions of building a small application… [letting] us focus on actual software engineering in the interview
In a developer interview, you may be asked a wide range of questions to test not only your knowledge, but other personal and professional qualities that you may have (see here). As we mentioned, one line of questioning that regularly comes up is for you to craft a solution to a totally random coding problem, the types of which you most likely will not have seen before on your coding journey. Sometimes easy questions will be given earlier in the job interview process to weed out applicants, sometimes harder questions will be issued later in the process to test candidates more thoroughly. Just because these are random and unusual problems does not make them trick questions! The rationale behind these questions is to see how you think through a problem in code. That’s why memorizing code challenges and their solutions is a futile exercise, as these questions can be from a pool of thousands of possible questions and the objective is not purely to see if you can get the “right answer”!
Interviewers want to see:
- Your initial reaction to the problem itself, e.g. do you comprehend the question?
- Your thought processes - how do you break down this problem?
- Your communication - how are you conveying your thought processes and approach to your interviewer?
- Your decision-making - there are trade-offs in solving a problem one way or another, so how and why did you choose your methodology?
- Your passion for learning and challenges - are you energized by this kind of thing?
Again, this is why for our code challenges we don’t just ask you for your solution code, but for your explanation. Test yourself not only with not only the problem itself, but how you explain solving it!
See this thread on Quora for how these sorts of questions get asked at the likes of Microsoft and Google (including fleshing out the dialogue between interviewer and interviewee), and read this forum thread for some other examples of coding interview questions.
Finally, it’s important to note that you should not always expect to see these sorts of challenges in job interviews! For many development jobs, particularly at the entry level, employers may not issue any challenges at all and are instead far more interested in your portfolio and references. Once you’ve built up enough experience and a portfolio, employers may not feel that challenges are necessary. You would likely never see challenges like these when applying for freelance work.
Thus, don’t feel that you have to reach a level where you can solve all these challenges before you start applying for your first coding job! It is possible that you would never experience challenges like these in your career (particularly the hard level challenges) unless you applied for a more demanding or senior job and/or you applied for work at one of the world’s top tech companies, where highly selective screening processes are necessary.