Getting Exposure for Your Resume

So you’ve spent weeks polishing that resume. What do you with it now? You have several options:

• Post it to Job Boards
• Reply to Job Listings
• Apply directly to Companies
• Send it to Recruiters

Posting your resume to the job boards is what people do instinctively. You’re hoping that recruiters and companies will find your resume there through targeted searches and contact you about opportunities. Basically, they do all the work for you. What could be easier?

In practice this approach really only works if you have the in-demand skills and with at least 2 years of experience in those areas. Without that companies will likely see you as too junior and refuse to consider you. So if you don’t have the qualifications, expect to get a lot more spam than job leads.

If you reply to the jobs posted on places like Monster, HotJobs, etc., you are typically replying to recruiters, and in a few cases, directly to companies. You can also go to those companies’ web sites and apply directly. In both cases you need to be reasonably sure your qualifications match their requirements, and you’ll likely be competing with many other candidates. A good cover letter may help in this situation.

Finally, you can spam recruiters directly without any particular job in mind. This approach is perhaps the least likely to be successful. You have to be lucky and hope that when your resume crosses the recruiter’s desk it happens to exactly match the job they’re trying to fill at the moment, as recruiters have a rather short attention span. Otherwise your resume might get a cursory once-over and get placed into their database, or worse, into the virtual circular file.

So if these approaches all sound dismal, you shouldn’t fret. It’s all a numbers game, and the more you circulate your resume, the higher your odds are of landing the right job. Don’t give up!

Explaining Gaps in Employment

There are constructive and creative ways to deal with gaps in your employment history. If the gaps are short you can simply list on your resume the years you were at each job, such as “2001-2002”, instead of including months as in “3/2001-6/2002”. Be aware though, some companies may want you to fill out their own application forms requiring exact dates of employment.

Another popular way to deal with gaps is to claim that you were self-employed as a ‘Consultant’. However, you may have to back this up by listing actual projects you worked on during that time. And putting together a web page for your girlfriend doesn’t count.

You could also attribute the gaps to personal problems you were dealing with (medical issues, family matters, a divorce, etc.), but that’s a gamble: the interviewer might sympathize with you, but they might also wonder why you let your personal problems get in the way of your career.

Finally, you can just come right out and explain why you were out of work. If your company was downsized or went out of business, it’s not unexpected that you would be unemployed for a while. But if you have an especially large gap -- e.g., several years -- you may have to explain why you could not or chose not to find work.

Here are some examples of creative gap accounting that I’ve come across. They may or may not fly depending on the hiring manager.

• Sabbatical
• Personal Projects
• Retooling skill set
• Volunteer Work
• World Travel
• Raised Children

Personally I might be willing to buy any of these explanations assuming you had a good story to go with it.

Do You Need a Cover Letter?

Fact is, as the hiring manager I hardly ever see cover letters; they’ve usually been stripped off by the time the resumes get to me. So if you do write a cover letter it should be targeted at the recruiter or HR manager. For the hiring manager you should focus instead on a good objective or summary on your resume.

If you do write a cover letter then, it should specifically address the qualifications listed in the job req, as that’s what the recruiter or HR person will be looking for. For instance, say the job req is as follows:

"Looking for an experienced .NET engineer with 3+ years ASP.NET, C#, and SQL Server. Knowledge of HTML, CSS, JavaScript, and SQL Server required. Nice to haves include WCF /WPF, WinForms/WPF, .NET 3.5, and AJAX. Contact Joe at Joe
Schmoe Recruiting."

Then you might compose a cover letter like this:

"Dear Mr. Schmoe,

I wish to apply for the .NET Engineering position you have listed online. I feel that my nearly 4 years of ASP.NET and C# experience more than meet your requirements. I also have significant experience with HTML, CSS, and JavaScript as part of my development responsibilities. And while my hands-on SQL Server experience is limited, I do have a strong command of database concepts.

I also possess many of your desired supplementary skills, including hands-on experience converting a WinForms application to WPF. I have also researched WCF and LINQ from .NET 3.5 for one of my projects.

Yours Truly,

John D. Applicant"

Resume Do's and Don'ts

There is a lot of information available on the web regarding goofs people make in resumes -- Do’s and Don’t’s, essentially. I’ll try not to repeat all that information here, but I do want to mention few things I consider important.

Spelling: In this day of automated spell checkers there should be no excuse for spelling errors. What I see more often though is misspellings in tech terms – e.g., ‘Ajacks’, ‘Pearl’, or ‘Sequel’ . Not only does this look silly, it also tells me that you likely have no real understanding of the technology.

