As a contractor, I frequently engage in interviews, but I must admit that I never look forward to the tests that are sometimes part of the process. I have never been fond of taking tests, and they tend to cause me anxiety. Additionally, I have noticed a growing number of people on Twitter expressing dissatisfaction with the tests they encounter during interviews.

While I acknowledge that some tests may seem nonsensical, when I conduct interviews, there is always a purpose behind the assessments. I select tests that aim to evaluate analytical thinking, which I refer to as the “Spock Mind.”

In the past, after submitting my resume to a company, I received an email requesting that I take a 45-minute test primarily focused on personality assessment before proceeding with the interview process. I was a bit surprised by this request. While I may come across as having a certain attitude, it is important to note that I have been in the software engineering business for over 20 years. Consequently, I am hesitant to invest 45 minutes of my time solely for the opportunity to be interviewed, especially considering the shortage of software engineers in America and the even greater scarcity of highly skilled ones.

In the remainder of this article, I will provide additional examples and propose a solution that I have successfully used in the past when hiring software engineers. I encourage you to consider trying this approach during your team’s next round of interviews. This information and a lot more can be found in my book titled “Rock Your Career: Surviving the Technical Interview” available on Amazon.com

You Want Me to Do What?

I have undergone numerous tests throughout my career during the interview process, but one particular request stands out as a negative experience. Some time ago, I interviewed at a San Diego-based website that specializes in selling automobile parts. I was excited about the opportunity as it would allow me to resume my role as a leader of developers, which is something I genuinely enjoy and excel at. Interestingly, I’ve been leading teams since I was just 18 years old when I became the head manager at a restaurant and was involved in profit sharing. Not too shabby for an 18-year-old, I must say!

The interview was scheduled with the Chief Technology Officer (CTO) of the company and was initially slated for one hour. However, we immediately hit it off, and our discussion was so engaging that it extended for two hours! In the end, the CTO informed me that his assistant would reach out to me to arrange the next interview. When the assistant eventually called, I was taken aback by the request they made. They wanted me to build an entire e-commerce website within a mere four-hour time frame. I had never encountered such a request before, especially for a leadership position. While this type of challenge might be suitable for assessing the skills of a junior developer, it seemed unreasonable for someone to be hired to lead developers. I genuinely believed that no one could successfully accomplish such a task in such a short amount of time, and the idea of failing was something with which I was not comfortable.

I found myself at a loss as to how to handle this request. That evening, I was running a user group meeting in my local community, so I decided to seek advice from a few friends who are at a similar level to me. To my surprise, everyone unanimously agreed that they would decline such a test. After contemplating this situation for a few more days, I reached out to the assistant and politely informed him that I would not be continuing with the interview process.

It saddened me to decline the opportunity, as I genuinely desired to take on a leadership role again, especially considering my experience working with various e-commerce websites throughout my career. In fact, I even became a patented inventor for one of them, Proflowers.com! My biggest concern is that companies like the one I interviewed with may miss out on the chance to hire exceptional developers, instead of only attracting desperate individuals. I have encountered many stories similar to this one but let us now shift our focus to the real world.

You Must Hire Only Beginners!

Back in 2010, while working at a company, I witnessed a common mistake that many companies make. After releasing the initial version of the product I was assigned to, we encountered the typical challenge of having numerous features to implement but a shortage of developers. The CTO insisted on hiring primarily beginner developers, with a focus on simply filling positions rather than considering the long-term implications. Any seasoned developer understands that this approach rarely yields the desired results. Despite my efforts to persuade him, he refused to consider trading two beginners for an intermediate developer. Thus, the hiring manager and I embarked on the daunting task at hand.

As expected, most of the beginners we interviewed had recently completed their computer science degree. Unfortunately, none of them managed to progress past the initial interview stage. Not only were their interviewing skills subpar (which prompted me to author this my technical interview and the conference session), but they also lacked fundamental skills, such as a solid understanding of object-oriented programming. I know that many educational institutions fail to adequately prepare engineering graduates for the challenges of the business world. Frustrated by our inability to hire suitable candidates, I expressed my concerns to the hiring manager, fearing potential disappointment from the CTO. I insisted that we needed to find a better approach. With the other manager having to attend a meeting, we each had about an hour to contemplate a solution.

