A few tips for the aspiring Test Automation Engineer

So it appears I am about to hit the “10 years in the biz” milestone in my Automation Engineer/Software Developer in Test/Automation Developer (select whatever applies) career. This, I feel, qualifies me to share a few, numbered, BuzzFeed style tips on how to score a job in the field.

First, some words on who I am.

My name is Pavel and for the last 15 years I’ve been getting paid for ensuring software/hardware works properly. I did some hardware (High Voltage control systems) testing but mostly I did software testing, because frankly, I didn’t really enjoy the possible zap by a 3 phase (400V) voltage part of it. So I did some mobile, starting with Samsung’s pre Android handsets and all the way to modern iOS and Android with some Blackberry and Symbian sprinkled in for bad measure. I did some SaaS frontend testing and finally and most recently I did some cloud backend (Kubernetes/OpenShift) testing. Some may call me a Full Stack tester and I promise never not respond to those people.

During the last decade I successfully transitioned into Automated testing roles from the humble Manual beginnings. I was able to do so by being a natural autodidact and utilizing personal connections. Being extremely stubborn and motivated helped a bit as well. I attempted dozens of interviews for Automated testing jobs for many many months until I landed on one unlucky manager that actually gave me a chance. Unlucky because it was an utter failure and I left a few months later. I then tried again and again and eventually it paid off and I scored another job where I actually, somewhat, succeeded and got my feet in the industry.

In the last 3 years I also scouted and interviewed hundreds of candidates so I learned a whole lot about the process and what works and what doesn’t in the process.

But enough about me, let’s talk about how you pass those Test Automation interviews.

We will start with your CV, obviously.

These are some points that I still see people fail at:

• Don’t lie.
• DON’T HAVE SPELING MISTAKES. This one is easy. Turn on the autocorrect. This is 2021, we have the technology. If I see spelling mistakes, I will almost always ignore the candidate. If you are not disciplined to prepare a 2 pager for your future career, you are not disciplined to push good code to the Master branch. Simple as that.
• Don’t write too much. 2 pages are more than enough. I, personally, don’t really care what grade you passed your High School maths. I want to know what you’ve done and what you can do for me and for my organisation. There are some mandatory fields that the HR folks want to see (Your School/Uni/College and the name of your Major/Degree) but leave the trivia for later.
• Looking for your first job and having only a degree/diploma/online course certification to show for? This won’t be easy, but you can improve your chances by sharing projects you’ve worked on. If it’s a school project, share it on GitHub. If it’s your small little personal project, yes, please share it on GitHub. If you contributed code to some Open Source project, share the link in the CV. If you are still not convinced you need some code chunks online, do continue to read as I will return this important subject at the end of this list.
• Don’t mention every technology stack you saw a video about on YouTube. Mention only the stuff you actually worked with. These things are easy to fail on in the actual interviews so please leave as little landmines as possible. Also for the love of god, HTML/XML/JSON etc are not programming languages.
• Listing all the languages/operating systems you’ve worked with is nice and cool but I’d rather read what you actually did in your last positions. More precisely, what did you improve and how did you do it. For example:

Drastically reduced time to market of <> Mobile Applications by developing testing solutions. From 3+ days per cycle before the solution to less than a day after.

• State clearly your title/position in previous companies and try to be as accurate as possible about it.
• Links, links, links. Your email and LinkedIn obviously should be there but if you have a GitHub repository and a blog please add them as well. Have a high ranked Stack Overflow question/answer? Get that bad boy in! I know a dude who actually lists his tenure as a moderator in a well known online technology forum. That’s relevant for sure and implies a strong passion for technology.
• Get your CV peer reviewed. Find a friend in the field and show them the CV, ask what can be done better. Can’t find a friend? Ask on Reddit/Twitter/Facebook. Try to improve in any way possible. Hell, ask me, I can find a few minutes to help out as well.
• I don’t care if you have an ISTQB certificate. I don’t know any serious managers that care about it either.
• Same for Agile/Kanban/Scrum etc.. certificates. You are being interviewed for a Test Automation position, not for a Project Manager one. I care for these less than I care what you ate this morning.

Let’s talk about a few additional tips to improve your chances and to improve your career in general. I’m talking about your online presence. This one is hard to define or to maintain properly without abusing it, but here are a few things you can probably do:

• Have a good clean LinkedIn page with updated info on yourself. Don’t get addicted though and definitely never ever add the words “Visionary” or “Expert” in your title. This shit won’t fly.
• Have a small and succinct personal page. I am talking about a small landing page with your details and links to social media. Nothing fancy. Like this https://about.me/pavelzagalsky
• Write some blogs here and there. No need in Pulitzer level articles on famine and stuff. Just some words on things you’ve made. These go a long way in work interviews. Writing also really improves the way you think and express your thoughts which is always a good thing to improve on.
• Attend Meetups. Start as a participant and attempt getting your talk in. Sounds terrifying for some but I assure you it’s worth the adrenaline kick.
• It also allows you to add another valuable link to the talk on YouTube to your CV.
• ̶F̶i̶g̶h̶t̶ ̶w̶i̶t̶h̶ ̶p̶e̶o̶p̶l̶e̶ ̶o̶n̶ ̶T̶w̶i̶t̶t̶e̶r̶.̶

So as I promised above, here is why it is so important to have your project online and share it on you CV:

Ask yourself, do you even have the skills that will be worth a shekel for your future employer? Did you attend a course in some college? Finished a degree? Learned stuff online? These are all nice but for me, as an interviewer, the papers don’t mean (almost) squat. When I’m considering you as a candidate, I want to see the experience and what you bring to the table. If you just finished some kind of a degree let me see a project you worked on. Extra points for links to GitHub/GitLab. Extra extra points for a properly documented/tested project. If I see you know your way around Git (something that is actually seldom taught in Universities) you will save me time onboarding. I usually spend about 5 minutes on a resume. If in those five minutes you managed to have caught my eye with some nice, properly done code, your chances improve. But the most points you can get are if your project has already been deployed/published somewhere and have users/customers.

Why is having a project important for the process you ask? Well, I prefer to talk business in the interview, I don’t really care what your average was and how well you did your Algorithms and Data Structure courses. Leave that nonsense to FAANG. I want to understand how your twisted mind works, how you will respond to various challenges, what solution paths you’re choosing when facing the inevitable failure. If I can look at a project you made I can actually, well, ask you about it in the interview.

Having your work online increases your chances immensely. Although you should be aware, it might also fail you completely. How so? Obviously since these projects are mostly personal and non professional they don’t need be ISO certified or whatevs. however, they must have some semblance of professionalism. What do I mean by that? Don’t leave in user names, passwords, production paths and endpoints. Reasonable variables naming, best practices where possible. I will write on this matter at length on a future blogpost.

Another viable option, saved for the masochists among you, will be to try and contribute to Open Source projects. Why masochists? Because it’s extremely hard to contribute and get approved in the bigger Open Source project. You will also need a thick skin and lots of patience. If you come to the interview and show that you actually managed to contribute to some serious Open Source project, you will get a pat on the back and additional brownie points, leading you yet another step on the desired title of being employed.

Good luck!

Pavel