Currently, since I am on the hunt for a new job, one thing I am not looking forward to any tests I might be given during the interview process. Part of the reason is that as far back as I can remember, I have never liked taking tests. I am not sure why, but it does cause anxiety in me. Also, I have been seeing on Twitter lately a lot of people complaining about the tests they are given. Many times, when I have spoken about interviewing at conferences, I say some tests we give might not make sense, but when I interview someone, there
is a purpose behind it. The biggest reason I choose the tests are designed to understand your analytical thinking or what I call the “Spock Mind”, something I discuss more in detail in my
technical interview book.
Recently after submitting my resume to a company, I received an email from them saying that before they will continue with the interview process, they wanted me to take a 45-minute test that seemed to be mostly around personality. I was a bit taken back when I received it. I might be showing my attitude, but I have been in the software engineering business for over 27 years, and I am not going to waste 45 minutes of my time just for the chance to get interviewed. Especially since there is a shortage of software engineers in America and even a bigger shortage of good ones!
For the rest of this article, I will give more examples and I will propose a solution that I came up with and successfully used in the past when hiring software engineers. I hope you will try it the next time your team does a round of interviews.
You Want Me to Do What?
I have taken plenty of tests during my career during the interview process, but this request is the first one I always think about when thinking of a bad experience interviewing. A while back I interviewed at a website based out of San Diego, California that sells automobile parts. I was looking forward to interviewing for this position since it would allow me to get back to leading developers. Something I enjoy doing and am pretty good at it. I have been leading people since I was 18 years old when I became manager at a restaurant and was profit sharing. Not bad for an 18-year-old!
Anyway, the interview was with the CTO of the company and was supposed to last an hour. The CTO and I got along so well, and we had a lot to discuss which lasted two hours! At the end, he told me that his assistant will call me to set up the next interview. When his assistant called, he said that they wanted me to come in and build an entire e-commerce website in only 4 hours. I have never gotten a request like this before, especially for a lead position. I would say that “maybe” this would be appropriate to a junior developer to assess their skills, but not someone being hired to lead developers. I do not think anyone could do this, and I do not like to fail.
I did not know what to do about their request. That night, I was running the user group where I live. So, I decided to ask a few of my friends who are at the same level that I am what they would do. Everyone said they would not take on this test. So, after a few more days of contemplating this, I called the assistant and told him that I would not be continuing with the interview process.
I was sad about doing this since I wanted the lead role again and I have worked for many e-commerce websites during my career. One of them, Profolwers.com, event made me a
patented inventor! My biggest fear is that companies like this one might be missing the chance to hire great developers and will only attract desperate ones. I have many stories like this one but let us move on to a real-world situation.
You Must Hire Only Beginners!
Way, way back around 2010, I was working for Mitchell International, they made a classic mistake that I have seen many companies do. After we released the first version of the product that I was hired to work on, we had the common issue of lots of features to implement and not enough developers. Erez Nir, the EVP & CTO wanted to hire a lot of beginner developers and only beginners that is also referred to as “butts in seats”. Any seasoned developer knows that this rarely ever works the way the company intended. I pleaded with him to let me trade two beginners for an intermediate developer, but he refused. So, the hiring manager and I set out to complete this task.
As you might guess, most of the beginners that we interviewed were fresh out of earning their computer science degree. We interviewed many and
not even one of them got past the first interview. Not only were they terrible at interviewing (the reason I wrote my
book on interviewing), but they just did not even have the basic skills we were looking for like understanding object-oriented programming. I feel that most schools
do not properly prepare engineers for entering the business world. One day I told the hiring manager that
he and I must be doing something wrong since
we have not been able to hire anyone, and I was worried that Erez would get upset at us. I said we need to come up with a better way. The other manager had to go to a meeting, so we both had an hour or so to think about a solution.
During that hour, I went back in my mind to when I was a beginner and how I was successful getting jobs that I will explain next. The other manager came back and said we would give them a test to have them reverse a string. I did not think this would allow us to understand the candidate's analytical thinking, especially since I can do this with one line of code!
When I Started This Career
I always learn by doing. When I was a beginner, I was always was writing apps at home to teach myself programming. All these apps were ones that I needed that someone has not written, or I needed more functionality. Whenever I went to a job interview, I would take these apps in a box of floppy disks (yes, I am dating myself). When the interviewer would tell me about the project, they wanted to hire me for, more times than not, I said I have written something similar. I then installed the application, ran it, and explained how it worked. Showing one or more of my apps got me hired every single time! This never failed me! They just wanted me to demonstrate I wrote something that worked! They never even asked to look at my code, thankfully!
One of these apps that I wrote was a file transfer utility. The reason I wrote it was that when I was learning to program, I was a computer support person at General Atomics in San Diego, California. I would spend every day at lunch programming and needed an easy, quick way to automatically transfer source code from my work computer to my home computer using floppy disks, so I could work on the applications in the evenings. This was a long time before services like OneDrive or GitHub that makes it very easy to share/ backup code these days.
So, I sat down and wrote an application called Same<>Same. Once I was happy with it, I wondered if anyone else would find it useful, so I release it to the world, back in the ’90s via a
Bulletin Board System (BBS). For the younger developers out there, this is what we used
before the internet to communicate and share and sell applications.
Same<>Same was the second program that I release this way. After people started using it, I sold Same<>Same for $25. Adjusting for inflation, the cost would be $44 today! Back in the ‘90s, people purchased apps a lot more than today in the “I want it for free” attitude most customers have.
Same<>Same was given a great review in PC Magazine in 1995 (only one year after working as a software engineer) and my orders shot up from about 10 a month to 10 a day for a while!
When all of this happened, I did like the recognition (I was interviewed by two magazines), I did enjoy extra income for my family (I had two small children at the time), but what I did not know at the time was that this was teaching me the software development lifecycle. I did the entire process myself from dreaming up a new application, architecture, coding, maintenance, shipping orders and even dealing with customers. I think therefore I am one of those few developers that like talking to customers.
I have always felt it is my job as a software engineer is to improve the workflow for business customers. How can I even do that without talking to them so I can fully understand their needs?
For example, if your favorite car manufacture comes out with a brand-new model, with zero input from consumers, would you immediately go out and purchase it when it is available? If you care about using your money wisely, I doubt a reasonable person would do this. But this is the way that software is created all the time! During my career, very few companies I have worked for allows developers to talk to actual customers. At one company I even asked the CEO if I could do that during a party the company was holding for our sales representatives, but he refused. The next day was looking for a new job. I do not like working for companies with this close-minded attitude.
Since I do not have a computer science degree, this taught me a lot when I was a beginner. Sure, the SDLC is different now, but this was ingrained in me right from the beginning. Unlike computer languages or learning the latest framework, these types of skills can be used for your entire career. A few years later I was evening teaching SDLC at a few companies.
Applying How I Landed Jobs When Interviewing Candidates
I told the hiring manager that his idea is not good enough if we were to understand the candidate's analytical thinking. So, I told him the story above and we should do something similar. He agreed so I called down to the internal recruiter that we were working with and told her the following. I said, whenever a candidate comes in for the first in-person interview, they MUST bring in an application that they coded from their mind (not a school or work project). We will have them sit at one of our computers, load the solution in Visual Studio, run it, and then explain why they did what they did when we reviewed the code.
Candidate One
The first candidate that we tried this on brought in a simple application that he wrote for his father. His father was a veteran and could get milage reimbursement from the government when he traveled to the VA Hospital for treatment. Since he was a beginner, the code was not great, but I expected that. He did very clearly explain the reason he wrote it and showed us the code which allowed us to understand his analytical thinking. He did this so well that we hired him! The first task he was given was one that we were having a difficult time coming up with a solution for. But he figured it out and he turned out to be a very intelligent developer with a bright future in front of him. Once he figured this out, he left the company for a better one. I do not blame him. Mitchell is one of those companies that I call a “revolving door” company. Most developers in the area seemed to have worked there at one point. They go in, figure out how crappy the company is, and then leave for a better one. We have many companies in my area like this.
Candidate Two
The second candidate brought in some code from her current job. I do not prefer this, especially when it is just a portion of the code and it does not run. We were able to get to know her way of thinking. At one point, I asked her if this code is in production (since there were issues with it) and the hiring manager slugged me and said “Dave, we aren’t here to critique their code!”. I tend to do this whenever I look at code. It is very difficult for me to turn it off.
She also turned out to be great and once she realized it; she also left the company for a better one! I had a feeling she would since the department did not listen to me when I came up with a training program for her to learn the skills we needed. If companies do not support their developer's learning and growth, they will lose the good ones.
Always Hire Software Engineers that Love to Learn
Another thing that testing engineers like this will also show teams that the candidate loves to learn. I have said this many, many times and that is our world changes every single day. Since teams are small these days (2-5 based on my survey), it is important to hire engineers that love to learn and grow in their career. If they write applications at home, this is a home run! If they do not do this at home, that shows that they are a 9-5 developer and usually will not learn unless it is forced on them at work. I call these developers “Code Monkeys”, and you certainly do not want to be one if you want to grow in this career.
Make Sure You Write Apps at Home!
One of the things I strongly recommend for developers at all levels is to be always writing apps at home. I have been a software developer for a long time, and I am
still doing it. For example, I wrote a series of articles for this site called
Real World Cloud App from Start to Finish. In these articles, I’m showing how I am adding a new feature to one of my
free apps using Microsoft Azure. The main reason I am doing this is to learn Azure. My secondary goal is to change my current Microsoft MVP award to the Azure MVP award. Currently, I am leaning WinForms in .NET 5 along with more Azure!
Writing apps, in the beginning, was to learn how to be a developer, now I do it to keep up with technology. The applications I wrote which later got (good) reviews lead to more
jobs, started my writing career and even speaking at large conferences around the world. Little did I know that those first few apps I wrote would lead to where I am now.
So, go write something, anything! Write apps for one of the app stores. Write open-source libraries and release them on GitHub and NuGet. I suggest that you not do this to “get rich quick” but to gain the experience that you need and then see where it leads. If you do this, then I think your future in software engineering will be a happy and successful one. And even if you are not asked, bring these apps to your next job interview, just in case you need to show them what you have written on your own. If you are more of a front-end developer, you can also bring in examples of your work. I have done this by printing out the web pages or application screen grabs in high color and putting them in a nice leather portfolio.
Summary
Doing this with candidates allowed us to
finally hire the developers that we needed. I am not going to say this will work at your company, but why not give it a try if you are also having issues finding qualified candidates? What do you have to lose? If your company needs help with learning more about this, I am always willing to help. I am also willing to help your team interview software engineers! You can email me at
[email protected].
If you do try what I have suggested, I would love to hear from you! Have you been given any tests that made no sense to you? Please comment below.
George SemplePosted Apr 14, 2021, 5:55 PM
David, I too have found there are better ways to interview candidates. Something I have had great success with is simple conversation. I learned this technique many years ago when a had college instructor that never gave tests or quizzes. He graded you solely on your questions and interactions. I've now utilized this method in my last 4 companies with great success. Turns out, when someone knows about 'something' they can speak to it, the passion will come out. The more they know about a 'thing', the better they talk about it and the questions they ask are real the giveaway. Here's how we do this. After the introductions and glad-handing the process starts with a discussion. Anything relevant topic works. It could be tools/frameworks, design patterns maybe the newest C# feature set. The topics are only surface level important. Keep in mind, like you, we aren't looking for someone to know everything about how we code or being an expert in every toolset. When you converse (with a bit of purpose and planning) you more easily can find out what a person really knows, how people test, how they learn, where they come up short. We also have simple 'secret' role play scenarios we've employed. We'll plan to have a dev interrupt the interview to bring some 'issue' to our attention. Could be an IIS thing or a CI problem, doesn't really matter. Its an unexpected event for the candidate and then that becomes part of the conversation. We never ask a single 'technical' question and we've never asked for project samples. I can say we are now 6 for 6 at my current company and the process has consistently proved effective.