how to prepare for and survive a technical interview

How to Prepare for and

Survive a Technical

Interview

Peter Sergeant - [email protected] - http://perl.careers/

mailto:[email protected]

All About Me

Who I am: Perl Developer

• 13 years commercial experience with Perl

• Gave my first talk at YAPC ~ 14 years ago

• 15 CPAN distributions

• Been a contractor, a permanent employee, and a

freelancer

Who I am: Hiring Manager

• CTO at an enterprise software company

• Team of 40, most of whom were Perl developers

• Spent a lot of time reading CVs, interviewing,

hiring

Who I am: Recruiter

• Run a recruitment agency called Perl Careers

• Specialize in Perl developers

• Please come and get a pen and a business card

• They were expensive

Who I am: Who Cares?

• The only recruiter who has been on all four sides

of the table

• Developer looking for work

• Developer roped in to interviewing potential

coworkers

• Hiring manager

• Recruiter

The Secret

Nobody has any idea what

they’re doing

• Don’t confuse a multi-stage well-organized

interview for an effective interview technique

• Any person or company who thinks they’ve nailed

interviews has been lucky to this point

• There are a small number of things you can

achieve as an interviewer though

What an interview can tell

you about a candidate

• Can they answer questions about the skills they claim to have experience with?

• Can they present some evidence of their experience with those same skills?

• Are they capable of maintaining a façade of normality for at least a few hours?

• Can they – under duress – have a technical discussion where they respectfully listen to the other person’s opinion?

• Do you like them, basically?

Your goals, while being

interviewed

• Provide evidence of having used those tools you

claim experience with

• Try and not be too weird for a few hours

• Don’t shout at the interviewer

• Make yourself appear likeable

Your goals, while being

interviewed

• Provide evidence of having used those tools

you claim experience with

• That’s what this talk is about

• You’re on your own with

• Not appearing too weird

• Not shouting at the interviewer

Do your research

about the interview

Minimum Requirements

• Who will you be meeting?

• You’ll probably just get job titles, but maybe actual names

• Try and find them on LinkedIn (using the job title, or name)

• You might know people in common you can get some tips from

• Maybe you went to the same university

• Try and find them on GitHub

• Are you among the handful of people in this world who have INTERCAL repositories?

• You can avoid making jokes about PHP developers when you see they’re one of the core contributors to Magento

• Don’t contact them, don’t be a stalker


• Will there be a technical test?

• What form will it take?

• Is there anything you can do to prepare?

• Some companies will be upfront about what areas they will be digging in to your knowledge of

• You probably don’t have time to digest an algorithms book

• But you probably do have time to check you remember how Moose / DBIx::Class resultsets work


• How does the whole process work?

• Are you going to be in this process for four weeks?

• You may not want to talk about salary in the first interview• But that’ll make life difficult if that’s also the only interview

• Hints on how well you’ve done• If you appear to have skipped 2 interview steps, perhaps

ask for more money?

• If you appear to have stalled somewhere, you’re probably not their preferred candidate

The recruiter should know…

• The recruiter or HR person should be proactive

about telling you these details

• Not all recruiters or HR people are good at their

jobs

• Entirely within your rights to ask these questions

• Although they often won’t know exactly who you’ll be

meeting

• Because this is often decided 15 minutes before the

interview…

How to approach

different types of

technical challenge

https://commons.wikimedia.org/wiki/File:Ethernet_12U_box.jpg

Challenge: Code review

some existing work

• Be cautious, it may be the interviewer’s master piece

• More likely, they know some things are wrong with it

• Can you pick out what’s wrong with it?

• Can you suggest alternative approaches?

• … without calling it and the author a bad joke

• Avoid calling out coding style or anything that could be fixed with PerlTidy

• Although pointing out that PerlTidy is a good strategy for production code seems reasonable

• Inconsistency is probably in scope too

Challenge: Implement an

algorithm, solve a problem

• If you don’t know it, be upfront about it

• And then give it a go anyway

• Much more on the right way to do this in a few slide’s time

• Generally they are trying to work out how you think, and how good you are with coming up with questions about the task at hand

• If the company you’re at has a reputation for asking these, and you have enough time, relatively easy to revise

• Don’t get defensive

This man will regret this

tweet

Take-home project

• Write some code to solve a task, on your own machine, in your own time, inside a time constraint

• [Unicode Character 'HEAVY BLACK HEART' (U+2764)]

• Probably the only good way to do a technical interview

• Often not designed to be finished

• Bite off what you can chew, and can chew well