During that hour, I reflected on my own experience as a beginner and recalled how I successfully landed jobs, which I will explain shortly. When the other manager returned, they suggested giving the candidates a test involving reversing a string. I expressed skepticism about this approach, as I believed it failed to provide insight into the candidates’ analytical thinking, especially since accomplishing the task can be done with just a single line of code!

When I Started This Career

I have always been a hands-on learner. As a beginner in programming, I would spend my time at home writing apps to teach myself. These apps were either tools I needed that didn’t exist or projects that required additional functionality. Whenever I went for a job interview, I would bring these apps with me, stored on a box of floppy disks (yes, that definitely dates me!). When the interviewer discussed the project they wanted to hire me for, more often than not, I would mention that I had written something similar. I would then install the application, run it, and explain its functionality. Demonstrating one or more of my apps resulted in me getting hired every single time! It never failed me. All they wanted to see was that I had created something that worked. Fortunately, they never asked me to examine my code!

One of the apps I wrote was a file transfer utility. I developed it while working as a computer support person at General Atomics in San Diego, California, during my early days of programming. I would spend my lunch breaks programming and needed a quick and effortless way to transfer source code from my work computer to my home computer using floppy disks so that I could continue working on the applications in the evenings. This was long before services like OneDrive or GitHub made code sharing and backup effortless.

Thus, I sat down and created an application called Same<>Same. Once I was satisfied with its functionality, I wondered if others would find it useful. So, back in the ’90s, I released it to the world via a Bulletin Board System (BBS). For the younger engineers reading this, BBS was the platform we used before the internet for communication, sharing, and selling applications. Same<>Same was the second program I released this way. After people started using it, I began selling Same<>Same for $25. Adjusting for inflation, it would be around $50 today! In the ’90s, people purchased apps more frequently compared to the prevailing “I want it for free” mindset among customers today.

Same<>Same received a great review in PC Magazine in 1995, just one year after I started working as a software engineer. As a result, my orders skyrocketed from about 10 a month to 10 a day for a while!

During this time, I enjoyed the recognition (I was even interviewed by two magazines) and appreciated the additional income it brought to support my family (I had two young children at the time). However, what I didn’t realize back then was that this experience was teaching me the Software Development Lifecycle (SDLC). I single-handedly went through the entire process, from conceptualizing a new application, designing the architecture, coding, maintenance, shipping orders, and interacting with customers. I believe I am one of the few developers who genuinely enjoys talking to customers. As a software engineer, I have always felt it is my responsibility to improve workflow for business customers, and how can I do that without engaging in conversations to fully understand their needs?

For instance, imagine your favorite car manufacturer releasing a brand-new model without seeking any input from consumers. Would you rush out to purchase it immediately? If you value making wise financial decisions, I doubt you would do so without hesitation. Yet, this is often how software is developed! Throughout my career, I have worked for very few companies that allow developers to directly communicate with actual customers. I once even asked the CEO of a company if I could do so during a party the company was hosting for our sales representatives, but he refused. The next day, I started looking for a new job. I dislike working for companies with such a closed-minded attitude.

Not having a computer science degree, taught me invaluable lessons as a beginner. While the SDLC may have evolved since then, the core principles I learned from my early experiences have stayed with me. These skills transcend specific programming languages or the latest frameworks and can be applied throughout one’s entire career. In fact, a few years later, I even had the opportunity to teach SDLC at several companies and I incorporated it into the classes I taught at the University of California San Diego.

Applying How I Landed Jobs When Interviewing Candidates

I expressed my disagreement with the hiring manager’s suggestion of requiring interviewees to write code to reverse a string, explaining that it wouldn’t effectively assess the candidate’s analytical thinking. Instead, I shared the story mentioned earlier and proposed a similar approach. The hiring manager agreed with my suggestion, so I promptly contacted the internal recruiter we were working with and outlined the new requirement. I emphasized that for the initial in-person interview, candidates must bring in an application they personally coded from scratch (not a school or work project). During the interview, we would have them sit at one of our computers, load the solution into Visual Studio, run it, and then provide an explanation of their code choices during our code review session.

Candidate One

For the first candidate, we applied this approach and brought in a simple application he had developed for his father. His father, being a veteran, needed a solution for mileage reimbursement when traveling to the Veterans Affairs Hospital for treatment. As a beginner, his code was not perfect, which was expected. However, he excelled in clearly explaining the purpose behind his application and demonstrating his analytical thinking through the code. His performance impressed us to the extent that we decided to hire him.