Tense: Generally your summary / objectives and skills list should be written in the present tense ( ”I am…”) or neutral tense (“Skilled engineer…”). Accomplishments and work experience sections should be in the past tense (“I did…”). You should not vary from this format without good reason.

Perspective: Your resume can be presented in the first person perspective (“I am a …”), or neutral (“Experienced developer with…”), or rarely, even in the third person (“Joe Blow is a solid…”). But you should avoid mixing them up.

Sentences vs. Snippets: If you’re going to write in snippets rather than sentences, do so consistently throughout the resume. Try not to mix the two forms.

Action Verbs: These are good, but vary them. e.g., don’t start every single sentence with “Designed…” or “Developed…”

Errors in grammar: This is more common among those for whom English is a second language, but I see it also with (presumably) native English speakers. Don’t rely solely on Word’s grammar suggestions (the squiggly green lines), as they can be misleading. Pick up a copy of Strunk & White if you need to.

“Weasel Words”: A lot of adjectives are essentially meaningless and will likely be ignored (e.g., ‘Solid’, ‘Skilled’, ‘Dedicated’, ‘Professional’‘, “Goal-Oriented”). However, some invite more scrutiny as they make the candidate sound better in a way that’s difficult or impossible to back up. e.g.,

• “Proven performer” – Exactly how was this proven?
• “Integral member of…” – Just how integral were they?
• “Acclaimed as …” – Acclaimed by whom?

If you insist on using these vaguely suspicious superlatives, don’t be surprised if I challenge you to back them up.

Resume - Work History

Typically the biggest component of your resume will be your work history.

You should list your jobs in reverse chronological order, most recent position first. You should also dedicate the most space to your most recent job, unless it was a brief stint. Likewise, you can provide successively less detail about earlier jobs.

Personally I like to see details about each job in bullet form, but since some resume parsing software may not like bullets you can also use essay form. Either way, you should keep the details relatively short and easy to read. However, if you listed the details of a job earlier in your resume in an ‘Accomplishments’ section you should expand on that in this section. Try to avoid having essentially the same text in both sections.

Some people like to list out each project they worked on at each job, but I feel that takes up too much space. You need to keep your resume down to 2 pages, remember. So try to limit each project to a single bullet point or 1-2 sentences.

For each position or project you should list the technologies you used, and more importantly, what was accomplished. Avoid getting bogged down in details, and definitely avoid using any company-specific terminology or abbreviations that no one outside your company will understand.

Here are some bad examples:

• Used C#, ASP.NET, and SQL Server. (Used them to do what?)


• Utilized ASP.NET for a Web development project. (Better, but tell me more details!)


• Worked with Visual Studio 2005 as source control, wrote store procedures, business components and made UI changes. (Nice laundry list, but how does this show your competence in any of these areas?)


• Worked closely with art department to prepare new artwork for various websites. (Just what skills or achievement does this illustrate?)


• Enhanced APEX system to update TPS cover sheets. (What the heck does that mean?)

And here are some better examples:

• Used C# and ASP.NET to develop a website consisting of over 30 aspx pages. (Shows tools used and results accomplished).


• Re-engineered JavaScript code to reduce page load times by an average of 30%. (Illustrates quantifiable results).


• Optimized SQL Server 2005 database by redesigning tables in third normal form, removing unused indexes, and adding covering indexes. Reduced data errors by 10% and improved query times by approximately 20%. (Describes results and shows an understanding of the technology).

Resume - Education History

Besides the Objective / Summary / Skills / Achievements section, what else is there to put on a resume? Well, you would typically provide your education history and work history.

Your education can be listed either before or after your work history, but I would recommend you put it afterwards unless you attended a stellar school. Of course, the definition of ‘stellar’ may depend upon your particular field. And if for whatever reason you do not want to emphasize your education, you’d definitely put it towards the end of your resume.

You do not need to provide too much detail about your educational history. Generally, you should provide the following:

• Institution name
• Location, if necessary to clear up confusion (e.g., UC-Irvine, Miami University of Ohio, etc.)
• Degree & Major
• Year of graduation
• Graduation honors, if any.
• GPA , but only if you’re a new graduate and your GPA is above 3.0 on a 4.0 scale.

Here are a couple of examples:

University of Nevada, Las Vegas
B.S., Computer Science, 2006
GPA: 3.3

University of California, Los Angeles
B.S., Computer Science, 2001
Summa cum Laude

