Everyone that knows me, knows that I enjoy a good interview. I even enjoy the bad ones sometimes because if anything, they at least make for a good story later on. And this last interview didn't disappoint me one bit. It went exactly the way that I knew it was going to go. It was like a second year in college programming midterm, except that instead of writing, you had to answer each question out loud, within seconds. And every second that went by with silence was the most awkward second of your life. Yeap, that's how it went.
I never do well in these types of interview. And it's for a good reason. I've been programming for the greater part of the past decade now, and I think at this stage in my life I no longer care about bubble sorts and stack implementations. That's not what I do on a daily basis, and it's not what I want to do with my career. If you genuinely need someone to implement stacks and queues all day long, then write that down in the job description and I'll move on.
So here are some of today's highlights. Most questions revolved around object oriented programming and many many definitions. I answered most I would say and only moved on if I truly had never heard of the terms.
1. Name the OOP SOLID principles
To which I respond "Is that an acronym or are we talking physics here?". Truly had no idea what he was talking about. Was it something that maybe I covered in college? Perhaps. It's been about 8 years. And at my previous jobs no one ever really said "Ey, did you use the SOLID for this?" Hasn't happened as of yet. So let's find out what these SOLID principles and why they are so awesome.
First off, SOLID was introduced by Robert C. Martin, a software engineer in the early 2000's. So it isn't a thousand year old theorem that was been circulating the world, unfortunately.
- S – Single-responsiblity principle
- O – Open-closed principle
- L – Liskov substitution principle
- I – Interface segregation principle
- D – Dependency Inversion Principle
I won't run through each of these individually, because that would be a post all of its own. But essentially, SOLID are principles created by Robert Martin that can aid in making systems more agile and more refactored.
2. What are Nullable types
A Nullable type is an instance of type the System.Nullable struct. It can represent whichever type of value is given and one additional value of null. It's good to use if you're working with data from the database and as well all know sometimes in our databases we'll have a null value where an integer should be. Sounds pretty convenient actually. But personally, I've never used a Nullable Type.
public void Example()
{
int? num = null; // NULLABLE TYPE
if (num.HasValue)
Response.Write("Has Value");
else
Response.Write("Value is Null");
}
3. Name and describe design patterns
I thoroughly covered design patterns when I was in college. I even wrote a paper about it at some point and back then it was kind of cool. Then I started working and no one ever discussed design patterns again. You use them all the time. You probably don't realize it, and you probably don't call it a design pattern, but at various points in your programming you've come across them and you've used them. I managed to get out a "Factory and uh..Singleton?" answer as the judging eyes cut through me.
So here is a list of popular design patterns you can mention at your interview, which you may or may not forget.
- Abstract Factory
- Builder
- Factory
- Multiton
- Singleton
- Prototype
- Decorator
I can name them, but ask me anymore about them and we're going to have a problem. I get this question all the time I should say, and each and every time I forget them.
4. Create a stack without using .NET collection objects
Just in case one day, all of the collection objects in the world vanish and I really really need a stack. So for this I used an array of int's. I could of made one using Generics, but time is of the essence here. Stacks are simple for the most part. You can insert from the top and you can remove items from the top. Or Push and Pop respectively.
This wasn't a bad question really. But it isn't a realistic one. This scenario will never happen when I'm coding. To create a stack in .NET I would simply create a new Stack object and that's it. And if for some reason the Stack wasn't available, I would use a List, and if a List wasn't available, then I would quit because I'm obviously in the wrong place.
There were plenty more questions thrown around during the hour and a half and overall it wasn't too bad. It was, like I said, what I expected. But I was really hoping that it wasn't. I was hoping for something more. These questions I found the answer to on Google after about 5 minutes, and I imagine they also came from Google as well. I was hoping for a meaningful conversation about the companies needs and about what I could offer them, but it never came. As soon as I defined a foreign key, time was up, and it was time to head on home. Questions about stacks and design patterns are great for developers new to the work world, but at what point do you decide that it isn't applicable anymore. Do you ask the person with 20 years experience to create a linked list?
I'll see in the next few days whether I get a second interview at this company, and if I take them up on it or try my luck somewhere else. And if I don't get a second interview, I'm really not that dissapointed :)
Walter Guevara is a Computer Scientist, software engineer, startup founder and previous mentor for a coding bootcamp. He has been creating software for the past 20 years.
Last updated on: