Interviewing Tips: Technical Challenges – Coding & more

After making it through the initial application selection and conquering a first set of introductory interviews the interview process often moves on to some form of “technical challenges”. The goal here is to check your skills on a practical task in the area you will be working in. Oftentimes they are used to sort out people that can just talk “nicely” about doing things vs. actually doing them. The challenges will often be a basis for further conversation. Challenges can take many forms, and so this post will first give some general tips and then dive into the different forms they can take and what to look out for.

The focus of this post will be engineering, as that’s what I know best, but a lot of the general tips should be generally applicable. We’ll first look at a good mindset and some general tips. Then we move on to different challenge setups – namely, is it take-home challenge or a live challenge. To round things out we’ll examine different challenge topics: Coding, Pull Request Review, Architecture & People Manager. 

Who am I to speak on challenges in interviews? I’ve done quite a few of them myself and also was the one grading them on many (> 100) occasions as well as teaching people how to grade them. Thanks to my friend Sara Regan for proofreading and providing suggestions.

As a small disclaimer, of course these tips are biased towards how I grade challenges and how it has been done at companies I work at. There are probably people out there who are not interested in you deliberating options and just want you to quietly solve a challenge. If they exist, I’d say they are by far the minority. That said, of course people can also have valid different opinions and approaches to this. Grain of salt applied.

This part of a blog post series I’m writing covering:

• CV, cover letter & screening interview
• Technical challenges ←you are here
  • Bonus: Reexamining FizzBuzz Step by Step – and allowing for more varied rules
• Interviews

Let’s get into it!

Mindset

Let’s get in the right mindset to tackle the challenges ahead.

The most important thing that I think most people get wrong about technical challenges: It’s less about IF you can solve it, but about HOW you solve it.

Many times I’ve seen someone seemingly half-ass a challenge as they regarded it just as a small hoop to jump through to get to the “real” interviews. This is often exacerbated by the problems given out to be perceived as “toy problems” that are easily solved. This was perhaps most showcased in an interview where the candidate was refusing to implement FizzBuzz instead showing an online solution that worked with a precisely initialized randomness generator. Solving it is not the point.

Most challenges will include something akin to “treat it as if it was real production code you wanted to work on with a team” or something to that tune. I can only implore you to take them seriously. In many cases, whoever is reviewing the challenge doesn’t know you or your background and they can’t assume you know something. Put yourself in their shoes: they want to hire someone and can only assume that during the hiring process you’re trying to show your best self. Even if they don’t assume that, they might see other people who are more diligent and will be more likely to give them the job. Fair or not, this is what they have to go by to see if you’re a fit for the company and also at what level they think you can work at.

You may also be surprised by the statement that they don’t know you, after all this is already after a couple of rounds of interviews – they must know you, right?! Well, it depends on the company but many companies try to remove biases from the process as much as they can. That means that especially people who grade take home challenges or do an in person technical challenge with you often haven’t seen your CV nor have they been in a previous interview. Their task is to judge your proficiency solely based on the challenge. And so, give it your best to leave the best impression. This is not the case everywhere, especially small companies can’t afford to do this. However, it’s still relatively common these days as far as I’m aware.

General Tips

Let’s start it off with some quickfire tips for all challenges – coding, people manager, case study – before we go into more detail:

• Take the challenge seriously (yes, I’m a broken record on this), this is an interview situation – it’s fair to assume that they expect you to bring your best and you really should. Aim to deliver high quality and if in doubt mention what you’d do normally and say why you don’t right now or ask the interviewers if you should.
• Communicate your thoughts and decisions! As I said, it’s about how you solve a problem, people can’t peek into your thoughts so make them accessible to them.
  • Record questions you asked yourself
  • Communicate decisions you have made along alternatives you considered and their tradeoffs
• If you don’t know how something is meant, ask the interviewers esp. about ambiguity. I have seen many challenges where ambiguity in the challenge description was part of the challenge design to see how you deal with ambiguity and how you try to clarify it. Asking questions about the problem or even how far the solution should go usually nets you bonus points. Especially if you are unsure about a question or requirement make sure to clarify your understanding to avoid going off in the wrong direction as much as possible
• Go through company values and the job posting again before solving any of the challenges. They give you an idea of what to focus on. If “documentation” is one of the company values and you provide none, that doesn’t spell well for you. If a major part of your future job is solving database performance problems, you should make sure your schema and query design in a coding challenge are immaculate.
• Nobody expects you to be perfect, a mistake or even a couple mistakes don’t disqualify you. Keep going.
• Sadly, not all challenges, interviewers and reviewers are good. Some of them are pretty bad actually, due to a host of reasons (sometimes unqualified engineers are thrown into the mix of interviewing). Try to follow the tips to make the best out of the situation, but I’ve even heard of interviewers refusing to engage in questions about the task. Always remember that interviewing is a two way filtering process – it’s fine for you to decide that you don’t want to work for this company. I have once aborted an interview process because I was sure that what they filtered for with the interviews as I experienced them was not a culture I’d like to work in.

Challenge Setup

Generally speaking, there are 2 types of challenge setups – you can take the challenge home and solve it on your own time or you may need to solve it live on the premises (“in person”). Both challenge setups have their peculiarities, so let’s take a look at them.

Take-Home Challenges

Usually you get sent the challenge and then have a week or 2 to solve them. They usually also fall into 2 categories (or a mix), challenges that are just graded by someone or challenges that you bring with you to the next interview to discuss them with someone.

