## The bare minimum you should be able to cover in an technical interview (II)

This constitutes the second part of a post. Find the first part here.

## 5-Solid understanding of databases.

It might seem that the “old” database systems (MySQL, postgres, Oracle…) are not as cool as the new noSQL systems or other big-data solutions, however the truth is that they are the core of the vast majority of systems.

Understanding the benefits, limitations and trade offs of database systems is key, in an interview you should be able to clearly and confidently talk about:

1. The SQL query language, specifically you should be able to to write queries with a number of joins and filters.
2. The indexes of tables and their limitations: Why adding an index is (normally) the way to solve a slow query? what happens when that is not the case? what is the penalty for having an index? which kind of data structure does a database use internally to represent an index? All of those should be questions that a strong candidate must be able to answer with confidence.
3. Query improvement: Are you able to analyze a query? you should be familiar with different techniques and tools to figure out where the bottleneck of a given query is.
4. Connection leaks and connection pools: What does each of those terms mean? why use a connection pool, what is the effect of connection leaks? It is the job of any decent developer to be aware of those elements.
5. Security: Databases end up storing very sensitive information, there are different techniques to protect such information and there are, likewise, a bunch of bugs/malpractices that can expose such information to the wrong people. Yes, I am talking about SQL injection (among other problems), one would think that by this time developers would have learn their lesson, right?

No spoiler alert here: we have all made mistakes, I have quite a bunch in my own history… fortunately I have learn from all of them, and I have really not repeated them.

If you think that is not your case, think again. Unless you have been in the industry for too little, chances are you have been involved in some sort of mess up: maybe it was not your code, maybe you just approved the pull request, or maybe you just designed the software in a way that it became a total mess: it is all ok, really it is.

Even the NASA engineers have made memorable mistakes, why would you be free of such mistakes? The only good thing of mistakes is what you learn from them, try to visit your own failures: what happened? why? did you take responsibility? It is true that some times software developers are put in a position where it is very likely they will make a mistake: projects with terrible architecture, managers that are just pushing for dead lines… the list goes on. But it is still YOUR responsibility to make things work or raise your voice to warn about the consequences.

Whenever I interview an engineer who claims he/she makes no mistakes I always think that the person is either a genius or an arrogant candidate. It takes quite a level of maturity to recognize your mistakes, I certainly respect that.

## 7-Talk about your own history and your … successes.

Finally: be ready to talk about that project where you nailed it, or that bug that was so hard to fix but ended up fixing that problem that everybody had already given up on.

One of the most satisfactory parts of being a software engineer is the professional reward that we can experiment almost every week by either delivering a new feature or improving an existing one.

You should have 2-3 cases where you where particularly brilliant. Even if you are just a junior developer with 1-2 years experience there must be something that you are proud of, or something that went better than expected, hell you might have even deliver a project ahead of schedule (a rare circumstance… but absolutely epic whenever it happens).

## 8-You should be able to convince your interviewer that you are a nice person.

This might sound too obvious or maybe out or place, but it is fundamental.

A technical interview is a process that tries to answer two simple questions

1. Is the candidate technically sound?
2. Would I have a beer/tea/coffee with the candidate?

We have well covered part (1), but you should really be ready to cover part (2), after all software building is a team effort, developer teams go through a lot: good and bad times, moments of joy and tension… You really need to be a nice person to fit in well.

If you think this is not so important, think again: A junior developer can improve over time to became a senior one, but a senior developer who is a jerk cannot be fixed. Who would you be willing to work with?

This concludes the minimum you should be able to cover… I really hope these advices will help you in your interview processes.

Happy coding.

## The bare minimum you should be able to cover in an technical interview (I)

I have been doing technical interviews for around 8 years, and it is not easy to find great candidates, probably because great candidates last very little in the market, however time after time I deal with candidates that, unfortunately, are not able to cover certain basics, lets go through them.

## 1-Big-oh notation, time and space complexity.

Being able to determine when it is worth to optimize an algorithm is absolutely fundamental, I have seen codes where collections of 100 elements were sorted because a search will be performed once or twice… that says a lot about developers.

Also, it is important to understand how bad or how well out algorithm will do as a function of the size of the input. An image is worth more than words, so here is the fundamental picture to keep in mind.

Anybody doing an interview should have that picture really clear in their heads. The reason? lets go through a simple question: lets say you have 1 million numbers, unsorted, and you will need to search whether or not a given number is in your million numbers, such operation is to be repeated 100 times. Is it worth sorting your 1 million numbers or not?

It is a simple question, and it should have a simple and definite answer, however without the help of the big-oh notation and some knowledge about the running time of sorting and searching algorithms, it is impossible to answer it.

However, with the help of big-oh one can answer this question very effectively.

