DESCRIPTION

by Radek Kowalski

It’s been 8 years since I first sat on the more comfortable side of the recruitment table. I was a developer and my team needed more of my kind. I might have been more stressed than some of the candidates. I took a long time to prepare, reading over and over through the CVs and crafting the interview questions for each candidate.
Now, hundreds of interviews later, I’m a lot more comfortable and efficient at talking to potential colleagues. What hasn’t changed is that I only have an hour to learn about the candidate and only their resume and LinkedIn profile to prepare upfront. That’s why small things matter. Whatever I notice during that hour or on the A4, are my only clues on the person I would be working with the coming years. Unfortunately, there are lots of great candidates that simply suck at interviews and often I can’t tell them from the poor candidates.
To draw the stage, I am a solutions architect at a corporate startup. We’re backed by a large, successful company. We’re located at the heart of one of the busiest cities of The Netherlands and we make use of cutting edge technology. We have an awesome, inclusive culture. And we’re always looking for software developers. This makes my task of getting the candidates enthusiastic about the company very easy, but it also means that we’re setting the bar pretty high. Would you like to know how I perceive you when you sit there on the other side of the table? Read on.

The resume

The goal of the resume is to convince me and my colleagues that it’s worth spending the time and effort on getting to know you better. I’ll be looking for what’s relevant for me and my employer. First I’ll give it a quick scan, identify the relevant points and focus on those. If the document is long and detailed on the irrelevant parts, I might miss the relevant ones. Don’t write essays. No more than one A4, please. I don’t need to know which elementary school you attended or what you worked on 15 years ago (unless it’s very relevant). Mention only your highest level of education. Highlight your focus and achievements from your last couple of roles. Explain your motivation. The best resume is one that attracts my attention and leaves me craving for more details.

Code samples and publications

Do you have a code repository with your hobby projects? Did you write a technical article on Medium? Add a link to your repo and articles feed to the resume. This will encourage me to invest more effort in learning about you. And you can be pretty sure we will talk about your article and code once we meet. We will be discussing your work, which will create an opportunity for you to impress me. Of course, it can also have an adverse effect. Don’t shoot yourself in the foot by sharing poor quality code or one you can’t explain.

Get ready for the interview

Were you invited for an interview? That’s awesome! Now it’s time to prepare.
Do you know what we do? Sure, we’ll explain it in the interview, but the first time you hear it, you will need time to digest. This way you miss a chance to ask relevant questions and to show us that you come prepared. Look at our website, check the company profile on LinkedIn. Look at the names in the interview invite. Can you find the interviewers on LinkedIn? Check their background so you know what to focus on. Is your story going to sound the same if you tell it to an HR manager, a product owner or a developer? Do the profiles of the interviewers reveal their preferred tech stack? Did they publish any articles recently? Look for common interests so you can bring it up during the interview and demonstrate your knowledge on the shared topics during the interview.
What questions would you ask if you were interviewing for the position? Don’t let the obvious questions take you by surprise. Why would you like to work for us? Why are you leaving your last job? What do you expect from your next employer? What gives you energy? Where are you heading with your career? How can you help us? These are short but powerful questions that you’ll surely hear in one or other form.

The interview

I remember hiring some great guys who delivered mediocre assignment code. I can’t remember hiring a single person, who delivered excellent code but came across as a poor match in the interview.
The interview mostly starts with a round of introductions. Memorize the name of the person you’re talking to and use it. It helps make the conversation more personal and it’s a sign of your outgoingness.
Yes, we really want to get to know you. Tell us a bit about yourself. Don’t start with your working history. First of all, you’re a person and this is our chance to get to know each other a bit before we commit to seeing each other in the office every day. What are you like? What do you like?
Yes, of course, we want to hear about your working history, but it doesn’t have to be complete. Don’t start with your first job and go all the way to the current one. I don’t need to know in detail what did you do ten years ago unless it’s relevant for the role.
Did you do your homework? Do you know what we do and why? Do you know what technologies we use? Do you know what is the role of the person you’re talking to? Ask if you don’t. Craft your message to the audience. Don’t explain the details of your favourite logging library to the HR manager. Talk about code to a developer. Explain your decisions to an architect. Tell the manager how you work in a team. Pick the details from your past that explain why you’re a match for the role. I don’t need to know that you were delivering pizza during your studies. And I don’t need the full list of technologies you used in the past. Pick one or two, that are the most relevant and explain why you used those and what would you do differently if you were doing it again.
You’ll be asked some technical questions. Their obvious goal is to verify your knowledge. One other thing they do is reveal your attitude. Don’t you know the answer? The best thing to do is admit it and ask what the answer was. This way we’ll see you as a curious and honest person, who likes to learn. Don’t start throwing buzzwords around. Don’t evade the question by telling us everything else you know or ridiculing the question and the interviewer. We’re not risking hiring a person who would cheat on us.
Don’t force yourself in someone else’s shoes since they’re not comfortable in the long run. Don’t try to be a match at any cost. Share your opinions and preferences. This is the moment to make sure you can pursue your personal and professional goals at the company.
A job interview is a conversation where my goal is to learn about you and yours is to get to know your potential future employer. Don’t be shy. Ask questions about anything that might impact your decision. The people you’re talking to might soon be your colleagues. Ask them about their experience with the company, their motivations, their current challenges. Be aware that the questions you ask are often better hints about you than the answers you give.

Development task

If you’re applying for a developer role, most likely you’ll be asked to show your skills. Many people see it as a coding assignment. Lots of candidates focus only on this part, forgetting that this is a taste of how you work. How do you deal with poor requirements? Do you ask questions? Are your questions relevant? Do you only ask questions or do you propose solutions?
Why are you doing this assignment in the first place? We don’t need the software you’re building. We want to see how you deal with challenges. Were you asked to spend no more than 4 hours? Do you need 10 hours to do it right? Can it be deliberate? Will you spend those 10 hours? Will you tell us you did? Or will you only use the time given? How will you use it? Will you deliver a functionally complete, dirty piece of code without documentation and reasoning behind your choices? Will you focus on the functionals and ignore the non-functional requirements?
Have you ever asked yourself who will assess your deliverable and what will they expect from it? Most likely your potential colleagues from the dev team would like to see maintainable, readable code. They won’t be impressed by fancy frameworks unless they see the value. They don’t want to waste time dealing with stability issues in the future so they’ll appreciate the usage of stability patterns and good observability. They’ll spend just a couple of minutes assessing your code. If they can’t immediately follow your solution, you lose points. They won’t read tomes of documentation. A small test suite will come handy both to prove your focus on quality and to make it easier to understand your code structure.

Good luck with your interviews! I hope you’re feeling a bit better armed. And if we ever meet at the recruitment table, please mention this article. Then I will know you did your homework.