Here’s what to look out for specifically (while the general tips still apply of course):

• Sadly, most of the challenges will take more time to solve them than advertised. I don’t know why this is, but I usually think that someone comes up with an idea that tests as many things they deem important and then pack them all into the challenge. They then make the typical “guesstimate” how long they take to solve and are off by the usual factor of 2-3x. If it takes longer than you’re willing to invest, make sure to communicate it in the challenge or better even ask your contact person. As in: “I don’t think I can finish the challenge due to time constraints, can I get more time please or alternatively could you please tell me if I should rather focus on finishing all the requirements or on writing tests?”
• Taking into account the above, make sure that you have enough time during the allotted time frame to solve the task without depriving yourself of sleep. Also be careful not to splatter your schedule with too many coding challenges at once.
• Especially with take-home challenges document your major decisions, as you may not be there for the reviewer to ask questions. Be proactive about this. For coding challenges I’d feature a section in the README about decisions taken and then also reference it from relevant parts of the code via comments – make it impossible for the reviewer to miss. They’re also human and make mistakes after all.
• If you think something would be too much to include right now or you can’t fit it in due to time constraints, again document it. A common case in a coding challenge would be “normally I’d put this in a background job queue, but due to time constraints I’ve decided to leave it inline for now”.
• Review your entire challenge before submission with the mind of a reviewer. Read the challenge description again and make sure you covered all the points.
• If the take-home challenge is the subject of a later interview, make sure to re-review your own challenge before the interview. Sometimes a month or more can pass between you completing the challenge and the interview – you should be intimately familiar with it.

Live Challenges

These are challenges where you are presented with the challenge in an interview setting while the interviewers are present. Sometimes you are given a short time (~30 minutes) by yourself to study and prepare, sometimes everything is done on the spot. This is often an extremely stressful situation, but if your interviewers are any good they’re aware of that and will try to make it as comfortable as possible for you.

These tips are also applicable if you first solved a take-home challenge but are then discussing it in a later interview.

• Ask clarifying questions! About the problem in the challenge, about how you are expected to solve it and about what you can do (“Can I google?” – answer should usually be yes). This gives you the benefit that you know exactly what you should be doing, but also gives you some time to already think about the challenge and calm down.
• Restating the core of the challenge in your own words is a great way to absolutely positively make sure that you’re on the same page as the interviewers about what the task is. For challenges, I like to keep my own bullet points on what is required – for instance at the top of the file for a coding challenge.
• Come well prepared. A live challenge should never be sprung on you out of the blue. For a coding challenge make sure that you have your programming environment completely set up as you need it and confirmed working. At best, create a small sample project before at home with all the basics setup working. You don’t want to start installing Ruby & VS Code during your interview.
  • Also, be aware that if done on your personal laptop (no matter if remote or locally) people will likely see your desktop so make sure it’s presentable
  • Turn off notifications/communication programs in advance so that you don’t get distracted and so that your interviewers don’t see something they shouldn’t see
• Everybody understands that it’s a stressful situation, take some time to think through the problem, you don’t need to be talking all the time.
• However, still remember to communicate major questions you are thinking about or decisions you are considering right now. This helps your interviewers, and they might even help you. For instance, I’d always help people if they were searching for a specific method or how to set up their test environment. The interview shouldn’t be about testing easily google-able knowledge, however sadly some may be.
• Some of these will be labeled as “pairing” challenges, 99% of the time it won’t be actual pairing. While the interviewers may help you and discuss problems with you, they usually won’t give you critical solutions or take to coding themselves. I feel the need to mention this, as I always feel that this “pairing” label is deceptive. However, if they do give you suggestions, consider them and elaborate on them.
• Sometimes the challenge isn’t even designed to be doable in the allotted time or there is a base version with multiple “extension points” in case there is time left. A good interviewer will tell you this. If unsure, ask. I have passed coding challenges in the past with flying colors although I didn’t finish it. 

Challenge Topic

There are many different main topics for challenges throughout different companies and seniority levels – the most common of which is certainly the coding challenge for developers. They often have their own specifics to go with them no matter if they are take-home or live, so let’s dive into them!

Coding Challenge

An oldie of coding challenges

They are usually part of an engineering hiring process in one form or another. A “trial” day is also a coding challenge in big parts, as in you’re given a problem and are asked to solve it with the people around.

Whether or not coding challenges are good is not the topic of this blog post. I know many programmers hate them with a passion. I can only tell you that I’ve seen candidates with 5+ years of experience that couldn’t explain what a `return` statement does. Especially if you have a lot of open source code it’s common to wish that they’d just review that instead. And that makes sense and some companies do it. However, a challenge comes with the pro that it’s normally standardized across the company, can be the basis of discussion in further interviews and it hopefully probes for skills relevant to the job. For instance, you can say people could just look at benchee when interviewing me, but it would tell you nothing about how I work with databases or web frameworks.

Why am I telling you this? I’ve seen more than a couple of candidates who let their disdain for any type of coding challenge show while they’re solving it or discussing it. That’s not in your best interest – if you take on this step, even if you hate it, handle it professionally.

• One more time: Take it seriously! Show your best work!
• I mentioned before that challenges often contain a phrase like “production quality” but what does that mean? Here is a small list:
  • Naturally the application fulfills the task as described
  • Tested appropriately – in some places missing tests are an auto reject, also make sure the tests actually pass
  • The application should not emit warnings
  • Reasonably readable code
  • No leftovers like TODO comments or out commented code
  • A README that describes what the application is about and how to set it up
  • Document the versions of all major technologies you have used (Elixir/Erlang/Postgres version)
  • It usually does not mean that the application should actually be deployed, although it may earn you bonus points
  • Similarly, you don’t need to have a CI running unless you want it for your own safety (the amount of challenges I’ve seen that were broken on some ‘last minute refactoring’ is staggering)