• Keep notes on why you did certain things a certain way, take them with you

• Make sure you can explain every line you’ve written or they’ll assume you copied it off StackOverflow

• You better believe I will be asking you about your use of

__PACKAGE__->meta->make_immutable;

Idiotic programming trivia

sub { return

((1 x shift) !~ /^1?$|^(11+?)\1+$/)

}

• “What does this do?”

• Someone really asked me that in an interview

• It’s probably not indicative of some deeper truth about the company or

future colleagues

• So unless you already hate them, probably not a good idea to

launch in to a heated take-down of their interview, parentage, etc

• Grin and bear it

Show your working

Show your working

• Whether or not you can solve a technical problem

is rarely the real question

• The real questions are…

What an interview can tell

you about a candidate

• Can they answer questions about the skills they claim to have experience with?

• Can they present some evidence of their experience with those same skills?

• Are they capable of maintaining a façade of normality for at least a few hours?

• Can they – when motivated to – have a technical discussion where they respectfully listen to the other person’s opinion?

• Do you like them, basically?

Share your thoughts…

“Reverse a binary tree”

• What don’t you know, and what are you

assuming?

• “A binary tree is a set of nodes with … two children

and a root node?”

• What are the constraints?

• “I guess it the optional strategy probably depends on

how big the data is?”

• “Is saving every last piece of memory more important

than developer clarity?”



• Test your thinking with examples

• “Let’s draw a simple binary tree, and think about what

reversing it would mean”

• What would you need to look up?

• “I bet this takes an amount of time that grows linearly with

the number of elements – I know that you’d write that with

“Big O” notation, but I don’t remember how to write that”

• “I know some programming languages can save memory

by doing ‘tail recursion’, but I’d have to look up how to do

that in Perl”



• Say exactly where you’re getting stuck!

• “I know there’s a feature in Perl where I can reduce

the reference count to allow something to get

garbage collected, but I don’t remember what it’s

called”

• The interviewer likely wants you to succeed

• If you can tell them exactly what you’re having

trouble with, they can give you hints

• But they’re not psychic



• Think about failure modes

• “What should I do if a node is missing?”

• “What should I do if I get empty input?”

• These aren’t questions to the interviewer necessarily,

be willing to reason through a sensible answer

• But it may be the interviewer wants it solved in a certain

way



• Showing your willingness and ability to think is far

more important generally than solving the problem

• I will hire the person who had interesting insights

in to the problem but got stuck on something

because they were nervous

• The person who just sat, assumed, and wrote

working code without asking anything is liable to

be difficult to work with

Don’t (just) answer the

questions

Interesting trumps right

• The point of technical quizzes is not getting to the

right answer

• The point of technical questions is also not getting

to the right answer

• The point is that you get to show off your technical

chops

So I see you like

databases…

• If you get asked about which databases you’ve

used

• (by a technical person, rather than a recruiter doing

due diligence)

• DON’T JUST LIST THEM

So I see you like

databases…

WRONG:

• “I’ve used MySQL for three years, I’ve used

PostgreSQL, and I have used SQLite for testing”

• SO WHAT?

• It said that on your CV

So I see you like

databases…

BETTER:

• Share some war stories and battle scars

• That Unicode issue you had with MySQL that took three weeks to solve because you accidentally used “Astral Plane” character points as test data

• That time your team was using SQLite as the test database, but Postgres for the real database, and there was that hard-to-track error

• The really clever solution you had to come up with for the distribution key on Redshift, and how you benchmarked different approaches

Interesting trumps right

• If you’re boring them, they’ll probably cut you off

• But if you give short answers to questions, they’ll just ask you other questions

• And you may not have such good answers

• For example: personally, I can answer question on “testing strategies” really convincingly. So:

• If I get asked ANY question that I can segue from in to a testing strategy answer, I will do that

• You want to spend as much time talking about the things you really know well as you can

Prior preparation and

planning

A simple strategy

• This has served me well for a decade

• Write out a list of questions you’re going to be

asked

• Write out a “perfect” answer to each

• Practice saying it out-loud 4 or 5 times

• Don’t try and memorize them

• It’ll just sound weird, and it’s hard work

A simple strategy

• Actually really for real say them out-loud using

your mouth

• You will find parts of these answers coming out in

the interview itself

• You will have straightened the answers out in your

head

• It’s a nice confidence booster to revise these on

the way to and before the interview

Non-technical

questions you should

prepare for

Do you know what we do?

• Make sure you’ve read their website

• They don’t really care if you know or you don’t

