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:
- The SQL query language, specifically you should be able to to write queries with a number of joins and filters.
- 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.
- 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.
- 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.
- 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?
6-Talk about your own history and your mistakes.
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
- Is the candidate technically sound?
- 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.