• Remember that it is more about how you solve it versus if you solve it. You can give an impression of overengineering or underengineering all too easily.
  • A classic thing I often see is people completely forgetting about any form of separation of concerns, and just mixing as much as possible into a single module as “the challenge is so small”. This is usually not in your best interest, as you want to show how you’d work on a “real” project. Also, it usually makes for overly complicated tests.
  • On the other end of the spectrum I see people basically making up future requirements that are in no way hinted at in the challenge and so they make their code overly complex and configurable, sacrificing readability.
  • Both of the above are bad, best document why you did or didn’t do something and say what you could have done differently. 
• While using linters & formatters is usually not a requirement, they help you catch errors and make it nicer to read for your reviewers. I especially recommend using these if you’re rusty.
• It should go without saying, but follow best practices as you know them: Add indexes where appropriate. Don’t use float columns to store money values.
• Communicate decisions! For instance, you may have decided not to add an index for a column that is queried because the query is fast enough without it and the application is write-heavy and so the index may do more harm than good. Without documenting this, the reviewer will never know and might just assume you don’t know how to use indexes.
• Be mindful that some reviewers will read your git history, avoid cussing out the challenge or company. (yes, this point is here for a reason)
• If you use unusual patterns, make sure to explain what they are and why you are using them (and ask yourself if it’s really necessary). 
• On take-home challenges: Make extra sure to use readable names and add a bit more documentation than you usually would, these are people that don’t know you and can’t ask you. Make the reviewers job as easy as possible.
• Especially for take home challenges I’m paranoid that it won’t work on the machine of the reviewer. So, right before submitting I’ll clone the entire repo freshly into a new directory and follow my own setup guide to see that everything works and I didn’t forget to check in a file or forgot a setup step.

Let me expand on “document things” a bit more. I remember a peculiar coding challenge where its design was problematic as it sent all requests through a single central GenSever essentially bottle-necking the entire application. I wrote a whole paragraph on why I think this is a bad design, but still implemented it as the task description specifically asked for it. I then went into how I would implement it differently and what I also did in the current challenge to lessen the negative impact of this architecture.

Some coding challenges you will encounter aren’t truly coding challenges but puzzles. I’ve seen coding challenges that just directed you to an URL and from there you need to figure out the format, get links to CSV files, a text file and then try to figure out what your task is. I can just say that I think these are terrible, try your best to solve them, but also think about what kind of skills the company may be valuing if they choose to test engineers like that.

Lastly the aforementioned FizzBuzz is a well known challenge and well suited to demonstrate what I mean by “taking it seriously” as well as showing how complex a “toy” problem can get. So, I wrote an entire blog post about it and its different evolutionary stages. If you want to dive more into coding challenges, that’s a good next spot to check out.

Pull Request Review

It feels like in recent years “pull request reviews” have become more common as a form of challenge. The premise is simple: You are to review a pull request. Sometimes it’s adding a feature, sometimes it’s building out an entire new application. However, the pull request will always be intentionally bad, so that you have something to fix.

What I like about this kind of challenge is that it’s less likely to go vastly over time while also checking communication skills. So, what should you look out for in particular here:

• Again, pretend it’s real. Pretend you’re reviewing a real pull request from a real human being. Be kind, be helpful. One of the easiest ways to fail these is by being an ass.
• Proper Pull Request Reviews are a topic of their own (see for instance this post by Chelsea Troy) but in short things that can help:
  • Also praise good code, don’t focus on just the negatives
  • Ask questions if you are not sure why something is the way it is
  • Provide suggestions on how to change things, if you recommend to use a particular method best provide a link to its documentation
  • Make sure to mention why you think something needs changing; “this is bad” comments help no one
  • Summarize your main points in a final summarizing comment, perhaps offering to also pair on it
  • Check if the PR actually solves everything that is mentioned in the issue it is trying to solve
  • Check for readability
  • Make sure everything is appropriately tested
• Be very diligent, many of these challenges also sneak in some form of insecure code the kind of which you hopefully don’t see too often. Don’t overlook something because “they probably know what they’re doing” – it’s a challenge, they likely don’t.
• See if tests & linters pass, if there is no CI try to run it yourself. It’s generally best to check out the code yourself to be able to play with it anyhow.

Architecture/Design Challenge

Excuse the hand writing. Some actual notes from an Architecture interview I did.

This is a type of challenge you typically only face at the level of Senior or above, sometimes it’s also called a “Design interview”. Essentially you’ll be given a scenario for an application and asked to design an application that solves this scenario. Sometimes the scope of this is choosing the entire tech stack and general approach, sometimes the focus is solely on the database design – although the latter will come up in both cases. You will not implement it in code, but you will talk through it and probably draw some diagrams.

• Ask about the requirements for the application, chances are that there are things that aren’t completely spelled out but could have an impact. At the very least, you can make sure to arrive at a common domain terminology. Some questions that might make sense to ask for a web application:
  • Who uses the application? What for?
  • Will there only be a browser client for this or do we have other possible clients as well?
  • What kind of traffic can we expect? Will it be spiky?
  • What is the expected response/processing time?
  • How much data will we need to store approximately?
  • Are all users of the system the same or do we have different roles?
  • What’s most important to the system: Should it always be correct, always be fast or always be available?
  • … and of course many more, system design is a WIDE topic …