And here is an unnecessarily detailed example:

State University of New York
Binghamton, New York
Bachelor of Science with Minor in IT Management
Additional coursework in Accounting and Finance
May 1996
GPA: 3.3 / 4.0

Remember, the resume screeners will only spend between 15 and 30 seconds scanning your resume. You want to convey the important information about your education, but you don’t want to clutter up that section and cause the readers’ eyes to drag.

Resume - Objective Statements / Summaries

What makes for a good Objective Statement or Summary for your resume?

Strictly speaking, an objective statement or summary is not absolutely necessary. However, if one is present it should be located near the top, and it should succinctly describe your qualifications and the value you bring to a position. Basically it’s your “Value Proposition”, as the marketers like to say.

An objective or summary should NOT be a description of what you are looking for. This is a common mistake made by candidates. In fact your resume is not a description of what YOU need; it’s a selling tool stating what you have to offer the company. It also should not be a list of your accomplishments; you can add a separate ‘Accomplishments’ section elsewhere if you wish.

Examples of Bad Objective Statements / Summaries:

• Looking for a challenging position in software Development (This statement is essentially meaningless)
• To work as a team member in a highly motivated company with like-minded positive people, and to contribute my technical skills in a way that will further the objectives of the company I work for and fulfill my career goals (More wordy and even more meaningless)
• Experienced ASP.NET developer looking for a challenging web development position (Better, but the second half of the sentence is still unnecessary and candidate focused)
• I have 12 years of experience in a combination of skills including C, C++, Java, EJB, JDBI, .NET, ASP.NET, Ruby, SQL Server, MySQL, Oracle, PL/SQL, T-SQL, etc… (A summary should not be a laundry list of your skill set. Use a separate skills section to describe your technical competencies)

Examples of Good Objective Statements / Summaries:

• Experienced lead developer well versed in ASP.NET and C#.
• Senior .NET engineer with 10+ years in software development.
• Promising junior .NET developer, quick to learn, with solid educational credentials.

What If I’m Still a Student?

A commenter to a previous post asked what they should put on their resume since they were still a student. Clearly if you are still in school it’s tough to fill out the accomplishments list or an employment history. But before you give in to the urge to pad your resume with extracurricular activities, you should consider what information you can list that may be more useful to a hiring manager.

For instance, you can include your technical projects, either school assignments or personal projects you've done on the side. You can also list the key classes you've taken. Finally, you should definitely list any technologies and languages you've learned, such as Java, C++, Linux, etc.

As an example, compare the resume snippet below:

Education:
University of Nevada, Las Vegas, 2008 (Expected)

Personal Information:

• Captain, Intramural Football team
• Member, French Club
• Member, Student Council
• Member, Young Entrepreneurs’ Club
• Eagle Scout
• Competitive distance runner

And in contrast, look at this resume:

Education:
University of Nevada, Las Vegas, 2008 (Expected)
Major: Computer Science with focus on Web Development
GPA: 3.2 overall, 3.4 in major

Key Classes Taken:

• Data Structures (arrays, lists, graphs, trees)
• Algorithms (sorting, searching, recursion, NP-completeness)
• Databases (SQL, normalization, indexing & search)
• Networking (sockets, synchronous & asynchronous I/O)

Key Technical Skills:

• Java
• C++
• Linux
• PHP

Projects:

• Class project: Simple e-commerce site using PHP.
• Personal project: Web-based photo slideshow using Python.
• Volunteered as PC systems administrator at youth club.

As a hiring manager I'd find the second version of the resume to be much more useful.

Note however that I am not recommending that you completely purge all references to extracurricular activities from your resume. If you are active with organizations that are relevant to your profession, such as ACM or IEEE, that may be worthy of space on the page. And you should definitely list membership in academic honor societies such as Phi Beta Kappa.

Resume - Accomplishments vs. Skills

Although many resumes I see include a technical skills list, some candidates take a different path and emphasize achievements rather than skills. This approach is seen more with management and tech lead resumes, but it could potentially be used by any experienced engineer.

For instance, here is a skills-focused presentation:

Skills:

• ASP.NET: 3 years
• C#: 3 years
• JavaScript: 1 year

And here is a more achievement-focused version:

Key Accomplishments:

• Designed and implemented an e-commerce site in just six months using ASP.NET.
• Developed business logic for a highly scalable multiuser environment in C#, enabling support for up to 10,000 concurrent users.
• Refactored a site’s JavaScript code into reusable libraries, reducing file count from over 100 down to 25.

