Interview tips (part 2)

 Interview tips to myself (part2)

Please start with interview-tips-part-1 or the prologue piece for the background.

CV Writing

These days you have got literally 20 seconds to grab someone's attention when they see your CV. Recruiters will sometimes have a stack of up to 100 CV's send in for a role, many of them are people who are just desperate for any work even if they do not have the specific skills the job calls for. It's a bit like a Youtube or Facenook/Insta doomscroll, you have to stand out. It feels wrong as an engineer type person to have to put their "branding" hat on, but you are a brand, so think like a brand. Write yourself a tagline right now.

Now this is what has gotten my CV seen by recruiters. I'm going to suggest something I have always done, write 2 CVs. I am interested in embedded and electronics as well as desktop/cloud, so I have 2 CVs. The differences between each CV are not huge, but they are enough to tell a story about my key skills in each. This sometimes removes the need for a covering letter per job application too. But always be prepared to write a covering letter.

Old school works. Today lots of people write a nice list of all of their skills at the top of the CV, that works if all you want to do is play buzzword bingo. A month ago I had someone posing as a recruiter reach out about interest in my CV. Turns out they desperately wanted to get paid to re-write my CV, probably by feeding it into an AI tool for the princely sum of $20. Sure, use some AI to improve your CV, but be sure to start by listing your experience in each tool and environment. The best person to get help with your CV is someone you know who is a hiring manager.

Example:

• 14 years C/C++ experience + 18 years QA experience Python et-al. Mobile and Embedded device test roles as well as Desktop and Cloud.

Then tell the reader a bit about what inspires you. Example:

• I have worked as an SDET in Cambridge for 18 years now, and am a settled UK dual-national. Making over 32 years experience developing software, most of those in mission critical systems. 

Then list all the buzzwords before diving into your job experience in reverse chronological order. Only list years not months. Example:

• Citrix Research: XenDesktop 2010 – 2017
• Contract work testing a windows filesystem device driver. CPPUnit/C++. Soon joined a team created to deploy a turn-key test-automation framework (Continuous Integration). We delivered a turn-key testing environment in a Windows Active-Directory distributed environment.
• Roles
• Support manual and automated testing by developers as well as testers. 
• Using Virtualization to create scalable test environments and sandboxes.
• Projects
• Designing, creating and deploying the testing framework to internal teams worldwide. I worked directly to supporting 3 XenDesktop product releases.
• Skills and Tools
• Jenkins, Teamcity, Powershell.
• Jira defect tracking and Agile process. Perforce and GIT.

Length. If you have 30 years experience your CV will run into about 4 pages or more. Everyone will try to tell you that that is too long, but I'm going to advice against throwing away your biggest asset. Try to compress things, and when you find you cannot, stop and get someone you trust to review and help rewrite.

Be Online

Have a copy of your CV in a cloud drive, so that you can quickly attach it to a job application or an email even if you are out and about with only your phone. It thus goes without saying, make sure your CV is pretty much text only with no fonts or fancy formatting tables unless you use PDFs. Additionally you may want to publish your CV minus the contact details online too. These days text based web space is totally free.

Quality versus Quantity

If you have read this far, you are probably a quality versus quantity person. Some people I know get good results make making up to 5 job applications per day. Quantity works because 50% of the job applications you make, will be down to a lot of luck if you get someone spend more than 1 minute looking at your job application. Often it will be a computer, and you will have only milliseconds.

I am a one application per day, type person, which works against me, but also means I have to make fewer choices. I struggle to prioritize anything at all. After your CV gets noticed you still have to try get as many interviews set up as possible, because once again, luck plays a huge part.

I have walked out of more than one interview thinking that was an unwise or silly thing I said. 

A common mitigation for fairness is that you will have 2 people in the interview room. It's not a bad-cop good cop thing, it's to ensure balanced views on a candidate and removes a bit of bias.

Don't kick yourself if you do screw up, interviewing candidates fairly is very hard and companies do their level best to make things fair these days.

Homework

Due to the flood of CV's most employers that do not use external recruiters will give you some homework to hand in. Unless you are earning less than double the minimum wage, don't bother with those job posts. The field is too wide and you will be judged more on how much time you were able waste polishing the homework to perfection, not on how quickly you can in fact work at all.