• Especially here: make the options you’re weighing known. This interview is all about decisions you make and tradeoffs you consider. Whenever you bring something up, an interesting discussion with the interviewers might ensue. I once deliberated whether we could use Sidekiq in a scenario where we absolutely can’t lose jobs, as I was aware of a related problem in the base version of Sidekiq. This open deliberation seemingly impressed my interviewers, had I kept it to myself they would have never known.
• Be visual, draw diagrams of the application, its major components and its environment as well as the database design. All of that is the basis for the discussion and can help you spot inconsistencies. At best the interviewers provide you with a diagramming tools/whiteboard, but even if they don’t a piece of paper and a pen work just as well. The last time I did this I noticed that I had a dangling 1-to-1 that was related to only one table and basically only featured one  meaningful column. While it seemed to make sense, I discussed the issue with the interviewers and we decided to “inline” that table again.
• Take your time to review your own design and discuss it, that way you can bring more options to the table and fix it up – all that before the interviewers get to ask their first question.
• Deliberate the pros and cons of your choices and make sure they fit the scenario. You may love microservices, but if you’re designing a system for a small 3 person business that is used a hundred times a day for the foreseeable future it’s probably not the best decision.
• Be upfront that you might not know something as well. For instance, you might figure out that for what you’re going to build some form of message queues may be a good fit, but you haven’t worked with them a lot. This tip may be controversial, however pretending to know something that you don’t is one of the easiest ways to fail interviews. If the interviewers are good and aware you’re not as familiar with the technology, they might proactively help you out or appreciate the thought but encourage you to go with a technology you’re more familiar with.

People Manager Challenge

Many companies will have specialized people manager challenges for Team Leads/Engineering Managers and up. These can come in many different forms, most of them will put you in some sort of contrived scenario with a problem and then ask you how you would go about solving that problem. More often than not, the scenario will include some form of conflict involving your reports. The form that these take varies wildly:

• You might get a conflict scenario and simply be asked what you think is happening and how you’d address it.
• You may get posts on an internal “help” forum and be asked to answer them.
• You may also be given a scenario of a team that is underperforming and be asked to help them as their new manager.

This challenge type is very different from the others and arguably more complex: You’re dealing with humans and organizational structures here. And worst of all, they are not real and context is only established via a 1-2 page briefing. There is no code you can look at and fiddle with. As a result of this, be extremely careful how you approach and answer these. You simply can not know many things for certain, make it clear that what you are noting are deliberations and ideas. Still, look at all the people in the scenario and try to figure out what is happening. What misunderstandings could there be? Are there biases at play? How can you figure it out? The solution almost always includes talking to all involved participants to get their sides of the story.

As in real life, the scenario as described is subjective. Don’t take all information and statements contained in the task description as the absolute truth. For instance, a team may be described as “underperforming” – it would be important to establish how that was determined and what it means. Maybe the team is working on a major project people are unaware of. Maybe they’re the ones actually keeping the money making legacy application alive and are hence not contributing as much to the new shiny thing (™).

In whatever way you discuss the challenge – be it talking to interviewers about the task or notes you hand in to them – make sure that your thoughts are easy to follow. Be deliberate to distinguish your levels of certainty about different aspects. Make sure you don’t just write down “Talk to Sara” but why you want to talk to her, what piece of the puzzle you want to understand there.

Closing up

And that’s another whopper about interviewing in the books. It’s a complex topic and I truly wish to expand even more on some aspects – but I won’t do it right now so that it stays half-way readable and my time invested stays… not too outrageous.

Try to show your best self, take the tasks seriously and treat them as if they were real as much as possible. Make people aware of the tradeoffs you’re deliberating and why you’re taking certain decisions. It’s not just about solving the task, but about how you solve it – and for the interviewers to understand that you have got to make it obvious to them. Don’t be afraid to discuss the challenge itself with them.

Remember as always, interviewing is not a perfect science. You can fail these challenges for all kinds of reasons – and quite some of them have nothing to do with your ability to do the actual job. If you know you struggle with “Live” challenges, try to get some practice in. Be it mock interviews with friends or applying at another company that isn’t as important to you first.

You got this!

Interviewing Tips: Before You Apply, CV, Cover Letter & Screening Interview

Applying at and interviewing for a company is potentially one of the most valuable skills one can have – it’s not important for the job, but it’s important for you to get the job. It’s often a bit of a mystery how it all works while many pitfalls await you around the corner – but it doesn’t have to be that way! It’s not always easy to figure out what to do and I’ve even seen the most senior people make basic, but huge, mistakes. Let’s remedy that!

Over my career I’ve done a lot of interviewing: working at a startup, I owned the entire process from application screening to hiring decision. At Remote I did way more than 100 interviews from Junior all the way up to Staff Developers and Engineering Managers. For this article, I called in the help of my friend Pedro Homero, an experienced recruiter, to add his knowledge to this article as well – and add he did! My friend Eleni Lixourioti also gave it another read to make sure things are in shape. Thank you both! 💚

The post will be focused on engineering positions, but this first part is general enough that most of it should apply to all positions. This first part? Yes, there will be follow up parts about coding challenges and technical interviews.

Allegedly this post should have been split up as it is gargantuan in size, but as all of these parts flow into each other and require the same mindset it seemed too difficult to do so… and so I decided to stick with it as is. Take a break in between if you feel like it 🍵