We assigned him a challenging task that we had been struggling with, and he managed to find a solution with great intelligence and skill. It became evident that he had a promising future as a talented developer.

Unfortunately, after successfully resolving the task, he decided to leave the company for a better opportunity. I cannot blame him for that. The company I worked for, was known as a “Revolving Door” company, with many developers in the area having experienced working there at some point. They would join, realize the company’s shortcomings, and then leave in search of better prospects. This pattern was quite prevalent in our area, with several companies sharing a similar reputation.

Candidate Two

The second candidate decided to bring in some code from her current job, which I personally do not prefer, especially when it is only a partial code snippet that does not run independently. Despite this limitation, we were still able to gain insights into her thought process. At one point during the interview, I asked her about the production status of the code (as there were evident issues with it), and the hiring manager playfully nudged me, emphasizing that we weren’t there to critique the code.

Nevertheless, she proved to be an exceptional candidate, and it was clear that she had tremendous potential. As expected, she too eventually left the company for a better opportunity. I had a feeling this would happen, given that our department did not heed my suggestion to establish a training program to help her acquire the specific skills we needed. When companies fail to support the learning and growth of their developers, they inevitably lose the talented individuals they need to succeed.

Always Hire Software Engineers who Love to Learn

Another crucial aspect of conducting such testing with engineers is that it reveals the candidate’s passion for learning. I have emphasized this point repeatedly because our industry is evolving rapidly, with changes occurring on a daily basis. In today’s smaller team structures, typically comprising 2 to 5 engineers based on my observations, it is essential to hire engineers who have a genuine love for learning and continuous growth in their careers. If a candidate actively writes applications at home, it is a significant indicator of their dedication and passion. On the other hand, if they do not engage in such self-driven learning outside of work, it suggests they may have a “9-5 developer” mentality, relying on forced learning only when required on the job. Many refer to such developers as “Code Monkeys,” and aspiring professionals should strive to avoid falling into this category if they aspire to advance in their software development careers.

The Importance of Writing Apps Outside of Professional Work: A Path to Growth and Success

I highly recommend that developers at all levels engage in the practice of consistently writing apps outside of their professional work. I have personally followed this approach throughout my lengthy career as a software developer, and I continue to do so. For instance, I authored a series of articles titled “Real World Cloud App from Start to Finish” on dotNetTips.com. These articles demonstrate how I added new features to one of my free apps using Microsoft Azure. My primary motivation behind this endeavor is to learn Azure, while my secondary goal is to transition from my current Microsoft MVP award to the Azure MVP award.

Initially, writing apps served as a means for me to learn the ropes of software development. However, I now continue this practice to stay abreast of evolving technologies. The applications I developed, which garnered positive reviews, opened doors to new job opportunities, launched my writing career, and even afforded me the opportunity to speak at major conferences worldwide. Little did I realize that those initial apps I wrote would pave the way for my current achievements.

Therefore, I encourage you to write something, anything! Develop apps for app stores, and create open-source libraries to release on platforms like GitHub and NuGet. However, I advise against doing this solely for the purpose of “getting rich quick.” Instead, focus on gaining the valuable experience that you need and let the journey unfold naturally. By doing so, I believe your future as a software engineer will be filled with happiness and success. Additionally, even if not explicitly requested, bring these apps to your next job interview on a thumb drive as tangible evidence of your independent work. If you specialize in front-end development, you can also showcase examples of your work by printing out web pages or application screen grabs and compiling them in a presentable leather portfolio.

Summary

Implementing this approach with candidates enabled us to successfully hire the developers we were seeking. While I cannot guarantee its effectiveness for every company, I encourage you to consider giving it a try if you’re also facing challenges in finding qualified candidates. What do you have to lose?

If your company requires assistance in implementing this process, I am more than willing to lend a hand. Additionally, I am available to support your team in conducting software engineer interviews. Feel free to reach out to me via email at dotnetdave@live.com.

If you decide to explore this strategy, I would be delighted to hear about your experience. Have you encountered any perplexing tests during your hiring process? What types of assessments do you currently use for evaluating developers? Please share your feedback with me via email; I would greatly appreciate it.

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.