I had a mini-technical interview last week for a backend developer role using Ruby as the main language. While the questions were not very tough, it’s been a while since I had to explain technical concepts – especially under pressure.
Unfortunately, we don’t get too many do-overs in life, but we can learn from the past and keep moving forward. When we face the same problem in the future, we can hopefully handle it better. What can we do to help our future selves? One thing we can do is write about things we have learned. This will hopefully plant them more firmly in our minds. I thought I’d write out the questions and answer them how I would have liked to have answered them if I could answer them again. Whew. Without further ado, let’s jump in.
First question – Which http status codes exist and what do they mean?
I admit, it was a pretty easy one – just a general, low-level question. I had an ok answer, but I’ll give it another go. Http status codes range from 100 to 500. The most common codes being in the 200, 400, and 500 ranges. A 200 means the request went through successfully – not much more to it than that. Anything in the 400’s means that the connection to the server was ok but request was not good from the client. This could be anything ranging from an incomplete form to one of the most common – a 404 – which means the path was not found. Basically, if we type in an address such as http://www.weather.com/alskdjf, the request will hit the server and the path (alskdjf) will try to be found. In this case it won’t and the request will come back as a 404. Most developers will take this into consideration when building a website/web app and route you to their 404 page.
An http status code in the 500’s means that there was an Internal Server Error. It could be that the server is down at the moment, or quite possibly it just doesn’t like you:)
Second question – What http methods are there?
It should have been another layup. Again, my answer was ok, but I’ll try again. There are quite a few http methods, but the most common ones used for RESTful architecture are GET, POST, PUT, PATCH and DELETE.
Follow up – What is the difference between POST, PUT, and PATCH?
A POST request will create a new resource at the provided URI. So let’s say we are creating a new account on Facebook. When we fill out our information and hit submit, a POST request will be sent to create a new resource in the database with our info. A PUT request will either find the existing resource and replace the whole resource with the new one. Or if the resource doesn’t already exist, a new one will be created. A PATCH request will update an existing resource. Say we want to update our email address on our FB profile. When the PATCH request goes through, it will find our existing information and update just the email portion of the resource – not the whole resource.
Third question – What does indexing do?
Welp, I’ve actually been using indexes quite often with MarkLogic (eek!), but my mind turned turned off at this point. I think I said something about primary keys in a table and associations between tables. As soon as I stopped talking I knew I was way off. Let’s try that again.
Indexing is used to speed up data retrieval from the database. Think of a book. Now imagine we wanted to find the page that a certain topic was on. What would we do? We would go to the index and find what page it was on! Now imagine this book didn’t have an index. We would be forced to scan every page in the book to try and find what we were looking for. This is very similar to what would happen if we didn’t have an index on our table.
Indexing is configured by putting a data structure on a column in a table. This data structure, in most cases a B-tree, acts as a pointer to data in a table. For example, we visit FB and we want to look up an acquaintance in the search bar by their last name. Let’s say our acquaintance’s last name is “Yorke”. If the “last_name” column is not indexed in the table, the query will have to run through every single row in the table to find the users with the last name of Yorke. With billions of users stored in the table, that could take some time. However, if the “last_name” column is indexed, the query will run significantly faster.
Fourth question – Explain composition over inheritance
I knew I read about these concepts last year when I was studying a few design patterns, but in the heat of the moment, I just couldn’t recall. I think I mumbled something about classical inheritance being bad…something, something, something. It’s amazing what a little refresher will do!
Both composition and inheritance are design patterns in Object Oriented programming that we can use to keep our code DRY. In other words, they let us reuse code but in very different ways.
With inheritance, types are defined by what they are. So let’s say we have a monkey. Well, a monkey is an animal, so monkeys can inherit characteristics that all animals share. That sounds pretty reasonable to me, so what’s the issue?
One of the arguments against inheritance is that things might change down the line. We are forced to predict future behavior of our classes without having all of the information we may need. The example above is a very simple one, but in the real world, we would most likely have an inheritance tree. Imagine the whole animal kingdom mapped out this way using inheritance. If we had to make any changes in the base class, it would likely have consequences for all the subclasses and quite possibly break much of our code. This makes inheritance very inflexible as a design pattern because we can’t make changes without breaking a lot of our code.
So should we avoid inheritance like the plague? Nope, not at all! Like any tool, we just have to use it wisely. We wouldn’t use a hammer if all we had were screws. The rule of thumb here is to use inheritance if you have a shallow tree and you know for sure that your parent class isn’t going to change. If we shouldn’t use inheritance, what should we use?
We learned earlier that when we use inheritance, our types are defined by what they are. When we use composition, our types are defined by what they do. Here we don’t have to predict the future behavior of our classes, which will leave us with many less headaches down the line. We can pick and choose what are objects look like based on what they do. Maybe all we need our monkey to do is see, swing from a tree and eat a banana. Our Monkey class will only be given these methods – and only these methods. Now our monkeys are lean and not weighed down with a ton of baggage they ultimately won’t use.
Forget Me Not
To my future self – You’re welcome.