This part of a blog post series I’m writing covering:

• CV, cover letter & screening interview ←you are here
• Technical challenges – Coding & More (Bonus: Reexamining FizzBuzz Step by Step – and allowing for more varied rules)
• Interviews

Mindset

Before we get to the actual tips and guidelines, the most important thing to understand when you’re preparing your resume and cover letter is this: What helps them make a hiring decision about me? How can I present myself in the best light? Why should they choose me?

Especially at big companies it’s not uncommon for people to have to comb through hundreds of applications. Sometimes the people doing the pre-screening have little subject matter knowledge. They’re often stressed and have more work ahead of them. Make it easy for them to understand how you can contribute to the company.

It’s also important to understand that interviewing is not a perfect science: mistakes are made constantly. How to design a good interview process asks for its own blog post. But it’s important to remember two things:

1. You can get rejected from a position although you did everything right and would be a good fit. Mistakes happen or someone else was also a great fit and was chosen.
2. It’s easy to look at some of the tips further down and say “It should not be like that, the process is broken!” and you may be right, but it’s still what we have to deal with. We have to do the best we can with an imperfect world.

Before you apply: Get to know the company

I’m an avid believer in quality over quantity for applications. Take some time to get to know the company and the position you’re applying for. It will pay off during the process. You might even end up not wanting to work at the company at all any more – in which case you save yourself the time of the entire process!

Here’s some things you should do before you apply:

• Read the job posting carefully, take note of the requirements (remember you don’t have to fulfill all of them) and think about which ones you fit well or exceed. Take note of what seems most important to them. For instance, they may be looking for engineers who have experience working in Finance or with big monoliths.
• Check out the company:
  • What is their business model? How does it work and how do they make money? You should be able to do a very basic explanation of their business model before your first interview as that will give you extra points in the interviewers mind.
  • Do they have a public handbook or company information? Check out things such as their company values, work culture and others.
  • Check out employee ratings (such as glassdoor). There will always be disgruntled employees, but a lot of negative ratings all at once speak for something negative going down. Also, if there’s a lot of them concentrated in the last couple of months, something big and bad – like a layoff – is likely to have happened. Check Layoffs.fyi to see if the company is listed there.
  • Search for news about the company, you never know what you might find
  • Look for a company blog. Any recent interesting articles? Do they have an engineering blog? What do they write about?

This may seem like overkill to you, but these are quick checks that shouldn’t take you more than about an hour. Why should you do them?

On the positive side, I’ve left a positive impression with hiring managers more than once due to my knowledge. Recently, I said no to a recruitment message of a startup based on the described culture and they were impressed with how well I read it, but also let me know that the information was outdated and we might fit after all.

No matter what you think of company values – a lot of companies use them throughout the entire hiring process to see if a person fits well within the company. Being aware of the values helps you to make sure you highlight related qualities in your application and during interviews. “Which company value speaks most to you?” is also a relatively common interview question.

When you show that you’ve taken the time to check the company and get to know what their values are, you’re not only showing your interest but you’re also able to speak the same “language”. Doing that it’s much more likely that you’ll be deemed a “cultural fit” (while I’d much rather talk about “cultural add”, but that’s a different topic). 

I can’t stress this enough, I recently talked to an engineer more senior than me and they failed an interview because they didn’t go through this basic preparation, being left humbled by the experience. Think about it, if you had 2 candidates: one with no idea about your company and the other one knowledgeable and seemingly excited about working there – who would have higher chances of getting hired?

Surely the news section is an exaggeration though, right? I mean… maybe. However, I once ended up freelancing, via an agency, for a company with an open court case pertaining to crimes against humanity. I was horrified and got out of the contract as fast as I could and I wish not to repeat that experience.

Bonus Tip: Don’t apply at your “top company” first, unless you are really comfortable interviewing. A lot of people have some form of nervousness and “rust” around interviews. Apply to a less important, but still interesting, company first to shake off some rust, make some mistakes and then do it all better when you interview at your preferred company.

CV / Resume

Alright, you now know the company and what they do. It’s time to prepare your CV! Again, think about what’s most interesting to them. Keep in mind that sometimes, sadly, interviewers stumble into an interview without having read the CV beforehand. Make it easy for them to see what’s most relevant. My CV is by no means perfect but you can check it out here for some inspiration.

I’ll break down some tips and guidelines in the following sections.

General

Let’s kick it off with some general tips and guidelines regarding writing a CV:

• The language of the CV should usually be English, unless the job posting is in another language.
• Speaking about language, as a general guideline use past tense for past jobs and the  present tense for current jobs or in general current things (you are still a speaker at conferences, for instance).
• Make sure your CV length isn’t too long, I’ve seen 13 page CVs that had attached their entire university courses and grades. One to two pages is a good guideline unless you’re either very experienced or do a lot of relevant side activities. For comparison, I’ve now cracked 2 pages for the first time.
• Be mindful to adjust the level of detail as you maintain your CV over time, your job from 10 years ago probably isn’t interesting enough to take up half a page. Personally, I’ve been working for 9 years – I’ve removed a lot of detail from earlier positions and reduced my education section down to the bare minimum (degree, grade,  university, specialization) – it’s simply not super relevant any more.
• Sticking out with a more fancy design can help your chances, as long as it doesn’t impede readability. Don’t do a black background with red headlines – it’s terrible to read. Readability and ease of scanning comes first. Again, CVs should be judged purely on content but we’re all human and a special design can help you be remembered, show dedication or to make the cut at all. My CV doesn’t look too special: it has a clear division of sections to ensure readability, and it uses my favorite green as a highlight color.
• Give the file a meaningful name that isn’t just cv, people may be reviewing and looking through 100s of these, so something like firstname_lastname_cv.pdf is advisable.
• Unless specified otherwise in the job posting, submit your CV as a PDF. And I mean a “real” PDF here with searchable text, not a PDF that’s just a big image (I’ve gotten these…).
• You can use links both on the web and in PDFs, make use of them! Link to the company website of companies, to your open source projects etc. Make sure the links work though.
• With all those tips etc. it’s also important to remember that this is your application and your CV! You don’t need to follow all the tips here, be sure to speak in your own voice. I try to put the tips here into context, so you know why they may be a good idea. While many people I talk to could benefit from being a bit prouder of their achievements, also remember to not overdo it and to also be humble. Nobody wants to work with someone who doesn’t acknowledge the contributions of others.

