Are These Bad Interviewing Practices Costing You Millions?

Have you ever wondered what the ideal interview process would actually look like from a developers point of view? After interviewing hundreds of candidates I have come up with a list of the top 9 mistakes companies make when interviewing software developers. If you finish this article and find yourself asking , “What is the ideal way to interview developers?” Well, you’re in luck. At StriveNine, we are #DevsSourcingDevs and we have a proven interviewing system that can work for you too!

1. You are quizzing via riddles, instead of validating their knowledge of programming concepts.
2. You haven’t defined the set of Core Knowledge necessary to be successful.
3. You haven’t published your set of Core Knowledge.
4. You interview process doesn’t ensure that your candidates Core Knowledge is ready.
5. You don’t give feedback and allow the candidate to go home and study.
6. You don’t define and publish a core set of algorithms, that contain concepts that are important to your company.
7. You have candidates writing code on a whiteboard.
8. You don’t do pair programming with your candidates.
9. You don’t have a system in place for Junior Developers.

1. You are quizzing via riddles, instead of validating their knowledge of programming concepts.

I really hope that companies have stopped following this utterly ridiculous process. There is, unequivocally, NO CORRELATION between solving riddles, and being a great software developer. This notion is a fallacy if I have ever seen one. Sure, some developers might be great at solving your riddles. And some of those developers may actually be very good at what they do. But for everyone of those developers, I can find you a great developer that doesn’t care about, or have the ability to solve these questions with out sitting down and memorizing them first. So tell me, do you want your developers memorizing riddles or studying new technologies that could save your company millions?

To all the developers out there, if a company asks you a riddle during their interview process, kindly thank them for their time, get up, and walk out!!! If a company is this far out of date with their interview process, who knows how far out of date they are with their there treatment of developers. Still counting lines of code maybe?

OK, now that we have that one finally, once and for all out of our way, let’s move on.

2. You haven’t defined the set of Core Knowledge necessary to be successful.

What? You mean I should tell the developer what concepts are important to be successful before they interview? Then how am I supposed to trick them and make myself (the interviewer) feel superior?? This is such a basic concept that absolutely nobody does. And it is a very beneficial process, not only for incoming candidates, but for your company too. Writing down the important Core Knowledge for a team / company will help you organize your ideas, as well as help you identify your ideal candidate. Do you even know who your ideal candidate is?

This is where recruiters start telling themselves, “well I put a job description that says developers need to know J2EE.” Ummm… stop kidding yourself, nobody knows the entirety of J2EE. And if they do, then they have probably wasted their time studying uncommon concepts instead of focusing on more important knowledge gaps. Is that really the person that you want?

Consider the following questions. Are data structures important? Which data structures and why? Is Big 0 important? Is understanding how a language works behind the scenes important? In what aspect? Should they know multi threading? Should they know the event loop in JavaScript? Do they like to test? Do you write tests? Do you prefer TDD or BDD? OK, this is just touching the surface when it comes to understanding your core knowledge and identifying an ideal candidate.

On a side note, If you still are not writing tests in this day in age, I implore you to reach out to StriveNine so we can save you $$$$$$$$. One last thing, BDD is the best!

3. You haven’t published your set of Core Knowledge.

Why would I give away my interview questions to candidates? To many this seems counter intuitive. Let’s stop and think about this though. What groups of people are we interviewing when we do NOT publish our core set of knowledge? They either know the answers to your questions or they don’t. How many of the candidates that cannot answer your questions go into other companies and make a big difference? How many of the candidates that could answer your questions come into your company and prove incapable of learning new concepts that are equally or more important?

To me, I want developers that are curious, want to learn, and know how too learn. I want developers that pride themselves on going the extra mile to achieve success. When publishing your set of core knowledge, if a candidate cannot answer your questions, you can assert with greater confidence that they are not ready to join your team. The candidate that can answer your questions, either already knew your knowledge set (That is good), or they studied enough to learn it (That is even better!!). If the latter, then you know they can teach themselves (which they have to do almost everyday on the job), and you know they are willing to go the extra mile for success!

4. You interview process doesn’t ensure that your candidates Core Knowledge is ready.

