My stomach dropped when I found out that I was being laid off! There was so much uncertainty, fear, and anger in that moment. I had so many things that I was thinking about and dreading about my situation. It probably took me about a week to calm down and start looking at my next steps and what I needed to do for my upcoming job hunt. The first thing I did was look at my resume. Thankfully, it was recently updated, but I knew I needed to put an end date where there wasn’t one. Then there was the LinkedIn profile tinkering. And once you are all ready to go, you flip the “Open to Work” flag, and the recruiters find you, and everyone loves you, and it’s easy to find a new gig… Well… Maybe in years past that was the case, but not this time around…. My reality was that for the first couple of weeks, it was pretty quiet.

I’m a full-stack dev, which means I float between front-end development, middle tier (API), and backend (SQL). My stack of choice is Angular with TypeScript, C#, and SQL Server. Being a full stack means you have to know quite a bit between all the different layers of an application. I don’t want to say that we are know-it-alls, but we have to know a lot. However, so much of our knowledge really is dependent on the projects that we’ve worked on. No two projects are the same, especially when you talk about legacy apps (anything built before you). So the “Jack of all trades” moniker is fairly accurate, but what I don’t like is the “Master of None” part.

However, this isn’t a Full Stack Dev vs… post. This is about the Tech Interview. It is the Full Stack Dev’s worst nightmare. I have often said the tech interview is like going to a school you know nothing about and taking a test where you don’t know the topics or the questions ahead of time. It could be broad topics, or it could be very specific topics. It could be definition-based or LeetCode tests. For me, and I think many others, it is very difficult, nerve-wracking, and a bit insulting.

The Tech interview process is BROKEN!

I realize that there are a lot of impostors out there, and you feel like you need to weed those people out. Here’s the thing… 9 times out of 10, the business application development project is pretty much the same. You have your data entry screen, your service which calls your API, which then either calls an Entity framework call or a stored procedure. Why would you ask questions about O(n) or have a developer do a LeetCode exercise manipulating arrays when your application is a standard business application?

I was in an interview where the dev collated a list of questions that were very specific to their application. I understand that they thought those questions were valid, but I knew 5 minutes into the interview that I was not doing well, and this was not the project that I wanted to be part of. Naturally, you may say, “see, it worked! You figured out that it wasn’t the right fit.” Yeah, you are right, it did work. But I would counter with, the interviewer choosing this “testing style” of interview is wasting their time, as even if they find someone to “pass” their test, they are still leaving out the personality part. Remember, we have to work together for 8+ hours a day. How many articles do we have to read about EQ over IQ and the importance of team chemistry?

So what are the arguments for the Standard Tech interview?

Standardization: Technical tests help standardize the evaluation process, ensuring that all candidates are measured against the same criteria. Technical Depth: Demonstrating concepts shows a deeper understanding of CS principles that can be beneficial in solving complex problems. Problem-solving Skills: LeetCode and similar tests can help identify candidates with strong problem-solving skills. Experience Verification: Specific technical questions about past projects can verify a candidate’s hands-on experience.

I was in a scenario where I was interviewing candidates for a technology that I didn’t have a lot of information on. In fact, I had never really used that technology before, and I wondered if I was the ‘right’ person to do the interview. However, I was asked to do it, so I did. My approach was to look up very basic questions and answers about the technology we were looking for and conduct a conversational-style interview.

“What kind of challenges did you face in your last project using this technology?” as well as “What is the coolest thing you’ve written in this technology and why?”. I even managed to work the easy questions into these questions to really solidify basic knowledge of the technology. The answers to that style of question tell me more about the skill of that developer than a memorization test. I could immediately filter out who was winging it and who actually did the work. Plus, when you allow the candidate to talk and feel comfortable, you start seeing communication styles and any frustrations they might have had that allow you to ask follow-ups. I would argue that I was able to capture each of the arguments above this way.

Is it a perfect approach? No. There will be people that slip through and talk a good game. However, those people that might slip through are usually good people as you felt good about their interview. Even with the occasional miss, I believe it is still better than the test-based approach. Let’s face it, unfortunately some people have been unemployed long enough where they can practice and memorize tests and definitions. That does not make them better programmers; they become better test-takers. I’m not shaming the unemployed dev… You are doing what you have to do to get a job. Keep at it, you’ll get one soon enough! My point is that these tests only eliminate candidates, and you are missing out on quality people because they may not have been exposed to exactly what you are working on.

I know that there will be Software Managers and other Developers will say “your’re wrong! It does this, that and this…” Listen, interviewing is hard, the candidate is nervous, it is time-consuming for you and expensive for the company. Unless you have specific needs about O(n), or array manipulation and specifics for needing SUPER DEEP knowledge of a topic, I would suggest that you switch it up to a more conversational approach. You’ll find a lot more candidates that you can train to get up to your standards as well as work with because you’ve gotten an insight into who they are as a person.

For all the devs still looking for a job: If you are in the C#, SQL, Angular space, here is my study guide that I was using: https://github.com/jeffvaccaro/jeffvaccaro/blob/main/study-guide.txt

I’d love to hear about any tips and tricks you may have with studying up for the next interview! Keep grinding, you’re next gig is right around the corner!