It could be argued that your accomplishments should be listed within your work experience section. However, the same could be said of the skills inventory. Hence if you do decide to have either section you should include only your most important skills or achievements to reduce redundancy.

So just how do you spin a technical skill into an accomplishment? Think less about what technologies you used and more about what you did with that technology. Why was that technology chosen? Did that choice make a difference? How exactly was the technology applied? Can you quantify the results? Can you describe a discernable outcome, either on the project, the team, the product, or the company? And what part did you play in all of this? These are all things you can list as accomplishments.

Resume Buzzword Bingo

More and more I see resumes littered with an alphabet soup of technical buzzwords, and I’m also seeing it higher up on the page. I suppose this is a natural reaction to the increasing list of skills that recruiters and hiring managers ask for, but at some point it just gets silly. In many cases people list so many technologies that no mortal person could possibly have significant experience with all of them. I call it “buzzword spam”, and it can be almost as bad as the skill set listings on H1B job postings that people complain about so loudly.

In addition to creating clutter, skill spamming is actually a risky gamble. It might indeed help you pass those pesky automated filters; however, you’ll look bad in an interview if you’re asked about those technologies you listed on your resume but which you’ve actually only heard of in passing.

Also keep in mind that you don’t need to list every single technology you’ve worked with. In fact, it’s probably better to trim the old technologies that are no longer relevant. e.g., I don’t care that you’ve worked with FoxPro, Windows 95, or VB 6. And certainly don’t put down that you’re experienced with Microsoft Word and Excel!

If you do insist on peppering your resume with buzzwords, it helps if you also list how much experience you have with each technology – e.g., 3 years with ASP.NET, 2 years with C#, etc. This keeps me from having to mentally add up your experience from the various jobs on your resume. And if you only have a basic familiarity with a technology, just go ahead and say so.

Here’s a sample resume snippet that illustrates this approach:

John D. Applicant
Las Vegas, NV

Skills:

• ASP.NET: 3 years


• C#/.NET: 3 years


• JavaScript: Basic familiarity


• XML/XPath/XSLT: Basic familiarity


• SQL Server: 3 years light experience

This format tells me exactly what skills to focus on.

Putting Together Your Resume

Writing a resume seems like it should be a straightforward exercise. After all, it basically consists of your work experience, education, and maybe an objective or summary. What could be simpler? And yet, I’ve seen hundreds of truly horrible resumes. So here are some tips.

First, keep your resumes short. A lot of people violate this rule, thinking their work experience has been so interesting or important that it merits 3, 4, or more pages. I’ve seen resumes as long as 12 pages, if you can believe it.

The reality is that no resume screener, whether it’s a headhunter, in-house recruiter, or hiring manager, will actually read that many pages. In fact, it’s been reported that most resume screeners spend no more than 15-30 seconds skimming a resume. This is because they often have to sift through dozens of resumes per day and can’t dwell on an individual resume’s details.

Hence my rule of thumb for resumes is as follows:

• New or recent grad: 1 page
  
• Experienced candidate: 2 pages
  
• Industry veteran (20+ years): 2 pages, possibly 3 pages at the executive level

Realistically, 2 or (rarely) 3 pages are the most that a reader will ever look at. Do what you must to trim your resume to this length. If necessary, you can combine your jobs from earlier in your career to a single entry. Fact is, the interviewer will most likely only want to talk about your 2-3 most recent positions anyway.

You should also emphasize the most important aspect of your resume by putting it up near the top. If you attended a prestigious school, you could put that information higher up; likewise, if you worked at a well-known and respected company, then that item should take precedence.

Finally, remove any non-technical personal information from your resume. At the risk of sounding callous, I don’t care that you were the swim team captain in high school, or that you were an Eagle Scout, or that you’ve run the Boston marathon each of the last ten years. This information has no place on a software developer’s resume.

The Vague Job Posting

Sometimes there is a vague job posting that is legitimate, i.e., not a NonJob(tm).

The hiring company might post a general or vague job requirement because they don't want to rule anyone out who might be smart but doesn't have the ideal skill set. For instance, some managers may be willing to take good Java people and train them on C#/.NET (or vice versa). And other managers might consider people who don't have any .NET but do have strong OOP experience. This is in recognition that highly experienced .NET engineers are not easy to come by. So the vague job requirements by no means directly indicate a NonJob.

As an illustration, which of the job reqs below might you consider reasonable and which would you consider a non-job?

