Softwarecraft

This article is part of the The Anatomy of a Technical Interview series.

In this series I share with you my experiences and insights that I gathered while holding technical interviews.

I’ve seen my fair share of interviews while I was applying for various jobs and positions throughout my carrier. Many of them were either too technical or too focused on the framework of the week or other minutiae. Some companies required coding interviews, which are lovely, but useless. I’ll try to expand on this topic in it’s own post.

This is not to say that I have had no good interviews. I did, and some were provocative and challenging, and from some I actually learned a thing or two, even if I did not get the job.
The ones I loved the most were those where the atmosphere was friendly and the conversation just “flowed”; where there was an exchange of experience and a amicable discussion on technical topics.

My experience was that interviewees were talking about very niche, high-level frameworks and tools, but lacked a strong grasp of fundamental concepts and principles such as SOLID, TDD (or even testing in general), architecture and even OOP.

My experience both in “the field” and with being an interviewee, made me wonder what I would like to be asked at an interview. What would an ideal interview look like?

When the time came to hold my own interviews, I knew I wanted to focus on the “fundamentals”. I did not care about frameworks, nitty gritty details of how memory is allocated or some other stuff like that. That is not to say those things were not important, just that they were not important to me (and not for the position I was interviewing). You can build anything on a strong foundation.

I was determined that my interviews would be a nice experience, a friendly chat on topics that we both cared about as fellow programmers, and for people to actually walk away with something, even if they did not get the job.

So I came up with the following topics. Even though they are formulated as questions, they are more like bullet points, just to get the conversation going.
They touch on OOP principles and concepts, but they focus on SOLID principles, because I believe that if one knows and really understands them, everything else can be learned and is “syntactic sugar”.

Articles in this series:

• What Is a Constructor?
• What’s the Point of Constructor Parameters?
• What Are Interfaces?
• Ellipse vs Circle
• SOLID Principles
  • Single Responsibility Principle
  • Open/Close Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion (and Inversion of Control) Principle