Over the past 7 years I've sat across virtual and physical tables from many software engineers, from bright-eyed juniors to battle-tested veterans with decades of experience under their belts.

I've always viewed interviews as a mutual audition, where companies assess candidates and candidates evaluate teams, cultures and career paths. In this exchange it is important to remember that everyone's time is equally important, and that the process should be as smooth and respectful as possible. For example, I see take-home exercises as neither useful nor fair - candidates have to invest a lot of time in them, and nowadays with the commoditization of LLMs and code generation it's hard to know how much of the code was actually produced by the candidate.

But I'll pause the debate on broken hiring practices. Today, I want to speak directly to you, the job seeker, and suggest how you can increase your chances of securing a technical role. Of course, this assessment is through my own lens and my advice may not help you in any situation, but as usual you should use your best judgement.

Your CV

In most cases, the first contact between you and the company will be through your CV. This is your first opportunity to make a good impression, so make sure it's a good one. Here are some tips:

• Use a clear and concise format - I want to be able to begin to form an image of who you are as a person and a professional, not what your design skills are. Don't reinvent the wheel; there are many tools you can use to build a good CV, for example EnhanCV or Resume.io. Don't spend time coming up with a new format, it's not worth it. Instead, spend that time making sure you don't have typos or grammatical errors.
• Don't spend time detailing your activity at a job you had 5+ years ago unless:
• It's relevant to the job you are applying for - not tech-wise, as 5 years is a long time and probably that tech is outdated already, but more in terms of domain knowledge.
• You've been in the same role for the last 5 years, so you should list your previous role too. instead, you should write a short paragraph about it, and use the space to detail your most recent roles more.
• When describing a previous role, I am interested in what you have done, not what your team has done. Often times candidates state that they have used certain technologies on a project, but in reality they were only involved in a small part of it and have never even touched most of the listed technologies. My rule of thumb is: if your CV states that you have recently done something, you must be able to answer questions about it well. I will never ask you about what you've done 5 years ago, but a 2-3 year time frame is fair game.
• Don't list technologies that you have only heard of, or used by chance some time ago. If you list a technology, be prepared to answer questions about it. Depending on your seniority and my own familiarity with said technologies, I might ask quite deep questions and expect you to be able to answer them.
• Don't be afraid to mention your failures. Did you find that you were not fit for a role and left at the end of your probation period? Great, write that down - it shows that you are self-aware and that you know what you want. If you don't, I will probably ask you about it if we get to the interview stage, and it's better to be honest from the start.
• As a minimum, include links to your:
• LinkedIn profile
• GitHub profile
• Personal website, if you have one

The interview

You've made it through the CV screening and potentially an initial conversation with someone non-technical. Now it's time for the technical interview. Larger companies who see many candidates might have a more standardized process with fixed questions. For smaller companies, I always prefer assessing practical knowledge, problem-solving skills and cultural fit. No, I don't think Leetcode is a good way to assess someone's technical skills, unless I work for a company building very low-level software. Believe me, in 99% of cases you don't need to know how to balance a binary tree to do your day to day job. This is something companies should keep in mind when designing their interview process, but it's a discussion for a different article.

Here's what I try to figure out in the interview:

• Your communication skills: can you explain complex concepts in a simple way? Do you come across clearly and confidently?
• Your problem-solving skills: can you think on your feet? Can you break down a problem into smaller parts and solve it incrementally?
• Your ability to talk about things you've done in the past, as listed in your CV: can you explain the decisions you made, the challenges you faced, and the outcomes of your work? How well do you understand the technologies you've listed? Can you explain them in simple terms?
• Your fluency in writing day-to-day code: can you write clean, readable code? Can you demonstrate that you are actually doing those things day to day? For example, if I interview you for a full-stack role, I expect you as a minimum to be able to write a simple web server endpoint, understand the different HTTP methods and think about data validation. If you struggle with basic syntax or concepts that you are supposed to use every day, I will be concerned.
• Would I want to work with you? This is a very important point. I don't really care how brilliant you are technically if I can tell you are a pain to work with. Software engineering is a team game, and I want to make sure you are a good team player.

What I want to see you do:

• Say I don't know when you don't know something. I can tell when you are trying to improvise an answer and it's a very bad look. Be honest, be humble. You don't need to know everything, and I don't expect you to. Knowing what you don't know is a very important skill.
• Think out loud. I want to understand your thought process, not just the final answer. If you are stuck, tell me what you are thinking, and I might be able to help you. Actually, I want to help you - spending time in awkward silence is not fun for anyone and my goal is not to stress you.
• Ask questions about the tasks I give you. If we go into systems design, don't just make assumptions. Ask me about the requirements, the constraints, the expected load, etc. I want to see that you are thinking about the bigger picture, not just the task at hand.
• Show me that you did your due diligence on the role and the company. If you don't know even the high level details about what we do, it's a bad look. Spend at least 30 minutes reading about us and make some notes. Bonus points if you also know about our competitors and the industry in general.

What I don't want to see you do:

• Ask to use Google or ChatGPT to answer questions. I want to see what you know, not what you can find on the internet. If you don't know something, just say it. If I wanted to hire an LLM I would just buy some OpenAI credits.
• Use Google or ChatGPT as if I couldn't tell. If I get to ask you "hey, are you using ChatGPT now?" you're definitely not getting this job.
• Be rude or dismissive. Sometimes I may ask experienced candidates seemingly simple questions to see how they react to them, or to set the context for a deeper dive into the subject. If you're going to laugh at me or dismiss the question as being "too simple for you", I don't think I could work with you. Any question in the world has deeper layers to it, and I want to see that you are willing to explore them.
• Don't try to avoid answering questions directly because you were caught off guard. This typically happens when your CV oversells your skills, and you are asked about something you should know but you don't. Again, it's best to be honest and say you don't know, or admit that your CV is not accurate in that regard.
• If you apply for a role that asks for a specific language or technology as a core requirement and you haven't used it in a while, either prep before so you restore your muscle memory or be honest about it. Don't pretend you are an expert in something you haven't touched in 5 years, it's not a good look.

Following these tips won't guarantee you a job, but they will definitely increase your chances. Remember that the interview process is a two-way street, and you should also be assessing if the company is a good fit for you. Take it easy, enjoy the process, learn from the experience, and you will eventually find the right role for you. Good luck!