Doing a sequential search will take linear time, that is $$O(n)$$
Doing a binary search will take log time, that is $$O(log(n))$$ but in order to perform a binary search we first need to sort. Sorting takes $$O(n*log(n))$$ now, in our case we are specifically dealing with $$log_2(10^6)$$ which is approximately 20 as $$2^{20} \simeq 10^6$$

This means that

1. Using a binary search will take around 20 operations (worst case) to find a number
2. Using a sequential search will take 1 million operations (worst case) to find a number
3. The cost of preparing our numbers to be able to perform binary searches is 20 million operations

Now, lets ask ourselves the question again. Is it worth sorting 1 million numbers if we are going to search 100 times within them? The answer is yes, as our initial cost is 20 million operations, but after that, the cost of a binary search is almost none, while a sequential search will take 1 million operations each time.

## 2-Basic data structures.

The simple data structure is an array, but everyone should be familiar with stacks, queues, linked lists, hash tables, trees, graphs and possibly also sets and heaps.

Furthermore, I expect people to be able to implement any of the structures mentioned above. Sure, you will NEVER implement those in real life, but I think it is an interesting exercise to be able to implement those by yourself. I tend to ask people how to implement a simple Stack, and some people really struggle to do so, I would never ask anybody to implement a full hashtable, but I will certainly expect them to be able to do so if a hash function is provided to them.

Being familiar with data structures is key for being able to solve problems, here comes an example: Imagine you are given all the correct works of the English dictionary, how could you implement a spell checker that will not only inform the user if the work they type is correct, but also provide them suggestions in the case the wrote an incorrect work?

Most people will initially resort to a hashtable, however there is a problem with hashtables: they only help you with exact searches, if you type “helo” there is no way to let the user know that maybe he wanted to type “hello” or “hell”. How would you do that? The solution is a trie, a type of tree where each level contains each of the letter of the alphabet, if a particular node is a word, then it will contain a flag indicating so, again lets illustrate this with a picture.

This is a simple yet interesting example on how a problem that might seem very complex at first could be effectively solved using the right structure. Most people operate with linked lists, sets and hashtables pretty much every day, however trees, graphs and other structures might not be used so often but they are incredibly powerful in certain situations. As a software engineer it is your job to know your tools, and data structures are pretty much tools 101 here.

## 3-Basic data types.

What should you know about floating point numbers and monetary calculations? they are no-no, and for good reasons. Due to the internals of how floating point numbers are stored, they cannot represent fractions accurately, the loss of precision is not too terrible for scientific calculations, but it can be really bad for monetary calculations (or any other calculations where precision is critical). As an example a simple piece of python code (the same problem will occur in java)

Now, the expected output of that calculation should be 1, right? well, not really, the actual result is

So, if that happens after only 1000 operations, imagine what floating point numbers could do to multiplications and divisions. And then imagine what would happen if those multiplications and division involve money (currency conversion, tax calculations, margins…) Again, it is your job as a IT professional to know this and use the proper tools. Most languages provide mechanisms to deal with this problem, do you know them?

## 4-Basic object orientation understanding.

Becoming an expert on object oriented programming takes years, even I struggle sometime to find the right abstractions, it is a never ending process but, when done correctly, object oriented programming can solve many problems, as it allows us to work with abstractions rather than low level details.

Can you clearly explain what is polymorphism? without resorting to an example? could you explain it to your mum? that is the level you should be able to provide in an interview.

Do you fully understand inheritance and composition? Have you realize that inheritance can actually break encapsulation (if done wrong)?

I am surprised, quite often I ask candidates about information hiding and most of them are able to explain the mechanisms that languages like java provide for such technique (private, protected, public…) however when asked “why would you ever want to make something private? can you give me an example?” many people actually struggle, furthermore, many people will simply answer that you make attributes private and then provide getters and setters.

You need to understand how information hiding allows you to keep the internal state of the object separated from the outside world, you should be aware of the consequences of not doing so, and you should be able to clearly and confidently explain that.

This concludes the first part of this story.

Happy coding.

## How to fail a technical interview

As a developer, part of my job consists on interviewing new candidates, I have been doing so for about 7 years now. It does not cease to surprise me how many candidates make the same mistakes over an over in interviews, so I decided to share my experience.

Please understand that this reflects only my experiences, it is not necessarily representative of how things work generally in the software industry, also understand that I work in Sydney, it would not surprise me if there are some minor differences in other countries, or even in other cities within Australia.

Also, I would like to note something: whenever I interview a candidate, I am on his/her side, I just want that person to be the good developer we can hire, for two reasons: it is exactly what the company needs and I can go back to coding, which is what I love.

Lets begin

#### Do not prepare the phone screening.

The very first contact you will have with your potential new employer will be most likely a phone screening interview, I have to remark that normally those are relatively easy interviews, after all, you can only verify so much in a phone conversation, however there are a couple of things to prepare.

