TL;DR: not much!

In my short but intense professional career, not only have I been interviewed a few times, but I also had the chance to be part of the hiring process and interview candidates in my last two jobs.

This is a personal overview of what I have experienced on both sides of the table and some advice for both candidates and companies on improving software engineering hiring!

As a candidate

Let’s cut through the chase here, if you are interviewing for a software engineering position, you have the upper hand. It’s a candidate’s market at the moment so always approach your job search with confidence.

Before starting your job hunt, make sure you know exactly what you are looking for in a company. It can be an impactful product, or a supportive team, or some flexibility … or all of the above!

If you have a strong network that you can leverage to find your next job, I’d say you’re already pretty much set for success. If, like me, you have to spend time scrapping job portals and sending resumes and cover letters into the void, here are some tips I have found personally useful.

On maximising your chances to land an on-site interview

The main goal of sending your resume and cover letter to a company is to land an on-site interview for the position you are applying for.

If you’re sending your resume through your network, this is mainly just a formality so you can jump into the next section … else, keep reading!

About job descriptions

Always read job descriptions and requirements with a dose of critical thinking. Not all job descriptions are written equal and don’t spend too much time on those that don’t seem like a good fit to you. Whatever represents a good fit vary from people to people, but for example if the job description lists half a dozen technologies with years of experience required, that is a big red flag for me!

There is no golden rule here, but if you see yourself working at that position at that company for at least the next couple of years, then go and apply (even if you may not tick all the requirements)!

About resumes and cover letters

Note that I said “and” and not “or". That’s because I think it is preponderant to at least write a few paragraph to accompany your resume. It does make a difference!

More than a simple list of previous jobs and education, your resume is a reflection of your professional self! As such, in my opinion, its look is more important than its content. It doesn’t need to be an art masterpiece, but it does need to be spotless.

With regards to cover letters, try to make them as customised as possible. This will force you to look beyond the job description and into the company. A good rule of thumb is that if you can’t be bothered to write a customised cover letter, then it’s fair to say you’re not really interested in the position or the company. The format is quite free (the shorter the better though) as long as you somewhat answer to the question: "why am I the right candidate for this position”.

This is not a blog post on resumes or cover letters, but feel free to reach out if you want some advice on how to build solid ones!

On acing your interviews

After sending a dozen applications, you hear back from a couple of them (that is actually a really good ratio, congrats!).

Each company has its own process, but from what I have seen you will now go through a 3- or 4-step interview process before eventually receiving an offer.

About phone screenings

Typically, in larger companies, you might pass through a quick phone screening with an HR person to assess your fit for the position. It usually consists of a few questions on your past experience and on your resume and, ultimately, about why you want to join the company. They might also ask you about your salary expectations.

If the company is calling you that usually means that they are interested in your profile, so just answer confidently to their questions and be ready to also ask some questions about the hiring process or the company culture.

About on-site technical interviews

The next step is typically a technical interview. It might be on-site or as a homework … or sometimes both (lucky you!).

If you are going over to an on-site technical interview, be ready to answer trivia questions and write code on a white-board. I won’t say here what I think about those practices, but they do still exist and you will probably encounter them one day.

As an aparté, if at any moment you feel like there is no chemistry between you and the company (if you feel uncomfortable for example), it is totally fine to politely say that you don’t think there is a good fit and just walk out of the interview. That’ll save you and the company some valuable time!

What are the main differences between a Generator and a Promise in JavaScript?

So, let’s go back to those computer science trivia questions! I honestly don't enjoy cluttering my brain with useless information, thus I’ve never prepared before a technical interview. If that helps, you can always just search for the typical questions and answers and go over them, but I wouldn’t do anything fancier than that.

The only tip I’d give here is to try to answer every question the best you can, unless you really really have no idea what the question is about. If you are not sure of the answer, say so but try to draw parallels with things you know and express an informed guess.

Try to make this a learning experience, so if your answer is wrong or incomplete, don’t hesitate to ask your interviewer for the correct answer (more often than not they will struggle to answer as well!).

Could you traverse a BST breath-first on the white-board?

Luckily enough for me, I've never been asked that question (so far), and honestly I won’t be capable of doing it at all (despite having a CS education). If I ever am asked that, I would literally walk out of the interview (unless I am interviewing for a position where I’d need to reverse BSTs on a daily basis that is!).

