Background
I'm a soon-to-be graduated CS student. I have spent the last month trying to land my first job in the software industry. I interviewed with a couple of companies and I (you guessed it) got rejected. I'm here to talk about the interview process.
The process
Most companies have a similar process for interviewing candidates. You first go through an online test (On Codility, HackerRank or a similar platform). If you pass it, you'll have another technical interview, where you might have to write code on a whiteboard.
Why I think it's flawed
The questions you're asked usually revolve around implementing data structures, Maths, and algorithms. The problem is, you almost never will have to implement a data structure from scratch in the job, and you shouldn't anyway.
You usually use data structures included in the language or a standard library. You use them, along with other tools, packages and frameworks to implement your business logic. As a software developer, you spend most of your time gluing code together from different libraries and packages to build your app. You never have to build something abstract like a heap or a binary tree from scratch on entirely your own. You never have to write code without the help of an IDE, or Google for that matter. But that's what you're evaluated on anyway.
Theoretical knowledge of low-level fundamentals is great, but you can be a great developer without it.
There is a huge gap between what you do in the job you're applying for (especially junior jobs) and the abstract questions you're asked to solve in an interview. If you run into something complex, normally you would look it up on google, or consult your team on it. You won't have to face it by yourself with no internet connection, no outside help, and no IDE.
So why do you have to go through all those steps to prove you're just a good entry-level developer?
Solutions
I know it's hard to identify good candidates. I'm just saying that the current system is clearly flawed. One solution is an assignment given to the candidate based on a portion of your codebase, in which they try to understand your code and how to build on it and write code that solves the problem while not breaking the existing code, which is mostly what happens in the actual job. That way you'll have more practical knowledge about the candidate and how they integrate with the team.
Top comments (16)
I agree with you, and it's something I'm trying to influence where I work, but the reality is that knowing these things will help you get hired.
In preparation for an interview, you should implement common data structures and implement common algorithms, all while understanding their space and time limits. It's basically like studying for a big test. If you pass, you can go ahead and forget most of it.
With all that being said, just because a data structure is included in a language doesn't mean it isn't important to know what's going on under the hood. When and why would you use a LinkedList over an ArrayList? How about HashMap vs TreeMap? Can you identify code that has a quadratic runtime and make it linear? These are the types of questions you can answer once you've gone through the trouble of implementing various data structures and algorithms, even if you forget most of the implementation details.
I get that they're important, definitely. But they are nice to haves, not essential for most software jobs. You can make a decision on which data structure to use based on their high-level definition/documentation, no need to get to fine details.
So the main test on if you can do a job well is based on mainly trivial nice to haves, and not in any way representative of your real-world performance.
You have to remember that it's not exactly trivial from the interviewer's perspective either. How do you determine over the course of a few hours that a person is worth the investment of a software engineer's salary? This is especially hard when you're hiring people right out of school.
The fact of the matter is, people coming right out of school have no real-world experience, generally speaking. While having candidates implement data structures on a whiteboard or recall the exact runtime complexity of a non-trivial algorithm is not going to gauge real world experience, having them solve novel coding problems is a way to gauge their thought process and problem solving skills. This involves knowing when and where to use appropriate data structures, and at least being able to speak to their performance characteristics at a high level.
I think you're assuming that you don't get hired in every case because you failed to implement the data structure or algorithm perfectly. Do you know that to be the case? We use theory in interviews in part to gauge a candidate's fundamental level of understanding, but we don't reject candidates outright if they don't remember how to reverse a tree, and we wouldn't hire someone just because they did, either.
Most career self-help books will say some platitude about "it's how you approach the problem."
That's not false, but it's not quite right, either. How you approach the problem isn't just a matter of thinking logically about a problem you haven't memorized the answer to.
As someone who's interviewed and screened hundreds of candidate over a 15 year career, I start every interview hopeful that the candidate will find something interesting and technical to discuss about the question. You may not find a deep dive into FizzBuzz interesting, but there is something you find interesting about software development besides the salary. And you have to be able to find it with most, if not all, programming problems, or you will burn out, fast. Candidates who are excited about programming for a living can become great programmers even if they forget the cases where a Bubble Sort beats Quicksort. But they don't just make great programmers, they create great programmers out of their teammates, too. Personally, that's what I'm looking for in a candidate – someone who is excited enough to overcome the intimidation of a boring or overly theoretical programming interview question and get excited about it, and share why it excites them with me.
Great response. But I think good programmers don't necessarily have to be great problem solvers. Some can turn requirements into well-written code very well, even if they don't have the ability to design a solution from scratch. I think that part of the job is not taken into consideration in interviews.
Also, 'passion' and 'excitement' is not a good metric for measuring quality IMO. There are a lot of great developers who only work with code in their daily job, and switch to something else entirely when they go home (Family, friends, hobbies, sports, etc).
I commented elsewhere, but I need to correct something you just said - programming is problem-solving by nature, whether it is building, rebuilding, debugging, or expanding.
You are correct that designing a solution from scratch isn't necessarily part of every job, but you need to understand that a complete inability to design from scratch (or, in the same vein, a complete inability to build on top of existing code) indicates a lack of the core skills that set mediocre programmers apart from excellent programmers.
In case you're wondering, this is coming from someone who trains programmers at all experience levels as his full time job. I've seen all sorts of programmers, and many different approaches, styles, and talents. There is a lot of diversity in programming, but among those that excel at this craft, there are common traits - problem-solving, communication, and a dedication to excellence (often misunderstood as "excitement"/"passion"). These ARE essential ingredients.
But what would you suggest companies do instead to weed out the massive amount of applications they get? Companies already are trying alternative hiring processes (internship -> offer etc.) but you need some sort of initial filter to reduce the amount of applications.
I get the problem, and I know it's hard to identify good candidates. I'm just saying that the current system is clearly flawed. One solution is internships, another is an assignment given to the candidate based on a portion of your codebase, in which they try to understand your code and how to build on it and write code that solves the problem while not breaking the existing code, which is mostly what happens in the actual job. That way you'll have more practical knowledge about the candidate.
You do realize, we have to interview for internships, too. Those involve HUGE investments of time, energy, money, and development hours, so we have to be very selective there too.
As a someone who recently graduated 8 months ago, who has been working in the industry since, and who has been on tons of interviews in the last few years... I believe I have a relevant perspective on this. I've been rejected and accepted by the best and worst of them.
I don't have a great memory and I almost never have to recall some obscure implementation of a sorting algorithm outside of an interview. So you can imagine these types of interviews either go well, if I'm lucky enough to get a familiar problem, or terribly. This interview method merely tests a candidate's ability to memorize which isn't going to proved a ton of insight into how that person will be to work with. With that being said, there are many concepts and patterns which come with comprehension and experience which reveals a surprising amount about the personality of the candidate. For instance, using map/reduce instead of for loops everywhere or modularizing subroutines appropriately.
It's also notable that 6 months ago I firmly believed that I would never use some of the more theory related info from school (i.e. State machines) and 6 months later, guess what? I'm advocating the use of state machines to my coworkers as a way to approach a particular challenge at my company. The point being, you are going to learn valuable problem solving skills and get many ideas from existing designs, even if you aren't setting up linked lists and BST's at work.
tldr; Mohamed, you're absolutely right, but who wants to work for a company that doesn't understand what makes a good developer anyway. Keep at it!
Thanks a lot for the kind words! Who knows what makes a good developer, anyway!
One really interesting and effective (in my opinion) that I've encountered is pair programming. The interviewer would ask the interviewee to come in and come up with something to build/fix/hack. It could be an app from scratch, existing and sometimes an issue in a popular Github repo.
The interviewer is usually the observer while you do all the driving. And you are allowed to google or use SO. This gives the interviewer an idea on how you tackle problems and also shows a bit of your technical capabilities.
Yeah, that's a very good approach that I've heard of too. The problem is it takes time to get acquainted with a codebase, much longer than the 30-60 minutes you get in a traditional interview, anyway.
You should know, my company (MousePaw Games) takes a very different approach. We don't focus so much on existing knowledge as we do on the character traits and communication skills that set superb programmers apart. We do have a coding challenge - which applicants have a week to complete - but this is intended to give us a picture of an applicant's coding habits and approaches.
In short, as a recruiter and internship supervisor, I know that a coder's habits and communication skills are a far more accurate indicator of their proficiency than their present technical knowledge is.
That's a very good post! I agree with your conclusion. I think the same as to algorithms and data structures you described applies to math as well. They teach calculus and other complex math in CS courses while you (almost) never use it in programming.
Thank you!