Contact & Introduction

First comes basic information such as your name and email, link to social profiles you want them to see such as github. Many CVs these days feature an introductory text highlighting your core competencies. This can often be a good choice, as it gives you a short form to highlight your most crucial and relevant skills. Put keywords in bold, so as to make those 20 seconds the recruiter uses to skim your CV more valuable. Here’s a simple example:

“I’m a senior backend engineer with a little over 5 years of experience. My main stack is Elixir, Ruby and NodeJS. I’ve worked both for big corporations and fast startups and I’m keen on helping develop interesting products with well-documented, clean and performant code.“

Here are some things that I’ve seen featured on CVs that usually don’t need to be on a CV, although cultural context may apply:

• Usually you don’t use a photo on CVs any more
• Age
• Full Address
• Marital status
• Gender

If anything, they aren’t providing much value (other than inviting biases) and are saving you some space, when you leave them out.

Experiences

This is the core of your CV – your work experiences and other most relevant experiences. You should generally feature them in reverse chronological order – so, most recent experiences first. This is because your most recent experiences are most likely to be the best indicator of what you can do in a work context. Similarly, usually more recent positions deserve more detail/space than older less relevant experiences.

• Work experiences are of course most relevant and should hence come first. If you contribute to Open Source or speak at conferences you can also mention this later in a separate section. Education usually comes last, unless you are fresh out of university, of course.
• For each position/entry make sure to list the following:
  • Position title
  • Company name
  • Start date/end date (month/year is enough)
  • An overall summary of what you did there
  • Preferably, mention the major technologies you worked with there
  • I like to start with a small summary of my role in the job, and then have bullet points for some highlights of major contributions you made at the company
• If a title doesn’t really reflect what you did at a company, highlight the actual work in the summary as best as you can and maybe also leave a note in the title itself. This is a painful experience I had where in an initial interview it was questioned whether I had the experience to manage ~7 people while I had managed 15 people before. Turns out my job title was “Tech Lead” which many people don’t associate with management.
• Embellishing your contributions is (sadly) a common practice, I won’t advocate for it and I know why it happens but make sure to keep it in check. If you say “Setup a deployment process from zero” I should better not find out that you were just the person clicking the “deploy” button every now and then.
• Last but not least, you should be able to talk about every experience on your CV for a couple of minutes. I’ve experienced way too many interviews where when asked about a highlight on their CV people could not tell me anything about it. Take those points out, everything on your CV is fair game to ask about.

To have a skills section or not

A big question is usually whether to include a “skills” section or not. I recommend it, due to these reasons:

• Yes people can see your skills by carefully reading your previous positions, but having the overview makes it easier for the recruiter to check the mental mark of “knows elixir”.
• Some companies employ automated systems to sort through CVs, having the skills spelled out there helps you pass these filters.
• Again, remember whoever reviews these is often not a subject matter expert – you might know that LISP is a functional programming language but they might not. So having basic skills written out like “Functional Programming (LISP, Elixir)” or “Version Control (git)” can be helpful.
• If you do create a skills section, either avoid rating your skills x/10 or be careful with the grades you give yourself. I don’t care who you are, but the chances of you knowing any technology 10/10 are very slim unless you invented it, and even then I’m skeptical.

Adjusting your CV per application

One of the best tips I’ve ever read about CVs is to adjust your CV based on the company you are applying for. First this may sound nuts, but it can make a lot of sense. This is where your prep work about the position and the company comes into play:

• If you worked as both a manager and an “individual contributor” extend and shrink relevant parts depending on what position you apply for. If you do this a lot, it’s advisable to create and maintain 2 “base” versions of your CV – one for management positions, one for IC positions.
• Does the job posting mention a minimum of years of experience with a specific technology? Make sure that this is easily verifiable from your CV.
• Does the company look for someone with some specific skills or experiences? Expand details about that in your CV and maybe cut less relevant details elsewhere. Here are some examples:
  • They’re looking for someone with experience around Finance, make sure to highlight that in every position you worked in that domain, and put keywords in bold
  • I’ve been seeing more companies working on workflow automation, and I actually wrote my Bachelor’s Thesis about this – normally I don’t feature this on my CV any more but for one of these companies I’d put it back on.
• An absolute pro tip from Pedro is to have a template that you can easily tweak and where you have black as the color of your text and another color for details, visual elements, maybe name of position or name of company. Now go to the website of the company that you’re applying to, check out what their main color is and use that one for this version of your CV. Some recruiters and other interviewers will notice it and appreciate the touch. 