There are countless articles on the internet exposing the reasons why writing code on a white-board (or on a piece of paper) is a terrible proxy to knowing the technical capabilities of a candidate, so I’ll spare you this part. Again, what I’d advise here is to try your best and to vocalise your thought process. And again, if you can’t do the exercise, don’t hesitate to ask your interviewers for the answer (again, more often than not they will struggle to answer as well!).

About technical challenges homework

More often than not, companies have realised that trivia questions and white-boards are a terrible indicator of the technical worth of a candidate, so to assess the candidate’s tech skills they ask for a “small" technical challenge homework that relates to the position they’re applying for.

This will demand quite some of your free time to complete, and is a good proxy to your real motivation to joining a company. Try to make the code as professional and production-ready as possible. Particular points to give attention, besides the completion of the exercise, are test, maintainability and documentation. Make it as easy as possible for the reviewers to understand your solution!

Here is an example of a solution to a technical challenge: https://github.com/AntonioVdlC/pento-time-tracker.

About culture fit interviews

So you’ve made it over to the final rounds of interviews, that’s fantastic!

Usually the final rounds are mostly culture fit interviews, so be ready to talk (yet again) about your resume and about why you want to work for the company. Depending on the size of the company, your interviewer might be the CTO, the VP of Engineering or your future manager.

The only advice I can give here is to always try to have an example in mind to illustrate your points. Also, always remember that this is a two-way street, so as they are interviewing you, you are also interviewing them as well!

If everything goes well, you might get an offer shortly! Else, take this as a learning experience, try to get some feedback on what you could do better next time and keep hustling (take your weekends off though!).

As a company

I have less experience being the interviewer than the interviewee and I have never managed a team, but I still hold a few (probably wrong) opinions on how to hire the best software engineering talents!

On writing an enticing job description

Unless you are a renown company or startup, chances are that you are having a hard time finding software engineers (and your network can only get you so far). Your best bet is usually to post job descriptions all over the place and hope to attract at least a good talent to fill the position.

Just as I advise candidates to write cover letters and perfect their resumes, it is preponderant for a company to spend time crafting an enticing job description. The same way you can see through copy-pasted cover letters, candidates can also see through copy-pasted job descriptions, and if the majority of candidates won’t care, the talents will! It’s a candidate’s market after all!

There are plenty of articles on how to write job descriptions, so I’ll just give a few points of advice:

• Be concise!
• Don’t use terms such as “rock star”, “ninja”, “wizard" or whatever is hype now.
• Don’t write years of experience expected, it’s bogus at best and you might miss some great candidates with huge potential and probably better skills than a “senior” software engineer (whatever that means).
• Make it crystal clear what the company is trying to achieve and why!
• Refrain from using meaningless sentences such as "We are looking for a software engineer to produce and implement functional software solutions.” or "Ultimately, your role will be to build high-quality, innovative and fully performing software that complies with coding standards and technical design.”.
• Don’t list soft-skills as requirements, everyone is “autonomous" and has an “analytical mind with problem-solving aptitude” … besides that doesn’t even make any sense!
• If you can, don’t list tech skills requirements either, just go with a clear list of responsibilities, a good software engineer will be able to pick the right tool for the job and learn it if needed (but do give indications on your tech stack)!
• Try to be as inclusive as possible in your wording, that’s not just good human decency, diversity is also good for business!
• Be concise!
• Also, make sure a technical person reviews the job description … please!

All-in-all, a job description should answer a simple question: what is the company trying to achieve and how can the candidate help and be part of that mission.

As a rule of thumbs, if I don’t see clearly what my impact as a candidate will be in a company (and what that company is trying to achieve) I may just pass my way!

On assessing a candidate’s skill set

Congrats! Your job post has attracted a lot of candidates to fill the vacant software engineering position … now it’s time to assess all the candidates’ skill sets!

About resumes and cover letters

Each recruiter and company have their way to evaluate resumes and cover letters (I’ve heard some would discard randomly half of the applicants because they don’t want “unlucky people”), but here are the points I think are important.

On resumes, beyond the alignment with the requirements (which should be loose) I really put a lot of importance on the consistency. It does not need to be beautiful, but it does need to be organised, consistent and to-the-point.

For cover letters, if there aren’t any it’s usually a bad sign. That probably means the candidate either didn’t bother searching information about the company and thinking how they fit into its mission and vision, or that the candidate isn’t really good at communicating. A good cover letter is one that is concise (around 150-200 words), that gives me a relevant overview of the candidate's strengths and that shows the candidate understood the position they are applying for.