1. Looking for.NET engineer with 3+ years of experience in ASP.NET and C#. Knowledge of HTML, CSS, JavaScript, and SQL Server required. Nice to haves include WCF, WinForms/WPF, .NET 3.5, and AJAX.
2. PHP developer with experience in the entire LAMP stack desired. Should have XML, XHTML, DOM, SAX, XPATH, DTD/XSD, XSLT. Ideal candidates will also have some knowledge of Flash and ActionScript.
3. Need experienced C++, Java, or other strong O-O developers for C#/.NET environment. We will train on the necessary skills.

Thing is, I would consider all of these to be legitimate job postings. The first two are very specific, while the third is more vague. But I can understand how hiring managers might legitimately seek each of these skill sets.

What Is a "Non-Job?"

Some candidates use the term ‘Nonjob’ to refer to Internet job postings that don’t actually have a job requisition behind them. Most commonly the listings turn out to be either H1B postings or recruiters trolling for resumes.

What are some signs that you’re reading a nonjob posting? Let’s start with H1B posts. This is where a company wants to submit an H1B candidate for a Green Card application, so they are legally required to post an ad for the job the H1B holds. Of course the company has no intention of actually hiring anyone else for the position, so the job posting will often contain a ridiculous amount of detail, listing a very specific combination of skills that very few people on earth could possibly possess.

On the other hand, a nonjob posted by a recruiter will usually appear much more genuine. It might even be based on a legitimate job req. There’s typically no sure way for you to identify a recruiter nonjob, but there are a few telltale signs that a recruiter may just be looking to pad his resume database:

• The job req is vague enough that a lot of people could qualify (e.g., “Looking for people with J2EE or ASP.NET or LAMP or Perl/Python or Ruby skills”).
• The pay, which most job postings omit, is quite attractive.
• The possible pay range is huge – e.g., 60K to 120K DOE.
• The posting stays on a job board for months at a time.

My advice to you if you encounter what you suspect is a nonjob? If it’s obviously an H1B posting, simply ignore it. Even if you’re an H1B yourself, forget it; the company has already picked someone and they are not looking for anyone else.

If the nonjob looks like it’s coming from a recruiter, there’s no real harm in submitting your resume. The recruiter will keep your resume on file, and who knows, they might contact you in the future if a match comes up. But don’t hold your breath.

Hiring for Skills vs. Potential

A commenter to my last post wondered why we don’t just hire smart people and train them on the necessary skills. After all, every new employee has some amount of ramp-up time, so why not just hire the brightest candidates, then extend the ramp up time a bit and help them learn the skills they need?

This approach certainly sounds attractive, but there are some counter arguments. For one, there is a significant cost element to having extended ramp up times and putting employees through training. However, I will put that argument aside for the moment to focus on another concern.

The bigger problem in my estimation is how to tell that someone is a good learner and can pick up new skills quickly. Basically we need to discern in an interview whether a candidate has the aptitude to easily adapt to new technologies, which is much more difficult to do than just evaluating their existing skill set.

I remember back in high school when we all sweated over taking the SATs. That’s the Scholastic Aptitude Test, which implied, nay -- claimed – to be a test of aptitude rather than knowledge. However, if you’ve taken the test you’ll likely agree that it was in fact mostly a test of knowledge and skills.

You couldn’t hope to do well on the SAT unless you had a huge vocabulary and solid math skills. If you had aptitude but didn’t have great English or math knowledge (e.g., if you attended a poor inner city school), chances were you would do poorly on the SAT. Furthermore, as I recall SAT scores were shown to be a rather weak predictor of future performance in college. Which just goes to show that testing for aptitude is hard.

Some people might say that most talented, experienced engineers can pick up a new technology in short order. That’s likely true, but there are certainly many experienced engineers who are not particularly good with the technologies they already use, and are not likely to get much better with new technologies. So how do you separate the wheat from the chaff? How do you identify the truly talented ones who may be the good learners? It goes back to the aptitude measurement problem.

One possibility is to give candidates an IQ or other intelligence test. However, HR and legal departments in most companies will nix the idea of written tests for candidates. It all goes back to liability and possible discrimination lawsuits, as IQ tests may be culturally biased. Gotta love those lawyers!

Another measure of aptitude is a person’s performance in school. Presumably if they did well in their classes they were good at learning new things. But that’s not a guarantee, as there are many people who are good at “book learning” but not so good at learning problem solving skills.

