Successfully reported this slideshow.
Your SlideShare is downloading. ×

How to Prepare for and Survive a Technical Interview

Loading in …3

Check these out next

1 of 55 Ad

More Related Content

Slideshows for you (20)

Similar to How to Prepare for and Survive a Technical Interview (20)


Recently uploaded (20)

How to Prepare for and Survive a Technical Interview

  1. 1. How to Prepare for and Survive a Technical Interview Peter Sergeant - -
  2. 2. All About Me
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. The Secret
  8. 8. 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
  9. 9. 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?
  10. 10. 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
  11. 11. 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
  12. 12. Do your research about the interview
  13. 13. 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
  14. 14. Minimum Requirements • 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
  15. 15. Minimum Requirements • 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
  16. 16. 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…
  17. 17. How to approach different types of technical challenge
  18. 18. 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
  19. 19. 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
  20. 20. This man will regret this tweet
  21. 21. 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;
  22. 22. 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
  23. 23. Show your working
  24. 24. Show your working • Whether or not you can solve a technical problem is rarely the real question • The real questions are…
  25. 25. 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?
  26. 26. 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?”
  27. 27. Share your thoughts… “Reverse a binary tree” • 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”
  28. 28. Share your thoughts… “Reverse a binary tree” • 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
  29. 29. Share your thoughts… “Reverse a binary tree” • 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
  30. 30. Share your thoughts… “Reverse a binary tree” • 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
  31. 31. Don’t (just) answer the questions
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. Prior preparation and planning
  38. 38. 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
  39. 39. 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
  40. 40. Non-technical questions you should prepare for
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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”
  45. 45. 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
  46. 46. 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
  47. 47. 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…
  48. 48. Technical questions you should prepare for
  49. 49. 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)
  50. 50. 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
  51. 51. 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
  52. 52. 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
  53. 53. Final Points …
  54. 54. 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
  55. 55. 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.

Editor's Notes