But that's not to say preparation is not necessary, I always do 2 kinds of preparation. Background research, and Visualization. 

1. Before and while hitting that apply button I'm doing a google on what the company does, does their mission and industry align with what I want culturally. Things like Environmental and social governance, you don't want to be working at evil-corp 5 years later. Next I start writing a draft covering letter. Not everyone asks for one, but start writing one anyway even if they don't. This is a prelude to "interviewing the interviewer" which I covered in another part. In parallel, I look to see if I know or am in any way connected to anyone who does or has worked there, and ping them of opinions or ask why they left the company. 
2. Once it looks like an interview will be booked, I start to prepare myself mentally. Every single interview will ask you one of a few stumper questions. Be prepared and rehearse answers to questions like:

• Why did you leave company XYZ?
• If you were an animal, which animal would you be and why?
• Describe a conflict situation you were in and how you resolved it.
• Describe a real-world technical challenge, and how you broke it down and solved it.
• (Try to come up with one or two of your own here.)

A Test plan

In my first tester job interview, I got asked to describe how to test a system that modelled traffic on the motorway that encircles London. I have even been asked in the interview to list tests for a digital watch . Once I even got asked how would I test the controller for a sauna. So in a technique called visualization I have taken this a step further. I write a draft test plan.

You get three key things:

1. You have a well structured list of questions about the product and about what the job is before getting into the interview room.
2. You are more prepared and relaxed.
3. You have got homework to show off that shows you really want this job.