Writing software is not about rote memorization; you need a combination of analytical skills, creative thinking, and more importantly, the ability to see existing relationships and envision new ones. These are skills you learn and develop over time, and which you can’t easily pick up in school.

Having said that, I still think that hiring top students out of school is a promising approach to finding candidates with the best aptitude for learning. Unfortunately, many companies including mine do not aggressively recruit on college campuses, which is a shame. But that’s a subject for another post.

The (New) War for Talent

If you read the various recruiting blogs it becomes clear there is an ongoing competition for talent – a war, if you will. It doesn’t matter if we’re in a recession; talented engineers will always be in demand.

What does this mean to you as a candidate? It might seem sometimes there are many more applicants than jobs out there. Perhaps you, or someone you know, have been conducting an extended job search with little result. You might wonder, and rightly so -- if there’s a war for talent, why am I not seeing it?

The issue is that the job market in 2008 is significantly different from what it was in 1999, or even back in 1995. It has become a lot more stratified. Although there is still a lot of demand for technical talent, companies have become a lot more selective in their hiring.

The saying back in 1999-2000 was that if you could fog a mirror you could get a tech job. That’s not far from the truth; I recall back then how desperate my employer was in trying to get people onboard. We used to hire barely qualified people hoping they would improve and develop into better engineers over time.

The dot com bust of 2001-2004 shook out the industry and put an end to that kind of rampant indiscriminate hiring. Companies nowadays realize that in order to build and maintain large, complex systems you need solid, experienced engineers. You might be able to keep basic CRUD systems running with mediocre people, but to architect and build sophisticated, cutting edge systems you need top shelf talent. And companies are now less willing to train people or wait for them to develop and blossom.

Not only that, but since 2001 there is a whole new set of skills in demand, at least in my world. ASP.NET, C#, .NET CLR, etc. all came onto the scene around late 2001, and only a limited population of engineers is competent with these ‘current’ skills. And guess what – in addition to my company, all the other companies that use .NET are trying to hire those candidates as well.

So to bring this discussion back around to you, the candidate – it means that if you have the right skills, and can show that you have those skills, you will be a hot commodity. However, if you don’t have the necessary skills, you might find the market to be just as cool as it was back in 2001 after the dot com bust. So you need to do what you can to make your skills current and relevant.

And what does this mean to the hiring companies? It means that finding (and keeping) the right talent is now more important than ever, and perhaps more difficult than ever. In many ways the competition resembles the 1999-2000 environment, only now you’ll have to be more selective, and you’ll need to make a stronger case as to why candidates should work for your company.

After the Interview

Say you’ve passed the interview and snagged that offer. Now what?

As I noted earlier, you will likely receive a verbal offer first. Many companies will want to know whether you’ll accept the job before they’ll put together a written offer (which is kind of strange, like asking a partner, “Hypothetically -- if I were to ask you to marry me, would you accept?”)

The verbal offer stage is where you should negotiate for more pay, vacation time, etc. Sometimes the offer is firm, but often there is some flexibility on the hiring company’s side. This is also the time to discuss relocation benefits, which are usually negotiable.

If you wait until the written offer arrives to try and negotiate, things become much more difficult. That’s because most likely someone in the company (i.e., your advocate) had to make a case for hiring you, and several senior people in the company have signed off and given their approval on the offer. If you then demand a higher salary they may have to go through the entire all over again, and your advocate risks their credibility and good will with the top brass.

Assuming that now you have worked out the details and accepted the offer, what’s next? Why, you should inform your current manager of your decision to resign, and you should make every effort to give two weeks’ notice. Even if you hate your current job and detest your boss, you should give them the advance notice as a professional courtesy. You should never burn bridges, as you may very well encounter these people again in your career.

When you do give notice, you should be aware that two things may happen. One, it’s entirely possible they’ll have security escort you out the door immediately. Personally I’ve never seen this happen with a voluntary resignation, but I wouldn’t be surprised if it did. Hence you should make sure to remove personal items from your desk and any information from your computer before you give notice. And if you do get escorted out, just treat your two week notice as a much needed vacation.

The other thing that may happen is that your company may come back with a counter offer. Sometimes they may wait until your two weeks are almost up to pull this on you. But career advisors are nearly unanimous on this point – do NOT ever accept a counter-offer. It won’t change the things you were unhappy about at your current company, unless your salary was the only issue. And even if that was the case and is addressed by the counter offer, your boss will immediately start looking for a replacement for you.

Make no mistake about it, once you accept a counter offer you will be tagged as disgruntled and disloyal, and you are living on borrowed time. You will most likely be out of that job within six months, one way or another.

