Few words about interviews

TL;DR

Interview is a great tool for companies and people looking for a job. It works not only as a form of exam, but it can deliver data to both sides if they will make a good deal or not. And even if they don’t make a deal - they can benefit a lot from gaining new perspectives and there is nothing they can loose - apart from time.

Context

When I was looking for the first intern/job as a Software Engineer I remember that I was really stressed out by this. What if they ask me how PostgreSQL works internally?! What if I don’t know what is the difference between equals and hashcode? What if I will miss something?

Well… I was treating interviews as some kind of exam that I have to pass. However, after getting some experience, reading few smart books (like The Pragmatic Programmer or Software Craftsman, The: Professionalism, Pragmatism, Pride), conversations with other software engineers and even interviewing other software engineers I understood how wrong I was.

And even if I landed into my first job as Software Engineer then second one and after that into next one… I never stopped interviewing. Before I explain why…

Why do companies interview people before hiring them?

That seems to be a trivial question. Company wants to have a new employee. Company have some money and wants to invest it smart, so the best employee will be that one who brings the most value (in most cases - thanks to him company makes even more money). Common misconception is that as a software engineer the deeper you can go with details about some technology the more value you will bring to the company. This is very untrue statement. It doesn’t matter how good programmer (code monkey) you are if you cannot understand business (blogpost that elaborates more about it ). So yes - companies have interview process to find the most valuable employees but in case of software engineers in 99% it doesn’t mean they need the be technology masters - other skills count as well. But is it really an exam?

Why candidates agree go for interview?

First thing that can come to your mind - they want to prove their skills. Ofc - it’s pretty hard to prove your skills in such limited time. You just can’t build a real-world application in one or two hours (or in eight hours if we think about more complicated recruitment processes like Google’s one). Even if you could you wouldn’t be able to prove if you are good team player and other skills necessary to being good software engineer. But still some companies believe that they should examine if you know all those technical details about Database X or language Y (which are the easiest stuff in the process!).

Second reason - candidate wants to know what the company look like. I (as a candidate) want to know for what do I sign. If everything works out I will spend 8 hours per day there, trying my best and hope for being satisfied from my work. So it’s worth to ask. And even if sides don’t like each other… They don’t loose too much - time at most (but not so much of it). However, both sides get some new perspectives…

Interviews are like dates

In interview process both interviewer and interviewee can benefit. Usually both interviewee and interviewer share their experience, stories and can tell how something looks in their companies. It can generate new ideas, and sometimes feeling: “gosh… so good that I work in normal environment”. What’s funny - both sides can think the same in exactly same moment! There is nothing wrong with that - we all have different story behind us and we interpret reality in different ways!

It’s better to end too early than too late

Interviews are also a cool tool to avoid a situation where new employee land in the company he doesn’t like. That’s why I keep a list of questions that I like to give my interviewer, so we both know what are our expectations:

1. Do you do pair programming? If not - why?
2. Do you write tests for your solutions? If not - why? If yes please name types of tests you do.
3. Do you use DDD? If not, why? Do you use event storming for gathering requirements or modeling your solutions?
4. Do you have code reviews? If not - why?
5. What measures do you take to keep high quality of your solutions?
6. Which option describes relationship best between software engineer and business:
   1. there is no relationship at all
   2. business says what to do and SE does it
   3. partnership - software engineer can question choices of business and ask for ‘why?’ not only for ‘what? '
7. Do you have CI? Do projects build automatically after code is pushed to repo?
8. Do you have CD? Do projects deploy to environments automatically after code is built?
9. Are software engineers responsible how their solution work on production? Do you have duties and react to alerts when anything goes wrong?
10. Is software engineer responsible for setting up logs, metrics, dashboard etc.? Or is it delegated to some technical platform?
11. Do you agreed on some company-wide requirements/good practices for projects like setting SLA, contracts, gathering metrics and configuring alerts or it’s something you don’t like/need to do?
12. Are teams autonomous in your company? Can we (as a team) agree on what tools we use, what languages we use, how we solve something and how we work or rather we have some rules coming from upstream and we need to adjust to them?
13. Is software engineer responsible for infrastructure? Does software engineer need to create and maintain databases, queues, k8s clusters for each project or there is some kind of technical platform?
14. Do you use any agile frameworks like Scrum/Kanban?
15. Do you care about about personal development? Workshops, FedEx days, conferences or other means of gaining new knowledge? What’s the budget for that?
16. Do you write postmortems when something goes wrong? Or maybe you do premorters?
17. Do you contribute to open source world or share your knowledge by writing blog or maybe make some talks on conferences?
18. Let’s say i decide to work for you. I see super cool opportunity from which company can benefit a lot. What is the process of making it happen? Do I have some options to validate the idea very fast - let’s say I can get valid criticism that this idea is bad or resources to realize this idea if it seems good?
19. What about remote work - do you need me in office more often then once a month?
20. Talking about remote work - do you have some async elements like async daily/async estimates (if you estimate at all)
21. Take into consideration your best project (in your opinion): How many bugs appeared in the backlog in last month in this project?
22. Let’s say I become a Java Developer or any other role in your company. How am I getting to the next level - Senior/Principal/Magician/whatever?

Sum up

To wrap it up - interview is a great tool for companies and people looking for job. It works not only as a form of examine, but it can deliver data to both sides if they will make a good deal or not. And even if they don’t make a deal - they can benefit from gaining new perspective.