Bloggity Blog

Stop Lying On Your Resume

Posted in Thoughts

Articles for Thoughts

Believe it or not, most interviews aren't actually about finding out if you're good at what you do or not. They're mostly about finding out if you're a good person. Weird, isn't it?

Before you're ever notified that a potential employer wants to talk to you they have sifted through many resumes and whittled the number of potential-employees down to 5 or 10 people.

You may meet with any of the following people during your interview:

  • HR Person / Recruit
  • Hiring Manager
  • Director
  • Project Manager
  • Technical Interviewer

The Recruiter or HR Person is the first person you will talk to on your path to being hired. His or her job is to look at your resume and talk with you to discover if you're someone who might work well for the position. Often, resource management software is used to match candidates with a position. The failure of software to choose good candidates is a leading reason software developers are more likely to be hired by referrals of colleagues than simply by submitting a resume. Typically a phone interview to determine if what you say matches what the company is looking for. They will set up the interviews and talk to the hiring manager.

The Director or Manager of the department is the person you will most likely spend the most time interviewing with. This person is here to determine more than anything if you're a good person. A good person for their department. How will you get along with your co-workers? Do you have major personality flaws? Are you easy to talk to? For most jobs it's not terribly simple to determine how you are going to do before getting the job. Having the right personality for it is their number one indicator.

If you do well during this part of your interview, chances are you're going to get hired in most companies.

However, if you're applying for a very technical job, this might not be the case. This is where the technical interviewer comes into play.

Who exactly is this Technical Interviewer? It's someone who already knows what you're claiming to know and has demonstrated that at the company. If you put on your resume that you can program in C, Perl, Scheme, LISP, Haskell and x86 ASM you're likely to find yourself face to face with a programmer who is already known at the company as a person who can code.

If you know these languages, it's great. If you can explain what strncpy does, that HTML::TreeBuilder is your preferred method of parsing HTML in Perl and how the mov opcode works differently when used against control registers you'll probably do great!

If you're stumbling around questions about the differences between a strictly-typed language and a dynamically-typed language then you don't really know C and Haskell do you?

The Technical Interviewer has one goal: find out if you know what you claim to know and how well you know it.

Most typically this is done by asking questions, beginning with questions that would be most commonly-known and escalating to questions whose answers are typically only known by rather bright programmers.

Let's take a look at some real-world examples. These are questions that were prepared to ask an interviewee who had said they knew Perl:

1. What are the data types you use the most in Perl?
2. What does \Q and \E do in a regular expression?
3. What modules from CPAN do you use the most?
4. What will the following code print when run?

use warnings;
use strict;
use Data::Dumper;

sub _parse {
   my $string = shift;
   my $res = {};
   for(split /[;&] ?/, $string) {
      my($n, $v) = split /=/, $_, 2;
      if ( exists $res->{$n} ) {
        if ( ! ref $res->{$n} ) {
            $res->{$n} = [ $res->{$n}, $v ];
        } else {
            push @{$res->{n}}, $v;
      } else {
        $res->{$n} = $v;
   return $res;
print Dumper _parse("foo=5&l=1;foo=10&key=r bar=world");

5. What is a recent project you did in Perl?

The first question is fairly obvious. If you've worked in perl at all you will at least know scalar, hash and array. You might get bonus points for glob and for explaining why blessed refs and refs don't count as unique data types since they're just glorified scalars.

The second question is somewhat esoteric, but it tests how much you know of regular expressions. If you simply say /$foo/ the contents of $foo will be used as the regular expression so if it contains (\s+) the regular expression is treated as a capture of 1 or more whitespaces. If you say /\Q$foo\E/ it's treated literally to match (\s+) itself. This can gauge if someone knows regular expressions somewhat well.

Any good Perl programmer uses modules from CPAN. Personal favorites may include Data::Dumper, DBI, LWP, all the big ones. More than finding out what your favorite modules are, this question aims to ask, "Do you know CPAN at all? Do you use it?"

The 4th question aims to see if you're mind can act as a compiler and if you know advanced data structures. Being able to correctly answer this question suggests you're a good programmer and have been doing this for some time.

The 5th question prompts how you work on projects. Most projects run into bumps along the way, spec changes, any number of horrible events. How an individual recalls and explains these events, how they found solutions, and the overall project itself gives you a peak into their past. Stock and Bonds people say that past performance is not a guarantee for future success. I disagree.

Getting through these types of questions is extremely difficult if you don't actually know the language. There is nothing more embarrassing than being called out on what you don't know during an interview. Both you and the person interviewing you become uncomfortable and it's just a horrible experience.

Your resume is your very first impression on a company. Don't have that impression be a lie as soon they meet you.

blog comments powered by Disqus