know

• They care if you’ve taken the time to find out

• Even if your answer is wrong, it’s right

• As long as it’s evidence you tried to find out

• And you’ve not demonstrated irredeemable stupidity

Why do you want to work

here?

• aka: “What excites you about the role?”

• The honest answer is probably “I need a job, and you might pay more”

• Don’t tell them that

• The job spec and company website will tell you what the company values about itself

• Rephrase those and parrot them back

• Again, you are trying to show ENTHUSIASM

• And showing that you can pretend to not be a grumpy developer for at least a short amount of time

Why are you leaving your

current role? 1/2

• Under no circumstances make disparaging

comments about your current company

• They have no way to know that you’re not the

problem you are presenting

• If you can’t show you have the social skills to not

trash your previous company, that’s a big red flag

• Try not to look like an HR liability

Why are you leaving your

current role? 2/2

• Example safe answers

• If you’ve been there more than 4 years, you are interested in trying something new

• If you’ve been there less than 18 months, the role was misrepresented to you, but you’ve felt bad about leaving them in the lurch

• Between those two, find some aspect of difference between the current company and the old one, and highlight that

• “I want to work for a smaller and more agile company”

• “I find your products more interesting”

• “I want to focus more on Modern Perl and I see you’re using xyz”

Red flags on your CV 1/2

• Expect to get asked about any red flags on your

CV

• Such as:

• Big gaps in work history

• That time you got fired / had a 1-month role

• Lots of short roles

• Started but didn’t finish higher education

Red flags on your CV 2/2

• These are not a big deal … unless you freak out

when talking about them

• Get a reasonable story straight about why, practice

telling it, and you’ll be fine

• If you have gaps, focus on talking about productive

things you did during that time

• The focus of your story should be upbeat, how you

overcame adversity – we’re going for Rocky, not

Silence of the Lambs

• So don’t be too angry or bitter

Other random questions…

• “Tell me a bit about yourself”

• Give a quick overview of your CV, or launch in to something you want to talk about, such as:

• Some things you’ve enjoyed working on professionally

• Some technical stuff you’ve enjoyed working on in your free time

• “Where do you see yourself in five years time?”

• This question is really “Can you provide professional-sounding waffle without telling the interviewer you think their question is stupid” – and you can, especially if you prepare it

• “Tell me about a time you had a difficult situation at work”

• This question is really “Do you have enough social skills to come up with something that doesn’t make you sound like a psychopath” – if that’s going to be a problem for you, or you don’t know if it will, prepare with the help of a friend…

Technical questions

you should prepare for

Perl

• What’s the latest stable version of Perl? What version of Perl do you use at work?

• What are some of your favourite CPAN modules?

• What are some recent changes to Perl you’ve found useful?

• What does Modern Perl mean?

• How does Perl compare to x? (where x is a language you listed on your CV)

Generally…

• Assume any skill or experience you’ve listed on

your CV is fair-game for an interviewer

• You’re going to look like an idiot if you’re written

you’re an XPath expert, but you haven’t touched it

for 10 years, you’ve forgotten it all, and you get

asked about it

• Assume every skill listed on the job ad is a fair

game

• You should at least know what it is, what it’s used for,

and what alternatives exist for it

Tell war stories

• Nothing proves your experience more than war

stories about technical challenges

• Issues you had with Catalyst’s flash feature

• That time when you were caught out by hash key

randomization

• Why you started insisting all developers use PerlTidy

• Pick a few, practice talking about them, and you’ll

find they slip out during the interview

Question Preparation -

Conclusions

• You’ll end up with more questions than you have time to write good answers for, so prioritize them

• Really really really really practice saying them out loud – they’ll stick in your memory, and will come out during interview

• The more time you spend giving good answers, the less time they have to ask bad questions

• Don’t put anything on your CV you can’t say something intelligent about

Final Points

…

Final Points

• If you’re unsure what to wear, ask if smart casual or a suit would be more appropriate

• Turn up on time … or better yet, show up super early and hang out in a coffee shop reading your prepared answers, so that you’re not caught out by traffic / public transport / civil unrest

• Sound positive about the role, even if you’re not• The other roles you have lined up may fall through

• Leave a good impression for next time you interview with the same interviewers, at a different company

• Don’t say disparaging things about former employers

AN OFFER YOU

MUST NOT REFUSE

If you are job-seeking, and you know Perl, I will rewrite your CV for you, so that I can send it to employers, so that I can make cash

money.

[email protected]://perl.careers/

mailto:[email protected]