About technical skills

A lot of contradictory pieces have been written about the best ways to evaluate candidate’s technical skills, and (apart from Google maybe) we have very little data to actually support one way or another.

I am strongly against white-boarding (asking a candidate to write code on a white board). It not only is just plain stupid and awkward, but it is a terrible indicator of the candidate’s capacity to excel at their craft. If you want to have a quick overview of the candidate’s technical proficiency, provide them with a computer with Internet access. Don’t focus so much on the correctness or production-readiness of the code in an on-site technical interview, but look for a clear thought process and the way the candidate tackles the problems.

A close cousin to white-boarding is giving a technical challenge to candidates and ask them to complete them at home. If you do that, please don’t enforce a deadline. Keep in mind the candidates are doing that for free on their free time. Also, try to keep the scope as small as possible. In this setup, code correctness is a lot more important, but also keep on an eye on the asides: testability, maintainability and documentation. If the candidate already has a couple of side-projects in production that cover what you are interviewing for, a good alternative could be to ask the candidate if they prefer one of their side-projects to be reviewed instead!

Finally, I strongly believe trivia questions are not only an enormous waste of time (is this a TV show? A quiz?) but also a way for the interviewers or the company to feel superior by knowing useless implementation details that candidates might not know (unless this is a position with a very specific scope that requires high levels of expertise on how compilers work). Nevertheless, a technical discussion is in my opinion the best way to assess a candidate’s technical skill set, and most importantly their soft-skills too!

Most of a software engineer’s job is communication with peers and being able to make good technical decisions more than just writing code! If a candidate has side-projects, ask them about the technical choices and the challenges they faced and how they solved them. Instead of asking a pointless question about the difference between classical and prototypal inheritance, ask them about what they think of the new class syntax in JavaScript. And after they finish giving their opinions, do share yours! The more this looks like a conversation, the more you will learn about each other, which is ultimately the whole point of interviewing in the first place!

About soft-skills and culture fit

According to some studies conducted at Google (these folks do have a lot of data, I hope they never go evil!), the main factors of success for their software engineering hires are all soft-skills! Thus turning back great candidates because they were not able to recite all the HTTP status codes or have never heard of React Fragments is not only ridiculous, but also terrible business!

Soft-skills are a lot harder to assess objectively than technical skills, which explains why most software engineering hiring processes are focused around tech questions and thus are missing the broader picture. The soft-skills you want to look for in a candidate depend vastly on the company’s culture. Hiring mostly based on culture fit can nevertheless create bias and hinder diversity, so just as in technical interviews, it does help to have a list of soft-skills the company is looking for and a clear way of assessing them.

I personally think that the primordial soft-skills a great candidate should demonstrate are good communication skills, eagerness to learn, and ability to identify and explain technical trade-offs.

On rejecting and sending feedback to candidates

This is something most companies fail to do. Ideally you should always send an email to every single person that submits an application, but at the very least, if a candidate has been moved to an on-site or technical interview, please do get back to them!

Even if it’s an automated rejection email with no actionable feedback, please do get back to them! If you can actually give them some actionable feedback, that’d be even better. It is true that sometimes the choice boiled down to company-specific details and there is actually very little a candidate has to change to improve, but you can also highlight what the candidate did right.

Even if, as software engineers, we are in a favourable hiring market, looking for a job is still a soul-wrecking experience, so any bit of humanity can go a long way!

On on-boarding new employees

Another point I want to quickly cover is the on-boarding of new employees, because it’s something that has been butchered in all of the jobs I’ve had so far (except for my first internship, maybe that’s why I have such a high bar for the ulterior ones).

It boggles me a bit that the on-boarding process is often so neglected. The company has already spent countless amounts of resources to hire the right candidate, so why not doing all you can to make sure they have a great start and can get up to speed as fast as possible?

Usually candidates won’t be able to join your company right away (either because they are currently working for another company or because they need a visa), so don’t disappear altogether after they have signed the offer. Keep in contact with them! Organising a public event? Invite them! Just changed of year? Send them an email to wish them a Happy New Year! Changing jobs can be a stressful moment, so try to make the transition as comfortable and human as possible!

Again, I am sure there are plenty of great articles on how to on-board new employees, and it depends a lot on the company and its resources, but I think it is an essential stepping stone on making sure your new employees succeed!