I have been interviewing a lot of candidates for DevOps roles recently. I also interviewed as a candidate for a DevOps role with my upcoming employer. These experiences have taught me many new lessons as well as revived some forgotten ones.
A resume is a very crucial piece of a candidacy. It is the first impression a recruiter, hiring manager, and potential colleague has of you. It is not the only thing a good hiring process will consider but it is of high significance nonetheless. Let's talk about some dos and don'ts of writing a resume.
Keep your resume short and to the point. Hiring teams typically have a lot of resumes to review and don't have time to read through them in depth. Even a two-page resume can be too long, especially if it's chock-full of dense text in small size. Be kind to the hiring team. A shorter resume may also pop among the long, dreary ones.
Your resume should showcase your relevant and recent experience and highlight proficient skills. Remove skills inapplicable to the role's description but be prepared to bring them up in an interview if appropriate. If there are skills the current role would require or greatly benefit from but you are rusty, make that information available.
I have made this mistake all my career and I only really realized it recently. I have not only included rusty skills in my resume but highlighted them as well. When questioned on those skills, I could only recall some foggy details from my time spent on them. As an interviewer, I would love to get a sense of fresh versus rusty skills by just reading the resume so I can tailor my questions accordingly.
Identifying rusty skills gives the hiring team the important information that a candidate has experience with them but that they are not proficient anymore. For most roles it may not matter that you're not proficient anymore; just having that experience can be enough. Of course, some roles may require you to be proficient in those skills so brush up on them to discuss them in an interview.
To drive the point home, highlight your relevant and recent experience and skills. Include any relevant but non-proficient skills as well but make that clear. Keep the spotlight on your strong skills and don't be afraid of listing other relevant skills as long as the difference is clear.
Everyone exaggerates their resumes. It's an almost-expected part of the hiring process and thus hiring teams know to tease out the true details. If you don't exaggerate in the first place, your resume may be shorter but more truthful. If you do exaggerate, prepare well to answer in-depth questions. Don't walk in with only superficial knowledge; good hiring teams can figure out when you're not entirely truthful.
Treat an interview as a conversation. You're there to back up your resume by answering questions to the best of your knowledge. You're also there to add more body to your resume.
Some candidates I've talked to recently have talked in very generic terms. When asked to design a CI/CD pipeline from scratch, they did a reasonable job but did not share stories from their experiences nor did they provide any opinionated responses. For example, folks on both sides of that table know that a version control system is important. Which did you use, what did you like about them, which one would you recommend, what didn't you like about them, and other such questions need to be answered by you without being prompted. Tell the hiring team stories of how you tried a few and decided on one or two. Give opinions on the tech stack for the CI/CD pipeline. This tells the hiring team that you have actually used it even if you're not proficient in it yet. Providing very vague answers and listing a bunch of tools without elaborating on why you'd pick one over another leaves an impression that you only skimmed some intro pages and never used them in real life.
I'll repeat this point: share stories of your experiences. Talk about projects and what role (exactly) did you play in them. Don't be afraid to say that your role was pretty narrow and focused. As an interviewer I care more about your interpersonal and team skills and your honesty and integrity. It could be that the role I'm hiring for would provide you an even better chance of making an impact. You can't make an impact, though, if I don't know how you have handled team work in the past.
Always use specific examples of things you did, what went wrong, how you fixed it, what went well, and any lessons learned that would help you in the future. Unless the hiring team gets to know you as a person it'll be very hard for them to bring you on.
If the interviewers appear bored or distracted it's not a good sign. It may not be because of something you're doing but you need to take charge of the situation if it's drifting away. I like to lighten the mood a little by jolting their attention with some lighthearted comment. Keeping the interviewer engaged is your job and that will give you a greater chance of getting hired.
Ask good questions from first contact. Typically, a recruiter will do a phone screen, then one or two people will do a more detailed and technical phone screen, before they bring you in for a longer and in-person interview. Ask good questions at each stage that are appropriate for that stage.
I like to ask about the hiring process, timelines, and other HR-type things in my first call with a recruiter. In the first technical phone screen I ask for more details about the role, the team, and culture. My goal is to appear eager to join the team but also to be sure that the phone screeners sell me the role and the team. That is, they should convince me to join them as well. If they don't do that, it may mean that the phone screen didn't go well or the team environment is not as inviting as I would want it to be.
During in-person interviews I like to ask each person how their role fits into the big picture, what do they like about the role, what do they think could be improved about the team, and how could my role and my skills make them be more efficient and impactful. Don't be afraid to ask about working remotely, flexible working hours, time off, on-call schedules, commute, parking, meal options, and other such "mundane" things. When you spend one-third of your day for five days a week at a place, you need to be comfortable about the way the team works.
Resumes are not always perfect. They have typos, exaggerations, and sometimes outright lies. Don't make up a final impression of a person based on their resume.
I like to treat interviews as conversations about the candidate's experience and skills. I let them tell stories to give me a better sense of what they have done. Most of my questions are inspired by what they share with me.
I don't like to ask probing technical questions unless I feel like the candidate has exaggerated their qualifications beyond what can reasonably be considered expected. In these cases I can appear to be a very tough, maybe mean, interviewer. I want to hire candidates with honesty and integrity. If they don't appear to have both, I like to know how bad the situation really is.
As a candidate I suck at whiteboard coding challenges. My brain just shuts down in those situations. I was fortunate when this didn't have an adverse affect on my candidacy but that happens far, far less than I would like. For this reason I don't ask candidates to code on a whiteboard. If needed I prefer code challenges at the candidate's own time and pace. Not everyone is great at thinking through a problem and explaining their thoughts in real time. Hiring teams should have more empathy when designing the hiring process.
I once pulled a candidate's old repo on GitHub and asked them to critique and fix their own code based on what they had learned since writing it. My dear friend and coworker chided me on doing this. My intention was to gauge how much the candidate had grown their skills over a period of time and whether they were humble enough to realize that we all write bad code but we improve it as we learn and improve. My intention was not to grill them on bad code. I learned a valuable lesson to do this even more politely and being more transparent about my intentions if in future I decided to repeat this tactic.
It is very hard, if not impossible, to judge another person's qualifications and potential in a short period of time. All we can do as part of a hiring team is get a sense of whether we can work with the candidate and any adverse effects they could have as the team mentors them to the required skill level.
Be prepared to hire a junior candidate and mentor them. When I was a junior engineer I wanted an opportunity with a team that was mature enough to mentor me. I didn't find any such team. I realize that at some organizations there just isn't the money to invest in junior candidates. Others do have the resources and should step up. One of the best managers I worked with was always willing to hire people who wanted to grow and had proven that they grew in previous roles. I learned to be open minded from him.
My biggest regret so far as a hiring team was to not hire a candidate I thought I could mentor into becoming a better tester. Unfortunately, my employer just didn't have the resources for me to do that. I will always keep the option open in case I get another similar chance.
Marketing your organization and your team to the candidate is a very important factor in any hiring process. It gives candidates the confidence to ask good questions and that tells hiring teams even more about the candidate. Candidates are interviewing hiring teams just as the opposite is happening. Make sure to really sell the candidate on picking your team if you think you will want to hire them.
Candidates want to present their best to hiring teams. Hiring teams should treat them as humans throughout the process. All of us have to make the hiring process more about transparent conversations rather than asserting any false balance of power. Candidates and hiring teams should be prepared to walk away from the process at any point and should expect the other party to do the same.
I would like to see more empathy from both sides to make hiring a positive experience for all involved.