You should feel comfortable with the basics of the technology you are interviewing for, as an example, if you are interviewing for a Java related position, you should feel comfortable with basic data structures such as List, Set and Map. I will also expect people to be able to explain the usages of equals() and hashCode().

Additionally basic data structures are a must: Arrays, Linked lists, Hashtables, Stacks, Trees and Graphs are things I expect any candidate to understand well enough to explain how to implement them, I think it is also reasonable to be very familiar with big-oh notation.

Basic algorithms are the next must-have: I do not expect people to implement me a quick-sort, but I do expect them to know how it works, at a high level, I also expect people to be familiar with its running time, sames goes for Tree and Graph transversal, basic recursion and so on. If you do not feel familiar with all of those terms, just review them at home, it should not take more than a couple of hours.

#### Do not expect any coding.

So you are interviewing for a developer position and you are surprised you are asked to code during the interview? Why are people scared when they are asked to write code on a white board?

The way I see it, there are two things to be aware here: First, be wary of any company hiring developers without asking them to develop during the interview, this is as absurd as hiring a cook without seeing him cooking first. Second, we normally do not code on paper/white boards, so practice at home, if you think it will be “easy”, think again, as a small exercise, try to code a binary search on paper and feel the pain of lack of auto completion. The good news is, once you have coded a couple of algorithms in paper, coding them in a white board becomes simple enough.

#### When stuck, just stare at the white board, remain silent.

So, here is what is going to happen during a coding interview: you will get stuck, now the question is, how do you react? I have seen far too many candidates just staring at the white board for 5-10 minutes, saying nothing. The problem with this approach is that you are just wasting time that you might be using to explain what is going on in your head.

Sure, sometimes you need a few minutes to organize the problem in your head, but at some point you need to provide feedback to the people interviewing you, maybe you have just a brute force solution, or maybe you have only a partial solution (that does not work in some cases), well, say it, explain the problem, because if you don’t, all I know is that you are staring at a white board.

Showing how you react when faced with a complex problem is important, even if you do not manage to solve the coding problem you still have a chance if you can show what is going on your head, also it allows the interviewer to work with you, maybe hint you and so on.

#### Do not prepare questions for the interviewer.

Almost every interview that I have conducted has always finished with “well, we have asked you a lot of questions, do you have any questions for us?”, now this is a great opportunity for you to know how the company really works.

I got asked a lot of questions like “what’s the tech stack?” while there is nothing wrong with that question, and I am more than happy to answer it, it does not really provide the candidate any extra knowledge, in most of the cases the tech stack can be derived from the requisites of the job description (I mean, if they ask for java, spring and hibernate, I do not think they will be coding in python, will they?).

There are other questions that, while useful, are too generic, for example: do you write tests? almost 100% of the companies will answer yes, but we all know that it does not mean that they REALLY write tests, here are some examples of questions that I would ask and why.

• What is your current test coverage? In order to answer this question, the company you interview for must not only write tests but also measure their coverage, there are plenty of tools to do so, if they are serious about testing, they should be able to provide a good approximation without much hesitation.
• When was the last time you wrote a unit test? Normally that should have happened within a week (assuming of course the interviewer spends more than 50% of his/her time coding.
• Which kind of machines do developers get? This is absolutely fundamental, I have rejected jobs because everybody had to work under windows, and although there is nothing wrong with windows as a desktop system, I really prefer Linux. Also this includes which IDEs developers user and whether or not they are allow to use their preferred one, after all as a coder you will spend most of your time in your computer with your IDE, so it is worth to know.
• What is your branching strategy?: Again, fundamental, you want to know if they have a solid pipeline or if it is something like “oh, we all code against the main branch”.
• How often do you deploy? and follow up question, when was the last time you applied a rollback? when was the last time you applied a hotfix? This will give you an idea of how serious a company is about CI/CD, if you ask them they will always say they do CI/CD, well, if that is the case they should be able to anser these questions easily.
• What is the latest you have ever left the office? follow up by, what is the latest you have left the office this week? As you can imagine, this is related to overtime, I have never interview for a company where they admit to do overtime over a regular basis, however I have seen that more often than not. By asking these questions you are being very explicit, the answer has to be a concrete number, not some fuzzy constructions.
• If you could change one thing in your architecture, what would it be? I love this question, because it actually allows you to peek into the current problems of the company, lets face it, EVERY company has areas where they can improve, and in fact, if they are hiring is because the need help, this question is a good way of forcing the interviewer to give you a quick tour of the technical mistakes the company might have done. Also, I think it shows that the candidate is interested on improving and learning from mistakes.

This is all, as I mentioned at the beginning of the post, this reflects only my personal experiences, and I share it with the hope of it being useful to other people, nothing more.

Happy coding.