More On the In-Person Interview

In my interviews I typically ask a combination of ‘soft’ questions and technical ‘trivia’ type questions; I also ask the candidate to write some code or web markup. Some candidates are put off by this, assuming that their stellar resume should speak for itself. But I have found that a lot of people who can “talk the talk” can’t “walk the walk”, and stumble badly when asked to write actual code. Part of that can be chalked up to nervousness, but after doing a number of interviews I can tell when someone is a BS’er – and a coding exercise can flush out the pretenders from the contenders.

Mind you, these exercises I speak of are not rocket science problems. They are simple exercises that a good developer should be able to complete in a few minutes – e.g., looking for a character pattern in a string, for instance, or coding up an HTML table.

If you are presented with a coding or other exercise in an interview, follow this advice:

1. Relax and take a deep breath, and make sure you understand what the interviewer has asked for. Ask him to repeat the question if necessary.
2. Don’t freeze up; nothing’s worse than someone panicking and turning into a statue. Ten seconds of silence can seem like an eternity in an interview. It’s better to think out loud, as it displays your thought process.
3. Don’t be afraid to ask questions. The interviewer will likely be willing to clarify the question and provide course corrections, or even provide hints. It’s only the rare sadistic interviewer who’ll sit there with crossed arms and furrowed brow and refuse to help out the candidate.
4. If you are rusty with a particular programming language’s syntax, ask if you can use a different language or write pseudocode.
5. If you feel that you truly cannot solve the problem, just say so up front and move on to the next topic or exercise. It’s better than spending ten minutes spinning your wheels and looking foolish.
6. Sometimes the interviewer will ask you whether you prefer “Approach A” or “Approach B” to solving a problem. Most of the time there is no ‘correct’ answer; they just want to see that you have thought about the problem in the past, and that you can discuss it in an intelligent manner. e.g. – Waterfall vs. Agile development processes.
7. If you are presented with a ‘Microsoft’ type of silly logic question (which I personally detest), simply talk out the problem verbally. e.g.,”How would you get 500 kerfoozles into a diddlysquat?” Answer: “Well, let’s start out by agreeing on the average size of a kerfoozle, and the methods available for transporting them…”
8. Given the types of pressures in the above situations, if you are offered water at the beginning of the interview you should accept it even if you’re not thirsty. You might need it desperately later on.

The In-Person Interview

As I noted previously, the actual in-person interview may consist of a series of one-on-one interviews, a group interview, or some combination thereof. Here are some tips.

1. If you are asked a question and you don’t know the answer, don’t guess. You might get lucky and answer correctly, but you’ll look foolish if you confidently blurt out the wrong answer. The only exception to this rule is if the interviewer actually asks you to take a guess.
2. You are not expected to know the answers to 100% of the technical questions. Some interviewers will take perverse pleasure in asking obscure questions, feeling superior in that they have some knowledge the interviewees don’t. But more likely, in asking tough questions the interviewers are just probing the limits of your knowledge.
3. Many interviewers will ask you the dreaded “Your biggest weakness” question. Have an answer ready, but avoid the cheesy “I work too hard” ones that will cause the interviewer to groan. Instead, try to think of a mild weakness that you are “working hard to overcome”.
4. Keep your answers short – no more than 20-30 seconds or so. The interviewer will prompt you if they want you to expand on an answer. Nothing’s worse than an interviewee who rambles on for 5 minutes describing the deepest and most boring details of the payroll system they worked on ten years ago.
5. Maintain eye contact, but don’t keep a steely gaze fixated on the interviewer; you’ll come off as a stalker or psycho. Look away every now and then.
6. Don’t get overly chummy with the interviewer; stay professional. If they start BS’ing or shooting the breeze, nod and acknowledge them briefly, but don’t get drawn into a deep discussion about sports, movies, or whatever, and above all don’t let your guard down. Your time is limited, and you want the discussion to stay focused on the job and your qualifications.
7. Try to smile once in a while – it helps people connect with you. But don’t force it.
8. Remember, the interview is also an opportunity for the company to sell itself on you. Don’t be afraid to ask why you should work for the company. If you want to approach it more politely, ask the interviewers what they like most about working there.
9. Don’t ask the interviewers how you performed in the interview; that can be extremely awkward.
10. If the interviewers ask legally off-limits questions (e.g., age, marital status, ethnicity, etc.), just tell them that you can provide that information later if necessary.

The Recruiting Process