I recently learned about Arnold Schwarzenegger and visualisation as a technique to achieve goals. (https://www.linkedin.com/pulse/arnolds-2024-blueprint-arnold-schwarzenegger-hzebc/) I'll summarise for now.

• Arnie wanted to be the best bodybuilder...
• Arnie wanted to be a movie star...
• Arnie wanted to be governor of California.... 

He did all of these things, how? He visualised himself as having achieved each goal, then broke each goal down into tiny little steps. Each day he takes one step.

This technique works well for test engineers. it might be adaptable in it's visualisation form, for other roles though. How I start preparing for interviews nowadays.

1. You want this job badly, the company makes a product you are interested in helping to build. You want the product to be great.
2. Imagine it's your second day on the job and your boring induction paperwork has all been done, what are you going to do next? Probably start learning about and start actually testing the product.
3. Ask google AI (other AI's do exist) to write you a test plan for a "insert product type here". what this does, it get you past the writers block that impacts anyone who has ADHD tendencies. If you don't have ADHD tendencies it's a template for free at any rate.
4. Delete all the irrelevant stuff in the 3 page document the AI generated. If you used a good tool there will be no repetition. Add the actual company name and change the names of some technologies that the AI got a bit wrong. You should now have about 2 pages of a pretty good template with headings that make sense.
5. Mind map the product functionality now, and do a bit of research on what the product does. Adjust the test plan document headings a bit more.
6. The test plan will already list some equipment you will need, amend the list now.
7. Now add test cases. At this point you will hit lots of unknowns or things you are unsure about. List them all and take guesses at what you do not know. Put a question mark next to each one.
8. Add a new heading at the top pf your test plan, title it "Out of scope", and dump all of the things you found out about the product, but are not mentioned in the company job description.
9. Add a new heading at the end or your test plan, title it "Questions". Move all of the test cases that feel like guesswork down into that heading.
10. You should now have a draft test plan, print it out onto a dead tree and review and tidy it a bit.
11. Once again, break things down. Make a "tasks" or todo table of each block of testing first as a manual test, and then as an automated test. Optionally give each a size, do not estimate days, estimate relative sizes. Your days estimates will always be viewed as too optimistic, just don't, trust me.
12. Take these tasks and paste them in and give them a heading like "Resource plan".
13. Review and print the document again and take it with you to the interview. Be sure to highlight the sections where you wrote lots of questions and have knowledge gaps.

Don't tell anyone that you have this document, produce it when they ask you a question that seems relevant. At the end, give the document to the interviewer. Remind them that it's just a draft.

In my recent interview I got given answers to almost every question I had written into the test plan. Either because I asked it, or because the interviewer described the answer as part of their interview anyway. This way nothing is a surprise for you.

References

Have 2 people references ready, you will be asked for them if they want to make an offer, so be prepared. References are almost never used in reality, but do be sure to let the people know that you are using them as references at the time.

Rejection

I struggle to read people, and often leave an interview thinking that it went swimmingly. Then I get the rejection response. Often you will get no detailed feedback at all. It's not your fault.

Had a good chat with an ex Team leader David Doyle. He reminded me about learning to "read the room". Interviewers often have a mental image of the ideal candidate, and they are wanting you to fill that image somehow. They won't tell you how to match that image, but they will have one. You cannot guess what is in that image, and sometimes, you are just unlucky. Mostly learn from each interview and move on.

Best of luck.

Interview tips (part 1)

Interview the Interviewer (part1)

For the prelude to this 3 part post please go back to the prologue .

band practice night

I usually blog about things that I do not want to forget, but since I have to login to Linked-in every day while job-hunting anyway, I have decided to write roughly 1 article per week. I know that I can sustain this, because a few years back I made almost 100 blog posts over 2 years. I later switched to writing game reviews and managed to meet my goal of 1 per fortnight over the same period. Lately, however when I review or blog, I'm actually practicing my communication skills as well as doing a regular brain-dump. Practicing a thing you suck at is a great way to improve it purely through wrote learning or to overcome a personal barrier to the skill. Rome, was also not built in a day. at-sxsw-bluesky-ceo-jay-graber-pokes-fun-at-mark-zuckerberg-with-latin-phrase-t-shirt

No I'm not on Blue Sky, but let's stay on topic here. 

Job interview notes to self.

1. Practice your interview technique. 

You will often find you can get 2 job interviews booked in close together. For maximum effect you will want to book the job you want most, as the last interview. You will be able to reflect on the 1st interview and not make the same mistakes when it comes to the job you really want. It is common to step out after an interview and say to yourself, "I wish I had". At least if you have ADHD tendencies you will, apparently the brain likes to not only pre-rehearse conversations, but it also records them. For example in my recent article about Motivation, I spoke about the one question I got wrong interview-tips-prologue .

2. Interview the interviewer

The way I see it, I'm never going to be a 10X developer, that engineer who is 10x more productive than the average, but I can get that extra 20% productivity that happy workers give, just by making sure I am working at a place that I can love. And that's a extra 20% that extends to every minute of the day and every situation, not just your strengths. Which brings me to Career goals

3. Have Career Goals

You are always going to be asked a hard question in an interview, my favourite one is not:

 - "If you were an animal which animal would you be and why?"

Better questions are:

 - "Why did you leave your last job?"

 - "Where do you see yourself in 5 years time?"

And to be brutally honest my answer usually has been, 'with a paid up mortgage?'. That is everybody else's goal too, and so to rise above anyone's estimation of you, you have to articulate more inner spark or energy. A clear desire to grow in value and brightness almost. To me this was never in my nature. Every year when career goals came up in a one-to-one I just made up something vague that lined up with what I thought my boss wanted to hear.

I think the big reason I have never held myself accountable on a career goal, is that, well I've had 8 different jobs over my career, and some of those jobs have even changed tack unpredictably. But accountability can be a big motivator, as I already hinted at, in the my post linked above. So for accountability I am going to put security down as a career goal. More specifically code security, static analysis and code quality security, not penetration security. I'd like to learn how to pen-test, but a rotation back to being almost pedantic about clean code is probably my next goal. expect more on this in future.

4. Listen

When I step into an interview, my brain goes into overdrive a bit. I want to answer every question as quickly as possible. You cannot do that with words. most often to me, time wasted with a conversation pause feels like money wasted, it's not. In the real world, that's not how I write code, I write something, then review and rewrite it. Sometimes taking a moment to double-think before you speak has 3 advantages:

A: People think that you are wise because you didn't just blurt out a pre-made answer, you actually solved the problem in real time, as a brand new problem.

B: You calm things down and take the "rush" out of things

C: You can file away for later any extra information the interviewer just gave you. People are super impressed when you can recall a minor point they made hidden in a much longer exchange because you just listened.

5. Relax

Probably linked to the listening skill, relaxing requires my being super prepared. Most people do not know how to prep for an interview. I don't. Lately the way I get myself ready for an interview is my getting a mental image of each person I will meet in the interview. I look up things like how long they have been there, which uni they went to and any notable companies they have worked at in the past. Having some common base in a company you both worked at before is often a good culture clue, for engineering jobs at least, it often is.

Interview tips (prologue)

First of a 3 part series

Communication Styles

Last night I was in an online chat about communication styles and a young lady (I say this rather glibly because I was twice the age of the youngest person there) was moaning about people miss-understanding her. I struggle to read the room well, and I suspect it causes a lot of my interview impressions to be bad. I just have to accept that people who do not know me will probably not get, how dedicated and full of energy I truly am, from the job interview setting. 

Mistakes

I recently made 3 mistakes in a job interview which gave the impression that I'm someone who takes short cuts or is lazy, which jars with anyone who knows me. But that was the feedback, sent over, so I wanted to somehow call them back and explain the error, but. I had perhaps given that impression at least in 3 different instances, one of which I was tricked into. You can kick yourself, but it's their loss. I do kick myself though anyway. I still recall my first interview screw-up. It was admittedly my first ever interview, probably 30 years ago now. But a big thing I failed on was the practicality that the job was about 15 miles away and I had no car of my own. (This was Africa where busses do not really exist.) I did in fact have use of a car, but it was not my own, and yes I could easily afford to buy a car, but that had not occurred to me. They wanted someone who could work extra time on occasion, it was an IT job after all, so they asked, "do you have a car?" I said no, stupidly, but I was being honest.

Wins

Have answers for their possible questions and prepare well, this will boost your level of calm. Being nervous is not an interview excuse at all. Aside from predicting some of the questions you might get, the winner interviews were all ones where I stuck to my technical knowledge and did not try drift into being "mister nice". My first win was a referral, which I got almost entirely on the basis of being a friend with someone while on a full time training course. They offered to pay for my plane-ticket if I was successful. I met 2 directors and briefly the CEO too. I was sat in a room with a computer, internet and an IDE, and had to solve a linked-list problem from scratch in C/C++. The job would involve me porting Pascal and "C" code to C++, and I somehow did impress. That afternoon I flew home with a large manila envelope. My dad still gave me a bollocking for not signing and accepting the job offer right there on the spot. Ha ha! I packed my life into a station wagon a month later and drove from Cape Town to Johannesburg, and stayed there for 14 years. I only left to relocate once more, to the UK this time. 

Be prepared for the coding interview segment, most of all. I always freeze up when coding. Even though I am pretty ace at coding, my flaw is not reading the question properly. Something one rarely encounters in real life where the question is often really obvious. I panicked, until I read the question a second time and realized, the solution was far simpler than the one I had in mind. I did an online code test recently, for the same company that I had ducked out of their process on a few years ago, because I just feared the coding test. Pathetic. This time, I gritted my teeth and aced it. I believe the word for it is imposter syndrome.

You can often, only get a job, if you had one in the past, that proves you have the skills already. Employers don't want unskilled people. But they cannot spot people who learn quickly anyway in an interview, so my CV and covering letter writing skills have probably played a bigger part than they did in the past too. I used to majorly suck at writing, even though I write documentation copiously at work. Yes, my writing was, until 3 years ago, unreadable. But that's another story for later, for now I practice a lot.

3 Motives

My usual motive for applying for a job, is because the company does something which I think is useful or cool, not because I want the money. I recall getting a long-service award once, it was a sweet amount of money, in cash. I did not even open it to look, I handed it to my wife. She had a spa experience and full hairdo off of it with change. The money pays a mortgage, but money does not motivate me at all on a Monday morning at 8am. I once, took a job for the good money and ended up hating it overall for other reasons in the end.

My youngest son finishes a CS degree this summer, and as he starts hunting for work soon, I have had to quell his fears about not getting a job. I probably need to learn what it is he is looking for in a job now as well. Notwithstanding his lack of job experience, but these days it's harder than ever to even enter the market. So aside from my own job-hunt some of this post, is me formulating how to give my son some pointers.

I know nobody reads these articles, but I've never written on my blog about my early interview experiences, and this place feels more relevant than my blog does. It's also writing practice.

How I test Games

If you want a career as a Tester, this is for You

I don't test computer games, well, I do, but I'm not paid to. I will hopefully never work in a game software house, but it's not a bad way to start at all. I decided testing games was not for me after a interview at Sony in London. 

In a gray part of London in 2006 (much of London is gray looking once the heat of summer kicks in mind-you), I went to a round building, full of kids. Don't get me wrong, I've been to the Jagex (Runescape) HQ too and those kids are having the same kind of fun, but the pay. So yeah, not for the pay and the hours at all, but I do test games. I started writing games reviews over 3 years ago. and that has attracted attention from small indies who want to get positive reviews written around the time of their launches. Pushing the socials kind of stuff, so they often send out free pre-release copies. When I get a copy I write a review, but I also give defect feedback for any that are in beta, and here is gets tricky.

Games are easy to test and a good start for learning for to file defect reports.

How to write a bug report without any requirements

Well, you do have 2 requirements, the game has to be "playable" and has to make someone money eventually. 

Requirement #3 You have the game description, so when reporting an issue with the game, you want to see where the game description deviates from what your experience is. If the game is aimed at children, it has to use suitable language. Not too cutesy, because kids know when they are being spoken down to, but not too adulty, or else mum won't let her 7 year old play the game. So the smallest bugs you can raise are for things like grammar and spelling, and believe me, these are really easy to screenshot and get corrected. Easy bugs also help you get the developers attention. build relationship, ask them questions about what they hope the game will become or do. And be genuine but kind and build connection. In a real job, bugs are not just a thing you write up once and forget, they are a conversation than can go back and forth. In the industry we call it "bug tennis", where an issue goes back to you because you left out something or explained it poorly. This costs time.

What

Where/When

Why

1. Think small, but think big.

The best time to write a well supported bug for a computer game, is when the code is still very changeable. It's amazing how badly architected games code can be and how hard to change it often can be. Games are usually monolithic and not component-based at all. They are supposed to do one thing, and not have components that make any code changes easy to do in the way applications might be modified. So any suggestions that require a big change are usually far more work than you think.

Above is a screenshot of a game on the left with my suggested "accessibility" change on the right as a mocked up image, to make the text pop more. There are other issues in this screenshot, and my version on the right is not perfect, but it's a 5 minute defect. Always describe what you "expected" things to end up in your bug report. Not what you wanted to happen.

2. Smol QOL changes, bigger wins.

QOL (Quality Of Life) are one step bigger than the smaller (SMOL #slang) cosmetic bugs like fixing spelling, fixing the colour of something or the positioning of something. I see a lot of games get bad reviews not based on the enjoyability of the game, but on it's playability. For example any interaction menu like when clicking on something or responding to an event the user has to perform a repetitive mouse gesture or series of clicks. These break immersion because they waste time. Gamers call these QOL issues.

3. Classification

When writing a bug report, don't write like people do on the forums, come up with a classification system that makes sense for the product, and use the class of defect in the defect title. This will grab a developers attention when they are fishing for defects to fix in the backlog tool whatever that might be. good defect titles make you not only write a good bug report, but also mean you bug will get seen if at all in the flood of emails a developer might see.

I prefer to spend a minute and write a one liner bug title before I start writing up the bug itself. Bug titles should fit in one line in your screen. Example:

"Cosmetic: When catching a butterfly the camera briefly goes fuzzy"

Now this bug might not be a simple one to fix in the end, but it's not a critical bug like a crash or other data loss bug. Hangs, Crashes, Data loss, all of these are what we sometimes call showstoppers. which brings me to another point about bug reports.

Having a good bug title/description will also force you to write the bug report about one item and one issue only. Never lump 2 bugs into one unless they are tightly related.

4. Priority versus risk

Do not ever try to give a bug priority, that is the product owner's job. Lots of the bugs you report will never be fixed, often because the issue you found does not really impact the core mission. Or worse is a hard to reproduce defect, or just a defect that does not do much damage to the end quality. People who post on forums have a habit of making their complaint about a game or an app, the most important. They forget that 90% of people playing the game will not ever notice the thing that they do. Yes, most bugs, tend to only impact a very small number of users. The ones that impact all users are ones that tend to get fixed. Given the choice of 2 defects I might find, I'm always going to raise the one that will impact more. So the tester's job is to describe the impact or risk of a bug impacting a user, not it's priority in the work queue.

Finally: Screenshots Screenshots Screenshots

Before you hit send on your beautiful bug description make sure you have evidence, and are laying out your bug report with the 3 key elements. What, where/when and Why.

I love testing all kinds of software, and hope to improve my written communication, so expect to see more of these. Let me know in the comments are you a paid games tester, I really would love to hear from you.