How do you do this? Well, just make a copy and adjust it! Keep both versions in separate folders so that you can still easily keep the canonical naming (first_last_cv.pdf). Be sure to keep every version of  a CV you sent around, so that if you get to the interview stage you know what version of your CV they have.

Personally, my CV is generated by a static site page generator and so is stored in git so I can easily create a branch for adjusted versions. I can also easily create 2 different base versions of the CV as all the information is stored in JSON, so I can easily feed 2 different sets of data into the same base CV.

Cover letter

Should you write a cover letter? Yes! I know many see it as an unwelcome chore, but I see it as an opportunity for you to show why you want to work for a company and how you can contribute. And it shouldn’t be a standard cover letter you send to everyone, but one adjusted to the position you’re applying for.

Yes, depending on the company only the recruiter might read your cover letter (if that) but it can also be more: this is somewhat of a me thing, but I’ve read every cover letter of every person I interviewed – ever. It gives you the chance to set up a conversation you want to have, and I wish more people would do it like this. Especially if you’re a career switcher this is your place to highlight what else you can bring to the table. If you don’t fulfill the minimum requirements exactly but have other relevant experience, you can highlight that here. For instance, maybe you haven’t worked with Elixir yet but if you have 6+ years of experience in Erlang then that’s worthwhile highlighting.

Not convinced? Ok then, I’ve worked at multiple companies where the lack of a cover letter or a very lackluster cover letter resulted in automatic rejections. Do I have your attention now?
Again, you can say that’s not fair but the reality is many companies are overwhelmed with applications – seeing if you’re interested enough in the job to write a basic specific cover letter can be an effective filtering mechanism.

Also, if a cover letter is marked as mandatory and you just upload your CV another time or put in two sentences and call it a day, think about how that reflects on you in the eyes of the company hiring. They don’t know you and one of the first things you show them is that you’re unwilling to comply with some basic requirements – what may that say about your attitude when you work there? Yes, it may be completely different but you have to understand that at this point companies don’t have much more to go on – try seeing the process through their eyes.

So, how do you write a cover letter then? To me, it has mostly these parts:

• Introduction/how did you find the job
• Why you want to work at the company, use your research on them and maybe also company values
• Highlight, again from your research, how you might contribute to the company
• Say thanks and that you’re looking forward to hearing from them

As an example, when applying to Remote, I highlighted how I liked the business model, as I frequently had problems getting remote jobs while working from Germany. I believe I also highlighted my desire to work with Elixir full time and that I liked the company value of “kindness”.
I then proceeded to highlight the experience I had gathered working remotely, my Elixir open source projects, talks and community involvement dating back to 2015 (as technically, I did not fulfill the 2 years of working experience with Elixir minimum requirement) along with my public profile and experience interviewing (as I figured the company wanted to grow).

The result of that? The next morning I got an invite for an interview later that same week. I’m not saying it was “just” my cover letter, but I’m certain it played a role.
(Note from Pedro: I read Tobi’s cover letter and was immediately impressed!)

The Screening interview

Usually your first interview is a screening interview without technical questions with a non technical person. The preparation for this interview is basically what is mentioned in “Before you apply” above: Be sure you know what the company does and what the position is. As long as you’re nice, engaged and your language skills are passable you should usually pass this interview. It’s more checking for red flags and some basic parameters.

That said, interview processes are different everywhere and especially at smaller companies it can happen that you’ll discuss some more in depth topics such as collaboration or even technical details in the screening call. When I was doing screening interviews, I often asked some technical questions to get a first feel for the technical expertise of the candidate. 

Back to the “common” screening interviews, the basics they usually check are:

• Salary expectation
• Possible start date
• Work eligibility
• Are you in a big hurry (due to other interview processes?)

The salary question is of course a note-worthy one. I usually try to reverse the question and ask them what their salary range is for the position, as I’d hope that every company has these by now, although they might not share them. If that does not work, remember that the real salary negotiation comes later (and is its whole separate topic). Don’t say something completely outlandish (at best do some research before) and give a realistic number of what you’d like to make. Also beware of the “What did you make at your last role?”-question. You do not need to answer this question, and more importantly, you also don’t need to tell the truth. The question is used to anchor your salary close to what you made before, reducing the space for negotiation and movement.
In general, the salary question is often asked here to make sure that both sides don’t invest an undue amount of time in an interviewing process that can never work out as you’re looking for way more money than they’re willing to offer. Be ready to either give a value that is high in your range and say “but I’m flexible on this topic” or give a range “from X to Y”.

Other common questions you can expect here are:

• “Why do you want to work here?”
• “Have you checked our company values, what do you think of them?”
• “Why do you want to leave your current job?”
• “Have you got any experience with $thing-they-do?” (For instance remote work, or micro-services)
• “How did you find this job posting?”
• “What would make you decide not to take this job?”
• “Tell us about yourself”

That last one, “tell us about yourself”, appears in many different variations throughout various interviewing stages. The real question is “please give us a one or two minute elevator pitch on why we should hire you”. Come with this pitch already prepared, at least the main ideas. You can take these from your cover letter, where you should go through a similar exercise. The interviewer wants to know what you could bring to the company, how well you would fit in with the team and ultimately be excited about the prospect of you joining. Hiring managers are humans, after all, and a recruiter that is excited with your application and your interview will positively affect the hiring manager and the rest of the interviewers. Highlight what you know, how well you would fit the team and that you’re a person that is easy to get along with. At the same time, also remember to be genuine.