Know that we have our core set of knowledge defined, the next step seems obvious ….. right!!?!? Developing a system to ensure candidates are being interviewed to verify their Core Knowledge is more work, and it is often a crucial missing step. Given the HR interviewing tools that are available today, this is NOT a difficult step. Do some research on the best ways to track candidates performance to your core set of knowledge.

5. You don’t give feedback and allow the candidate to go home and study.

OK, so you have just interviewed someone that did less than spectacular on your core set of knowledge interviewing. Time to cut them loose and never talk to them again right? ABSOLUTELY NOT! Maybe they didn’t have time to study or couldn’t find your core set of knowledge. Maybe you didn’t publish it (tisk tisk)?? Kindly explain to the developer that they are not ready for the roles that you have open. Then show them how to find your core set of knowledge and let them restart the interview process when they feel they are ready. By completing this task, the developer has shown you their dedication to education and their ability to learn.

6. You don’t define and publish a core set of algorithms, that contain concepts that are important to your company.

The same ideologies that applied to your core set of knowledge, also apply here but with a small twist. The problem with algorithms in interviews, is that you don’t know if a candidate just memorized them, or if they actually understand the concepts behind them. Now you are probably thinking right now, but Cory, if I publish my interview questions wont all of the candidates just memorize the algorithm? Well yeah, they might. But I’m not suggesting you ask the exact algorithm that you have published.

At the core of every algorithm that you choose, should be an algorithmic principle that you are testing. It might be Big O efficiency, simple recursion, maybe even OO Design. Maybe you even want to test more than one principle in the same question. There are many different ways to test these core principles. When in the interview, you should test the core principle by altering the published algorithm or by presenting the problem in another manner (maybe a business problem). This process will allow you to see how well the developer can apply the different concepts they know to your different business problems.

7. You have candidates writing code on a whiteboard.

Just remember that your interview process is a method to discover if the candidate can be, or can become, a highly functional member of your team. If your team spends time writing code on whiteboards, then by all means continue this practice. If you are like the rest of the world and use computers to write code, then maybe you should get a feel for the candidate writing code in their natural habitat.

If someone was good at the popular kids game Operation (probably dating myself with this reference), would you feel comfortable allowing them to actually operate on you? Let’s guess that your answer is no! There is a real difference between writing code on a white board and writing code in an environment that a candidate is used to. You want to make sure the candidate can do the real thing, not draw letters on a white board.

8. You don’t do pair programming with your candidates.

Programming questions are not static. There are many different paths to a good answer. The most important part to analyze is the thought process and steps taken to get to the answer, not just the answer itself. Pair programming is a crucial step in analyzing this thought process. This means the interviewer should be engaged, sitting in front of a computer with the candidate. They shouldn’t be on their phone, chatting with someone else in the company, or otherwise not focused on the problem at hand. How else can they validate that the candidate is taking an efficient path towards solving the problem. The interviewer can help them write a test, they can question part of the algorithm, or find out what the candidate is thinking. They should be getting the candidate talking as much as the candidate should be engaged in asking questions. Without 100% focus from the interviewer, the candidate should seriously be questioning if this is really the place they want to work.

9. You don’t have a system in place for Junior Developers

I am going to ATTEMPT at making this section small because I could easily (and probably will) write an entire paper on this subject by itself. This topic is particularly important to me because I enjoy mentoring junior developers, and I believe they are greatly underutilized and misused. This is especially true in the new world of code bootcamps. Far too often developers are judged based on their current knowledge set instead of their overall work ethic. Remember that knowledge is one of the more easier things to be developed. It is far more difficult to teach an individual work ethic. Now you might ask, how can I interview for work ethic? Well, if you are asking yourself this question at this point in this paper, then my suggestion to you is to start over from the beginning.

I am a huge sports fans and I always draw analogies between sports and business. In sports, there are certain franchises that are perennial winners. Sure they have there star players, but so many other positions are filled successfully by rookie players or cast offs from other teams. These teams don’t need better players, because they have better systems. Building development teams is the exact same. A great system that is well documented, understood, and has buy in, will always win. Great team over great individuals. What is the system you have in place to help your developers succeed? Do your junior developers have examples of good code vs bad code in your system. Do they have great developers that are their and willing to mentor them. Not only being a great examples on how to become  great developers, but how to be great people and citizens in your culture. As I said, this is only touching the tip of the proverbial iceberg on this topic. Stay tuned for more!