Are Interviews Broken for Developers?


We have all been through it, the dreaded job search. You apply for over 100 positions, you receive a call from five of them, only two actually interview you, and out of desperation, you take the only offer you get. I know this because I have been there and done that. I took the approach of mass production and distribution with my resume and the numbers worked out very similar to the above.



 

Let me explain more about my situation, which I believe accurately describes most of our experiences. I decided it was time to start looking for another job. The reason is not important, what is important is that I decided to look around and see what options existed. I am a senior full stack developer with over thirteen years of professional development experience.


I know, and mostly love, Javascript and the popular frameworks. I know a variety of intermediate languages like C#, Java, and Python. I have an MCSE certification in Business Intelligence along with nearly ten years of hands-on experience writing SSIS packages and T-SQL queries. Oh, did I mention I have a Masters degree in Computer Information Systems from Penn State? 


On paper, my credentials are moderately impressive and I went in thinking that I should at least get through the door more times than not. After all, if I had these credentials in nearly any other profession I would most likely be well on my way to having any position I wanted. That is simply not the case in the development field, and I am still trying to figure out why.

Here are my thoughts and what I think I have learned from this experience. First, employers have no way of determining whether or not we are actually a good developer. Most of us work for companies who do not like to share their work. That means unless we work on open source projects or take the time to put together a portfolio of code snippets we have no way to prove ourselves. 


Employers overcompensate in this regard by administering test after test in an attempt to understand our skill level. Most of these tests are out-of-the-box tests that are put together by a testing company or website like hackerrank.com. Now do not get me wrong. I love Hacker Rank, I find their tests enjoyable and a good way to keep my skills on point. What I disapprove of is a live whiteboard session with two or more developers critiquing your code, live.


Bluntly, this is not how developers work!


If you are anything like me, you write a little bit of code, get stuck on a tricky section, and then take the dog for a walk. The whole time you are walking the dog your mind is thinking about the solution and all of the different ways you can solve this problem. About three-quarters of the way through your walk, the solution hits you like a ton of bricks. 

It was so obvious! Why didn’t you see it at first?!?!


You finish your walk, finally in peace knowing you have it solved, and after a drink of water, a splash of water on the face, you sit down and make the magic happen. 

I rarely, even with all of my coding experience, sit down and write code that just works the first time, without issue, and without spending at least twenty minutes on Stack Overflow looking for the proper syntax. If I could do that I would not need a job, I would have created the next cool thing and be living the dream!


The next point I want to discuss is algorithm complexity. A lot of the interviews I have gone through lately have had a large focus on algorithm complexity and whether or not I know how to calculate it. Again, if you are like me, I rarely am required to compute the complexity of an algorithm. 


I know that something like the below code is not efficient. I do not need to know the Big O notation to understand this is inefficient code. 

for(var i = 0; i < something; i++)
{ 
    for(var j = 0; j < somethingElse; j++)
    {
        //do something
    }
}

Again, do not get me wrong. It is important to know a bad algorithm when you see one. Academically, it is important to know how to calculate this. In the real-world, just knowing this code is bad is where you need to start. 


Surprisingly, one of the largest issues I come across with inexperienced developers is the fact they do not recognize the inefficient code. I honestly feel that if I show you this code and you cringe, that is good enough for me. Well, close enough at least. I might ask a follow-up question about how to fix it, but as long as you identify the issue you pass my test.

The problem we come across is there is absolutely a correct answer to the complexity question and the Human Resources personnel only see a right and wrong answer. Not knowing that a nested for loop usually looks like O(n²) in Big O notation can be the difference between a second interview or not. 


Sadly, if you are interviewing for a senior level position you need to know your Big O.

The last gripe that I have is when a snippet of code is given, and without the aid of a compiler, you are asked to debug it. Sure, this is possible. A well experienced developer should be able to find syntax errors, obvious issues, and the like with relative ease. The question is if we should have to do this without the use of our toolset. 


Would you ask a builder to build you a desk without using fasteners, a tape measure, an angle, or a hammer?


Of course not. Those tools are required for the builder to build you a masterpiece that does not wobble or fall apart as soon as you touch it. Why then are developers asked to do just that?


I honestly have no answer for this. It all circles around to my first point of do you know how to code? 


In summation, this is not a problem that developers can fix. Instead, this is a problem that human resource specialists need to solve. I have suggestions and I am happy to write about them, but that will not make a difference if people do not listen. 


I fully understand the need to test applicants. After all, we are asking the company to pay us over $100,000 per year for senior level positions and they need to be able to assess if we are worth that amount or not. 


What I recommend is that they start off with a verbal interview. This helps them determine how well spoken you are and whether or not you can properly convey your thoughts. 

Provided you pass this step, which I hope we all do, we should then be asked to interview with a senior member of the development team. No need to take a test, no need to whiteboard code, and especially no need to compute the complexity of a function. Instead, this should be a carefully crafted discussion. 


When I am asked to interview I write down the talking points I want to touch on. I ask questions about what you do you think of x technology? Did you see what Microsoft just released, I think that can help us here, here, and there…what do you think?

What this tells me is whether or not they are capable of having an in-depth technical discussion. Can you take a topic, convert that to a use case, and then explain to me how it would benefit us?


These questions are worked into the conversation casually. I am more interested in how they convey they know and can put that knowledge to use. Can they take this concept and relate it to that concept with ease. 


This tells me all I need to know about the candidate. I personally do not care if they know how to use the filter function on some obscure snippet of javascript. I want to know how they reason through problems, how they related technologies, and whether or not they are knowledgeable. 


If a candidate to objectively think about a technology and relate it to a situation then they can learn the syntax. Developing is a mindset, not memorization and it is time that recruiters and companies realize that.

0 views

©2020 by Justin Wilson