A good recruiter will also have time for your questions at the end of the interview, if not before. Be ready to ask a couple of interesting questions that show that you’ve done your homework about the company and are interested in joining. Questions are often more important than the answers, as they reveal more about what you, as the candidate, are interested in. I often ask about topics pertaining to collaboration, the tech stack and aspects of the business model I don’t understand yet. Don’t ask questions just for the sake of it, but ask about what would really interest you about a potential future employer.
End with a question like “I see on the job description that the next step is a test/an interview with X/other. Assuming you think I should move forward, when will I know if it’s going to happen?”. A great recruiter will tell you right away if you’re moving forward or not and will give you instructions (either on the call or with an email a few minutes after it).

It’s common advice to send a message thanking the interviewer after every interview. Personally, I don’t do this unless I have a question I want to ask or something to clarify/highlight. However, it’s still good advice, that Pedro also added in, so here it goes:
After the recruiter interview, send the recruiter an email thanking them for their time (“this candidate is a nice person”), highlight something they said that was important to you (“this candidate paid attention to what I said”) and show yourself ready for the next steps (“this candidate is serious about this recruitment process”). Rinse and repeat after each of the next interviews, unless you don’t have access to their email addresses. 

Going forward

This is the first part of what will likely be a 3-part blog post series, and all together a small eBook I wager 😂 Thanks again to my diligent reviewers Pedro & Eleni for helping round it out and fix some of my horrible comma skills. 💚

The other 2 parts I have in mind right now are about coding challenges and technical interviews. I might end up merging the 2 but seeing how much I’ve written about what I consider to be a lot more simple I think splitting them up will be just fine.

Remember, interviewing isn’t perfect and especially at the early stage you may get rejected for all kinds of reasons not even related to your own application – they might already have a candidate in the final stages whom they really like and close down the position. Keep going, you got this!

2n edition of HU course – with blog and material

Hi everyone,

today was a great day! Today was the first day of the second edition of the course about the basics of web development I’m teaching at Humboldt University Berlin. I had a great deal of fun and am already looking forward to next week.

Anyhow, the course now has its own blog where I share presentations, homework etc. The course is held in German only, so the material is only German as well. The course is aimed at total beginners (e.g. minimum requirement: “You should know how to use a computer.”).  When looking through the material please keep in mind that it is not made for self-study – it is made to be presented. Also it is for real beginners and therefore sometimes makes abstractions/simplifications for the sake of productivity.

So without further ado, enjoy the blog: webanwendungsentwicklung.wordpress.com

Cheers,

Tobi

Web Application introduction Slides from Rails Girls Berlin May 2013

Hi everyone,

It’s the well known web application introduction, this time without the Ruby introduction as the Ruby Monsters already did this! This time it also has a Bentobox exercise, so enjoy!

• PDF download
• Speakerdeck
• Slideshare

Hope you enjoy the rest of the workshop and that the slides help you with your learning 🙂

Oh, and a link to the cheat sheet which I mentioned.

Cheers,

Tobi

A Rails Beginner Cheat Sheet

Hi everyone,

during the last week I spent a large amount of time creating a Cheat Sheet for Rails beginners! So, here it is: http://pragtob.github.io/rails-beginner-cheatsheet/

I originally started creating this cheat sheet for my awesome Rails Girls Berlin project group. But I figured and hoped that a lot more people would be interested in this 🙂

So far this cheat sheet covers the following aspects:

• Command line basics
• Ruby basics including (Numbers, Strings, Arrays, Hashes)
• Rails basics including a description of the folders and commonly used commands (like starting the server)
• Tips about using an editor
• Information about where to get help

So also feel free to check out the repository and especially the open issues – I would love feedback on many of them! And contributions are also very welcome!

Cheers, hope it helps you + keep on learning,

Tobi

Shoes Lightning Talk

So I just gave a lightning talk about shoes. Here are the slides for talk, it was (mostly) a stripped down version of an introduction talk to shoes, which I gave ate Ruby User Group Berlin.

So here are the slides:

• PDF
• speakerdeck
• slideshare

Cheers and thanks for wrov_love.rb – it was a cool conference!

Tobi

Slides from the Febuary 2013 Rails Girls Berlin workshop

Hi there,

So here are the slides from my talks from the Rails Girls Berlin workshop on Saturday, in their chronological order:

Introduction to web applications (the one with the map)

• PDF download
• speakerdeck
• slideshare

I love programming

• PDF download
• speakerdeck
• slideshare

The slides are Creative Commons Attribution license – so feel free to share and modify them but say where you got them from 😉

And as a little bonus I was allowed to post the beautiful Rails Model View Controller comic drawn by Anja of our Ruby Monsters project group – the comic is Crative Commons as well if I understood her right!

Cheers,

(green) Tobi

Resources page online

Hey folks,

just a quick post: I just created a page containing many of the resources I stumbled upon while learning about programming, software engineering, web development, that I found extremely useful. Most of them are free so go and check the resources section out!
This list is also a good indicator of what I might write reviews about in the future.

I hereby want to thank each and every author of the referenced material for their contributions. This is my way of saying thank you, I hope that through my blog some more people find those great resources. I also hope that I can help all the people who are looking for resources in order to learn about Ruby, Rails, web development or any other stuff.

Also if you feel like there are any good resources in the form of guides or tutorials missing please let me know (via comments or ways described in the About section) . I would enjoy this and feel free to share this if you think someone might have use for it.

So once again: Go and check out the Resources section (or simply click on the link on the top right!).

I hope that this may be of use to you.

Tobi