Our company’s recruiting process is similar to most other tech companies, with a few differences. Roughly it proceeds as follows:

1. We send out a job requirement to several contingency-based recruiting firms. Admittedly, the job req is often general and vague, as we want to cast a reasonably wide net.
2. The recruiting companies send us resumes, typically sourced from the job boards or other places such as LinkedIn. The resumes have been only lightly screened at this point.
3. Our HR screens the resumes, perhaps in conjunction with a tech manager. The level of filtering here is again very light, contrary to what some people claim about “HR Drones” rejecting perfectly good candidates.
4. The resumes are distributed to various engineers to conduct 30-minute phone screens. This is to filter out the truly clueless candidates, as well as to roughly identify what position the candidate might be suitable for. This interview will be mostly technical in nature – short questions and answers.
5. If the candidate passes the phone screen, they are brought in for an in-person interview. At most companies this consists of 4-6 one-one-one interviews of between 30-45 minutes each; it may also be a single group interview with several managers and engineers, or a mix of the two types.
6. Some companies may require additional rounds of interviews, though we usually do not. For instance, an additional round may be required when we interview a candidate for one position, but realize they may be a better fit for another position that requires a different interview panel.
7. If we like the candidate, HR will make a verbal offer to see if they are interested. If they are, we’ll follow up with a background check and then a written offer.

Regarding the background check - more and more companies are doing it now. Usually it’s contracted out to a third party, and you’d be surprised how thorough it can be. They can check your educational background, criminal history (if any), your credit history, and of course your employment history. They may even confirm your salary at your previous companies. I’m not sure how they do it, but I know they can, as I saw it done in a copy of my own background report.

Basically all this means you should not lie about your education or salary history, EVER! I’ve seen more than one offer retracted due to the candidate failing their background check.

General Tips on Interviewing

As a manager who conducts lots of interviews, I’d like to offer some general advice to job seekers out there. This is targeted mostly at .NET engineers, but much of the advice could apply to most techies.

To give you some background, I have close to 20 years of experience in the software field, and currently focus on ASP.NET and Windows technologies. I have sat many times on both sides of the interviewing table -- probably 20+ times as a candidate, and close to 100 times as an interviewer. I estimate that I have screened some 500+ resumes in total.

So here are some points I’d like to get across:

1. The job market, as of Spring 2008 in Southern California, at least for experienced .NET engineers, is still very hot. I can’t speak for other technologies or other areas. Of course, if you don’t have the skills in demand, the market may still seem quite slow.

2. Resumes do not need to be longer than two pages. Typically a screener will only skim a resume for 15-30 seconds on average, and won’t look past the first couple of pages. I’ve seen resumes as long as 12 pages, which is patently ridiculous – no one will ever bother reading all that.

3. Resumes are only a means of getting in the door; don’t count on them to be your main selling approach to the company. The in-person interview is where the hiring decision is made.

4. If you list a technology on your resume, make sure you know it, as chances are good you’ll be asked about it. i.e., don’t list ‘XML’ and then tell me you don’t know the difference between DOM and SAX.

5. Don’t bother putting “References available upon request” at the end of your resume; it’s not necessary.

6. Before you go in for an interview, do a practice interview, perhaps with friends. Most people are pretty bad interviewees, most likely since they only do it every few years.

7. Show up to the interview on time. The interviewers’ time is valuable.

8. Always wear a (dark) suit to the interview, even to a company with a casual dress code. Dressing down for an interview shows disregard for the interview process. And don’t think you can get away with it just because you’re special.

9. Don’t play the game of refusing to divulge a salary requirement. You’ll have to pick a number sooner or later, so just say what it is. Most jobs have allowable pay ranges, and if your requirements put you outside the band, I need to know.

10. Prepare a list of questions for the interviewers ahead of time. It doesn’t look good if you say you have no questions.

11. Thank-you letters are not necessary and will not affect the decision one way or another. Chances are the hiring decision has already been made shortly within an hour after you leave the building.

12. If you don’t hear anything back from the company within a week or so, it means they’re not interested. Most companies nowadays don’t bother with rejection letters, either out of shyness of out of fear of liability. There is ZERO chance that they’ve accidentally forgotten about you.

I will expand upon many of these topics in future posts.

Welcome

Welcome to my blog. I am an 18-year veteran of the software development industry, and in my vanity I thought I would share the knowledge and insights I’ve gained over the years on various topics related to this field. My focus will be on management, recruiting & hiring, interviewing, software development, and other things of the ilk.