How to Get a Job, Part IV: No No's

A week into holding interviews, here are a few things I've had happen that pretty much disqualify you for the job:

1. Fail to read the job posting. The posting said that you need to be a US citizen right up there at the top. You're not a US citizen? I don't feel sorry that you just drove an hour to get here.

2. Fail to understand what an interview is. Don't send me an email half an hour before the interview asking me if it is a real interview or a phone interview, and then asking to reschedule since I actually want to meet you. I'll still meet this guy, but he just dropped down to the bottom of the pile.

3. Be nervous. I know understand this little bit of performance anxiety, but get over it. I like confident applicants that act like they've done this before; they tend to do better under pressure when they get the job. If you're afraid of me, just wait until the owner of the company tells you that he needs a miracle five minutes ago.

4. Dress unprofessionally. Seriously: go put on that suit. You've lost me when you show up in jeans.

5. Ask me how to make a resume. I came across someone and mentioned that I was hiring. Just so happens he was looking, so I gave him my email address and told him to send me his resume. His response? "I've never made a resume, what should I put on it?" Sorry - a professional knows how to do this, and I'm not going to babysit.

6. Send me a resume that I can't read. That's right, I actually got a resume with no file extension or other type information. And you want a position at a software company?

7. Show up blind. We put a lot of effort into our website. Take five minutes to find out a little bit about our company.

How to Get a Job, Part III: The Setup

I freely admit that I'm a bastard.

Once I comb through the pile of resumes, I choose a few candidates that look the best / least worst and send out emails inviting the potential employees in for an interview.

I see every part of the interview process as a chance to glean just a little more information about candidates. When it comes down to it, most candidates have the same answers to formal questions, so I like to use bits that don't seem like formal questions. In this case, I give them the company name, but not an address.

A smart candidate will Google the company, find our address and write me back, "Is this the correct address?" A less promising candidate: "Send me your address." I like candidates that can find their own answers; I hate babysitting.

So much of IT is being able to answer questions for oneself.

How to Get a Job, Part II: The Submission

I know this sounds absurd, but choosing how and where to submit your resume can make a really big difference.

But first, read this public service announcement: only apply to jobs that might actually be a good fit for you. Yes, I'm talking to you, the COBOL architect that applied to a Java position, and you, the manufacturing specialist that applied for a network administrator job. I'm also talking to all those woefully under-qualified individuals, along with those extremely overqualified individuals with no relevant experience on their (nine page) resumes.

These types of submissions are, in no uncertain terms, spam. You know how you hate getting 582 spam emails a month? You know how you complain about getting telemarketing calls during dinner every day from inconsiderate jerks? Yeah - you just did that to me.

</rant>

There may be plenty of reasons to apply for a position for which you may not seem entirely right. That's fine - but explain in your cover letter. You live in Burbank? Acknowledge the fact and tell me that you're willing to relocate. You don't list the Microsoft Exchange experience I specifically wanted? Tell me how you can overcome the shortcoming. I read cover letters. Usually, they make a bigger impact than the resume.

And while we're on the subject: don't send your cover letter as an attachment! Your email IS the cover letter. Furthermore, while it is generally unnecessary to tailor a resume for a specific position, it is absolutely necessary to do so for a cover letter. Don't give me generic BS about wanting to find a position that will use your skills and abilities.

And finally: format. Microsoft Word is pretty common, but there are several problems with it. For starters, not everyone has the software. Opening it in different versions or alternative programs (I'm looking at you, Open Office and Google Docs) can royally screw up the formatting. Also, it's possible to wind up with viruses from it. Send me a nice PDF. How to do this is left as an exercise for the individual.

If you can't Google a solution, don't bother applying - at least not to a software company.

How to Get a Job, Part I: The Resume

AGHHH!!!

I spent most of my day reading resumes. This should never be an issue.

A resume should be a good, solid - and single! - page that gives the hiring manager a way to narrow down potential candidates to those that really fit the job.

A resume is not a novella. A resume is not your personal, epic saga from fry cook at McDonald's to senior architect at a Fortune 500. A resume is not a nine-page document of every single task you've completed in 20 years.

I have 30 seconds for your resume. Don't rush me - and above all, don't bore me.

Interview Questions

I've recently had the opportunity to partake in interviews of four candidates for programming positions.  On the last several, I've been the one responsible for determining the technical proficiency of the candidates.  And since having a degree or experience seems to mean absolutely nothing in the software world, this is not as easy as it seems.  I'd love code samples or a few weeks with each applicant, but as it turns out, the other prime requirement is that I find a way to determine technical aptitude quickly.

So here are my new three questions for interviewees:

1. Explain the difference between an interface and an abstract class

Goal: Determine proficiency with object oriented development

• Bad Answer: Uhh...
  
• OK Answer: An abstract class has partial implementation.
  
• Great Answer: Delve into the difference between implementation inheritance and polymorphism.
  

Evaluation: If they can't answer, the candidate does not have a good OO background.  If they also claim experience with OO development, the interview is over.  If they get philosophical about inheritance and polymorphism, they will almost certainly get an offer letter.

2. Are you familiar with Dependency Injection or Inversion of Control patterns?

Goal: See how people will react when they don't know.  Also, they might just know the answer, in which case: wahoo!  I usually ask this question as a, "by the way..." when the candidate is approaching the white board for a coding question or some such.

• Bad Answer: Pretending to know when clueless.
  
• OK Answer: "I don't know."
  
• Great Answer: It's a technique for limiting coupling whereby objects are given everything they need, rather than having to go out and find it themselves.  Think of it as the anti- Service Locator.
  

Evaluation: This question hopes to achieve two goals: first, someone with real serious experience will have a pretty good clue what this is.  If they are claiming to be a rock star programmer with six figure salary requirements, they damn well better know how to answer it.  All told, though, this isn't something that is taught in schools and most junior programmers will be clueless.  Watch how they answer for some insight into their ego.

3. The programming question.  There are two I like depending on how the situation is progressing.

Goal: Does the candidate have a good basic understanding of OOP, and can he or she explain an idea?

3.A. Could you pseudo-code for me a class to represent a time?

• Bad Answer: Using Strings for hours, minutes and seconds, using a platform Date/Time class, anything that doesn't make sense.
  
• OK Answer: A class with fields for hours, minutes and seconds, and methods for getTime(), etc.
  
• Great Answer: Keeping a single field that is, say, milliseconds from a reference point.  This is how most platform libraries do it.  It avoids problems with time zones, etc.
  

Evaluation: When asking, keep prodding.  Does this implementation take into consideration time zones?  How would it handle a Daylight Savings switch?  You are evaluating not only OOP fundamentals, but also how well the candidate approaches the problem.  Can they explain their thinking?  Do they respond to criticism?  Do they attack the problem, or are they afraid of it?

3.B. Could you pseudo-code for me a class to represent an address?

Make sure to keep prodding the candidate.  Would this address work in Canada, where there aren't states?  Would this work in Xxx, where zip codes are not numeric?  How are you parsing countries?  Would that work for, say, the city of Lebanon, Missouri?

OK, this is a trick question.

This was the interview question I received when interviewing for my current position, and the person giving it to me received it when interviewing at Microsoft.  When I left the interview, I went home and told my friends that I was definitely not getting the job.  The purpose of this question, even more than the previous one, isn't to get a correct answer - the question is, quite literally, impossible to get correct in the span of an interview - but to judge how the candidate approaches tough problems.

H'okay, so I lied - there are several others I like, but those are the main ones.  But what am I really getting at?  What am I looking for in a potential new developer?  I'll try and get to those next time...