You wouldn't think I'd be advocating hanging on to a job you don't love, but in today's economy it may make the most sense. In the latest issue, #6, of PragPub, the free magazine from Pragmatic Bookshelf, I talk about how to make the most of the time you're spending in a job that you have to keep. It's also the first in my new monthly column for the magazine.

PragPub is published every month in three different formats, so you can read in the format that works best for you. I admit, I print mine out. Sorry, trees!

Finally, from last month, there's an article with me in the blog Interview Mantra.

You're out looking for a job, and you want an edge over the rest of the candidates out there. Your experience in open source should count for something, right? It just might, but the key is how you sell it to the person who reads your resume, and to the interviewer in an interview.

First, think of each project as a freelance job that you've worked on. Just as different freelance gigs have varying sizes and scope, so too does each project to which you contribute. The key is to not lump all your projects under one "open source work" heading.

Explain in your resume the contributions you've given to each project. Don't assume that someone will understand what your project is, or immediately grasp the importance of what you've done. For example, on my resume I might have:

Perl programming language (www.perl.org)

Created the prove command line testing tool. prove allows the programmer to interactively and selectively run tests in a test suite without a Makefile, making test-first development much easier. I wrote prove in 2005, and it was immediately embraced by the Perl testing community. It has been part of the core Perl distribution since 2006.

As with anything you put on your resume, explain what you did and why it was good that you did it. The only difference between project work and a "real" company is that instead of explaining the value to the company, you're explaining the value to the project or to the users.

Wags familiar with prove may say "But all you did was write a couple hundred lines of code around the standard Test::Harness module." The key to someone looking to hire me isn't what I did, but why I did it, and that I took the initiative to do it at all. I saw a need for a tool, created it, and released it to the world, to much appreciation.

So what have you done to contribute to help open source projects? It doesn't have to be as big as a deal as you might think. Submitted a code patch? Explain the bug, how you fixed it, and what you did to get the patch into the system.

As with any project, make sure you explain what the project if there's any chance someone reading might not be familiar with it.

(Thanks to Esther Schindler for asking for comments in her article "What To Include In Your Open Source Resume", which prompted this posting.)

I've been hanging out at JavaRanch.com lately, after I was the guest forum contributor a few weeks ago. The Java market seems to be glutted with programmers from what I read, and there's a lot of interest in using open source to boost one's résumé. One poster asked for specifics of how he could use open source projects to help his career change to one of programmer. Here's what I told him (with some minor edits):

The key to getting into open source isn't to find a project to contribute to. What you want to do is contribute to a project you already use.

What open source projects do you take advantage of every day? I'm no Java expert, but it seems like half of what the Apache Foundation is driving these days is Java-based. Do you use Ant? Struts? Jakarta?

How about non-Java projects that you use? Do you use SpamAssassin? It's in Perl, so would give you a reason to also learn Perl. Any Apache modules you use? You could learn some C.

How can you contribute to those projects? It doesn't have to be just contributing code at first. Hang out on the mailing lists and provide answers. Update support wikis or contribute documentation. I know that on the Parrot project, a large amount of contributor time goes just to maintaining the tickets in the bug system. Anything you can do to pitch in, do it.

Start with joining the appropriate mailing list for the project, or monitoring forums. Hang out in appropriate IRC channels. Listen to what people are saying. Make yourself known as being someone who is willing to pitch in. And then do the work people are saying needs to be done.

Go into it with the goal of contributing to the project, and not of improving your career. When you take care of the first part, the second part will come naturally.

Good luck!

Any other suggestions? I'd like to turn this into a sort of standard page that I can point people to when this question comes up.

Next time you’re at the grocery store checkout lane, take a look at the magazines and see what they do to get you to read them. There’s a valuable lesson there for your resume.

We geeks love our toys. ThinkGeek has led an industry on new toys, but many of us revel in our old toys as well. The quest to find the last comic in our collection, the last Star Trek model, or an old first edition Heinlein novel can be pretty compelling.

I'm a fan of Nick Corcodilos. His book Ask The Headhunter was one of my inspirations to write Land The Tech Job You Love. His thoughts on why you should refuse to reveal your salary history are inspiring, and underscore the importance of keeping the relationship with a potential employer equal to both parties.

When Nick asked if I'd review his draft of his new book How to Work With Headhunters, I jumped. No surprise, it's a great book, and I recommend it. It's a straightforward, no-BS guide to how to get the most out of the relationship with a headhunter, which can be tricky. The job seeker is at a disadvantage because she only seeks a new job every few years, so this relationship can be hard to manage. Most importantly, Nick spells out what headhunters do and don't do, so you understand your role. He also explains how to tell if a headhunter is a pro or a waste of your time.

The ebook is on sale at asktheheadhunter.com, and you can get $10 off with the discount code "tenoffblog". Tell the Headhunter that The Working Geek sent you.

Jeffrey Thalhammer, who last wrote for The Working Geek on "On breadth vs. depth of technical knowledge", has strong opinions about resumes and cover letters:

Last week, my wife attended a "resume bootcamp" seminar. Among other things, I asked her what the seminar recommended for cover letters. According to the speakers at this seminar, the resume is far more important the cover letter, and they de-emphasized letter-writing skills. I was shocked!

In my experience with hiring, I'm far more impressed by a compelling and concise cover letter than a long and esteemed resume. To me, a resume is like a PowerPoint presentation and I don't mean that in a good way. It is usually a dust-dry list of bullets and broken sentences that lack any texture or color. Reading a resume is never fun or even interesting.

On the other hand, the cover letter is an opportunity to tell me a story that holds my attention and helps me understand you. As an expository document, rather than a declarative one, your cover letter can leverage all the literary devices of your language: cadence, phrasing, metaphors, symbolism, vocabulary, etc. These are what make your cover letter interesting, and make me want to talk to you.

A good cover letter indicates your ability to communicate with others, and in the software industry, it also indicates your ability to write code. If you can't express yourself elegantly in your natural language, then you probably can't express yourself elegantly in code either. I realize this judgment is harder to make with those who don't natively speak your language, but fundamentally, I believe it is still true.

This doesn't mean that you should write a five-page cover letter for each job -- economy of words is still important. Consider writing your cover letter as if you wanted to thrill the reader with a summary of the exotic vacation you took last month. Tell them what you did, why you did it, how it affected you, and why the reader should be interested in your story. Make it exciting and fascinating to read. Show me your energy, your style, and your personality. And of course, be professional too.

In their defense, the speakers at the resume bootcamp were all HR recruiters. Often times, recruiters are given only a list of keywords and skills associated with a job, and instructed to harvest as many compatible resumes as possible. From that perspective, I can understand why they would put so much more emphasis on the resume. But once the resume gets to a hiring manager, I think the cover letter becomes a much sharper image of the candidate. So in the end, you really need to have the total package: a great cover letter and resume. But don't neglect one for the other.

A note for hiring managers: If your HR department does not pass along the candidates' cover letters, you're not getting the whole picture on your job candidates. Ask your recruiters to pass along the cover letters and all the correspondence associated with any resume they submit to you. You can learn a lot by looking at how a candidate interacts with recruiters in the early stages of the hiring process.

Jeff Thalhammer has been specializing in Perl software development for over 10 years. He is the senior engineer and chief janitor at Imaginative Software Systems, a small software consultancy based in San Francisco. Jeff is also the creator of Perl-Critic, the leading static analysis tool for Perl.

I found an article that claimed that US job hunters only spend forty minutes per day looking for a job. Maybe that's forty minutes checking job boards, but that's only 10% of an 8-hour work day on your job.

You may think "I don't have a job!", but you do. When you're out of a job, your full-time job is to find your next job. Treat it like a 9-5 job. No matter what you do, don't sit around and do nothing. Don't allow the gift of time you've been given to find a job be squandered by doing nothing.

There are three big reasons to treat your job hunt like a job:

• You'll increase your chance of success

• You'll fight off the depression of being jobless

• You're going to get asked about it in interviews

Let's look at each in detail.

You will have more chances of success

You may think there are no jobs to be found, but there are. You just haven't found them yet, probably because you're looking in the wrong places. Checking job boards doesn't count as job hunting especially since only 7.5% of jobs are filled through job boards. You have to get out and talk to people.

Talk to everyone you can. Even if you've exhausted every source you can think of, try for just one more. Look back through your hunt logs and find a target you haven't checked in a few months. Wherever you pursue, look for a new option you haven't explored yet. You can't get a job from a contact that you don't make.

One excellent source of information you may not have considered is your local Chamber of Commerce. The Chamber of Commerce is a group of businesses organized together to help each other. The website will probably have a directory of members and job listings. More important than these sources is the opportunity to talk to the Chamber staff themselves and find out what they may know about the needs of companies in the area.

Don't just call or email the Chamber. Show up at their office, in person, and talk to someone. You're far more likely to be remembered when you meet someone than you are just from email. Be sure to show up with a number of copies of your resume, and some of your personal business cards, so that you can leave some if it's appropriate.

Just keep pushing. Keep making one more step, checking one more idea. I know it can be disheartening, but anything is better than doing nothing. Chance favors the prepared mind, and the more time you spend working, using the Internet, the more likely you are to stumble across the job you need, and maybe even one you will love.

You fight off the depression of not having a job

Sitting around on the couch watching bad TV is a great way to aggravate your worries about not having a job. Playing World of Warcraft or napping all day may feel like a little vacation, but they're not going to get you that next paycheck. Don't give in to the temptation.

Treat your days without a job as if you do have a job, and your job is to find a job, and improve your skills. Get to the office at 9:00, even if your office is just the kitchen table, take lunch like you normally would, and then keep working until 5:00.

What can you do besides look for jobs? Take advantage of the time off to start all those projects you've just never found the time for. You've been given the time, so use it!

• Start a blog. Write about what you're learning in your time off. This becomes a record of your progress, to help you remember that your time's not been wasted. It's also a record that a future employer will see when he Googles you after he's seen your resume. Finally, it helps you practice writing, since you're in a field where the written word is crucial to future success.

• Teach yourself something new related to your job. Always wanted to learn a new programming language, but you told yourself you never had the time? Now you have the time. Want to learn a new Linux distribution? Clear out a spare partition on your home machine and get to it. Maybe you're a project manager who wants to learn more about programming. Get going, and then blog about it.

• Take a business or technical class, maybe at your local community college. Community colleges are a fantastic value for your dollar for introductory classes. My local community college charges only $77 per credit hour. Start with business classes before you worry about the technical. You can always learn technical skills on your own. Business knowledge is important to any employer. Take a class in accounting or marketing, or a good business overview if you've never taken one before.

• Take an unrelated class in something fascinating if you haven't found anything appropriate technical or in business. Maybe you'd like an introduction to automotive repair, or to get your feet wet in conversational Japanese. My local community college has programs in criminal justice and fire protection, both of which I'd love to find out more about. Whatever it is, learn something. Then blog about it.

• Contribute to an open source project. Somewhere you're likely using some open source software. Learn about it. Learn about the culture surrounding it. Find out what its needs are. Find out what kind of help they need. Then provide that help. You don't have to be a programmer to contribute to open source. You can provide documentation, answer user questions, respond to bugs in the bug tracker, and so on. Blog about it.

• Contribute to Wikipedia, or a wiki related to a project of interest. Wikipedia is an open source encyclopedia, and can always use improvement. There are tons on Wikia. Find a topic related to your job, not arguing about Jabba the Hutt's family history. Then blog about it.

• Frequent mailing lists and bulletin boards related to your area of expertise. See what you can learn, and who you can help. Blog about the most interesting ideas.

• Go to your public library. Libraries are amazing storehouses of knowledge. The chances of finding something fascinating and enriching are high!

• Read read read! Find something new to inspire you. Blog about it.

You're going to be asked about it at interviews

Chances are that an interviewer who sees that you've been out of work for a while will ask about your job search. She may even specifically ask "What have you been doing in the four months since you got laid off?" How will you answer this question?

You could answer:

Well, I've gone on a few interviews, and reading Monster every day, of course, but, uh, that's about it.

which is hardly inspiring, or you could answer:

I've gone on some interviews, but those weren't very encouraging. I've been investigating companies in manufacturing, because I feel like that's where my heart lies. In the downtime, I taught myself Python and I wrote a tool to analyze the RSS feed coming from Simply Hired using Python. The source code is in my portfolio of sample code that I brought today.

or maybe

In the downtime, I've been monitoring Stack Overflow for SQL Server questions, trying to help with the problems that novices post. It's kind of fun because I know how to handle most of the problems, like optimizing indexes, but some of them are stumpers so I go dig and find the answer. The latest was a problem someone had with...

or how about

... and I've been hitting the topics that I've never had time for. The accounting class I had my eye on was full, so I'm in my fourth week of a class in metallurgy. Plus, I've been checking out cookbooks on German cooking from the library, and I practice a new dish every day for lunch.

Imagine how a hiring manager is going to be impressed with your drive and initiative! In all these examples, you're showing how you're making the most of your down time, improving yourself and maybe even helping others. That's the kind of drive that you can't train into someone.

Keep thinking like you're working

Stick to the notion that you have a job. Keep a regular schedule. Work at your job of finding your next job. It can't help but improve your chances and get you back on someone's payroll.

For those who have been out of work, what do you do during the day to keep yourself active and working on the job of finding a job?

The phrase "shameless self-promotion" makes no sense when you're talking about your career.

"Shameless self-promotion" implies that there should be some sort of shame in letting others know about what you've done, and nothing could be further from the truth. Indeed, it's the only way you can be sure of getting the message out.

Have you ever had a garage sale? Did you put up a sign pointing to your garage sale? Or did you hope your neighbor would put up a sign for you, thinking "It's a good garage sale, people will tell their friends about it?" Of course not, because you knew that it was important that people know about your garage sale. So too it is with your achievements at work.

Techies seem to believe that if they do good work, they'll be rewarded. Unfortunately, "If you build it, they will come," only works in fantasy movies.

At work, your job and your career rely on the people above you in the company knowing what you do. Part of your job as employee of You, Inc. is to make sure that others know what you do, and how awesome you are. Your awesomeness may not be self-evident, or may not be understood by the people that matter. Say you've been using a new editor plug-in that helps you navigate source better, and makes your job easier. That's a cool thing you've done, because there are plenty of people out there who would write code in Notepad. You need to let your boss know about it, and keep track of it for yearly review time. It may well be worth putting on your resume, too, for your future self-promotion when you go to get a new job.

Aside from your career, if you're doing anything in open source and you want people to use your project, promoting the project is as important as writing solid code. Without users, your project is pointless. If it's a conference or meeting, that needs promotion even more. See my post on Perlbuzz "How to announce an event, or, awesome is not always self-evident" for more on the open source and conference angle.

Finally, for more on keeping yourself employed and boosting your career even in the middle of a recession, please join me and Chad Fowler for our webcast "Radical Career Success in a Down Economy" on July 1st. You'll need to register in advance. Chad and I are putting together as much as we can into our hour-long time slot. Chad's excellent new book, The Passionate Programmer, is also where I stole the idea of "your awesomeness is not self-evident", for which I'm eternally grateful.

For Father’s Day 2009, I’d like to take you back to 1984 and how I learned a valuable lesson in life and work from my father.

Geeks like numbers, right? Here are two numbers for the job hunting geek to remember.

A reader of Land The Tech Job You Love wrote to ask:

I have been searching for this type of book for years now. One question, as I'm only on page 75: How does a contractor make his resume appealing to a hiring manager?

I do NOT want to contract, but in DC, it seems to be the only way to either get a job or get a foot-hold into a long-term opportunity. But I hear from so many hiring types that they hate "job hoppers". But I'm not. I want and crave a long-term full-time position.

How do I address that?

Exactly how you just did it.

Put it in your cover letter. "I've been a contractor out of necessity for the last two years, but I want a long-term full-time position where I can set down some roots with the company. I think that WangoTech can benefit in the long-term from my skills as a ..."

Friday's posting about balancing the value of learning specific technologies and following technologies you enjoy got Jeffrey Thalhammer thinking about depth vs. breadth of knowledge.

Whenever my colleagues and I discuss our career plans and the job market, someone always asks me whether to learn programming language X, or operating system Y, or framework Z. But I like to point out that time spent learning some new skill is also time not spent honing the skills you already have. And in my opinion, it is both more lucrative and more enjoyable to be a master of one craft, than to be mediocre at several of them.

This is because I've noticed that those who are the best in their chosen fields are always fully employed and highly compensated. Especially during an economic downturn, employers become more selective about who they hire. So when they go looking for a candidate with a particular set of skills, they want to choose the person who is strongest with those skills -- not the person who has the most different skills. And employers are usually willing to pay a premium for top-notch talent, if they can find it.

I've been on the hiring side of the interview table enough times to know this. When a job candidate shows me they have mastered one technology, it also demonstrates to me that they have the potential to master others. But having partial expertise in many technologies may only prove that they own a lot of O'Reilly books. Truly mastering any technology requires a great deal of patience and dedication, and those traits are far more valuable to the team than being able to write code in 16 different languages.

Having said all that, I do acknowledge there is a real tradeoff between the depth and breadth of one's technical skills. Not all job candidates are created equal, and it just isn't possible for everyone to be the "best" in something. I'm sure there is a sweet spot where you can optimize your employability, and this doesn't mean that you should completely ignore other technologies. The industry is constantly evolving so you must stay up-to-date, and learning a little bit about other technologies can give you a fantastic new perspective on the those you already know well. And of course, this all assumes that you actually enjoy the technologies you're working with. If you don't enjoy them, then by all means, go learn some new skills.

But if you do enjoy the technologies you work with, then I urge you to consider mastering those technologies before going off to learn some new bag-of-tricks. To be sure, the road to mastery is long and difficult. It is fraught with frustration and can be boring at times. But it is also challenging, exciting, and deeply rewarding. In the end, I believe it will lead you to a much happier and more prosperous career.

I'd rather be the first-pick candidate for just one position than the second-pick for several.

Jeff Thalhammer has been specializing in Perl software development for over 10 years. He is the senior engineer and chief janitor at Imaginative Software Systems, a small software consultancy based in San Francisco. Jeff is also the creator of Perl-Critic, the leading static analysis tool for Perl.

A reader who wishes to remain anonymous wrote to ask:

I'm a programmer from the Philippines. I'm kind of a latebloomer since I didn't take up Computer Science or a similar course in college, but I learned programming on my own. I tried to save money so I can buy a couple of books (although I would love to read more), so I can continuously learn software design and development. For almost two years now, I've been landing jobs in companies that really don't have good processes for developing quality software. I have recently started a job. I'm not an expert, but I know when legacy applications have been built by engineers that also aim to produce quality software. The applications uses an object-oriented programming language, but all of them looks procedural. I still want to continuously learn and be a good software craftsman someday. Should I leave and apply for another job in which I think there is more potential to learn great software development processes?

Thanks for writing. Let me preface my suggestions with the caveat that they're from the perspective of a programmer in the United States. I don't know how applicable they are to business life in the Philippines. You'll have to look at them through the lens of your own culture and understanding.

First, that you are wanting to improve yourself, to improve your skills, to improve your job prospects, means that you have the drive that will make you a better employee and programmer. Being able to write good software is only half of what it takes. The other half is having the drive to apply those skills day in and day out. (The third half is being able to be part of a team.)

It's good you have that drive, because it sounds like you're going to have to do much of the learning you want on your own. I would not rely on an employer to teach those skills to you. If your only reason to leave your current job for another is to learn better software development techniques, think twice. Chances are, the company you go to will have the same problems, perhaps with a different flavor, as your current company.

Instead, keep reading constantly. Read books like The Pragmatic Programmer by Hunt and Thomas, and Code Complete, 2nd ed. by McConnell. Read websites like StackOverflow for comments and ideas on how to be a better programmer. There will be much to sift through, but that's how it goes.

Apply those skills by working on projects outside of work, preferably open source projects. Working on open source lets you work with other programmers around the world who have the same drive you do. You'll learn and practice, while creating code that you can bring to your next interview to show as an example of your programming skills.

You may also want to try to bring some of these ideas to work with you. As you learn how to write great documentation, apply it to your daily life at work, even if nobody else in the company does. When you learn about test-first development, use it as your software methodology, even when you're the only one who does. You'll have better code, better projects, and people will notice. You'll be leading by example.

Finally, don't let the bad code get you down. The world is filled with it, especially at work, and it's just part of life as a programmer. Consider it a test bed for your refactoring skills.

If other TWL readers have suggestions, I'd love to hear them in the comments below. Good luck!

A portfolio of your work is a great way to show at the job interview that you are able to produce work that the hiring manager wants. Anyone can make claims as to his skills and abilities, but producing tangible evidence of those skills makes it clear, and reduces the risk for the interviewer. Bringing a portfolio also puts you above other candidates who don't.

For programmers, code samples are the most obvious work product to bring, but what about sysadmins? Jeffery Land writes:

I was curious about what you suggest for a systems administrator to bring in a portfolio? Most of the work revolves around resource management and troubleshooting issues. At the end of the day this pretty much just leaves you with the experience and nothing you can really point to. I've been putting together a blog with my experience that I point out to potential employers but that's pretty much that best I've been able to come up with for a sample.

There's plenty you do that has a trail. I'd start with just about anything you've created that gets put on paper:

• Network diagrams
• Policy manuals
• Documentation
• Checklists
• Project schedules
• Training materials
• Budgets

You can also include electronic files and code:

• Significant shell scripts
• Configuration files

Before you snicker at how silly a config file might be, consider the research and care and feeding that goes into it. For example, tuning PostgreSQL's memory and disk usage can be a huge challenge. My postgresql.conf files at work have been tweaked and tuned and comments explain why different settings are set as they are. Some places have links to pages that give the reasons for each parameter's value. It shows the history and reasoning behind it all.

One caution, though, is that while these documents and files are great evidence of your skills, they may well be considered confidential by your company. You certainly don't want to include any proprietary information or passwords in your portfolio. You should plan on leaving your portfolio at the interview, and don't want to say "I can only leave certain documents."

Whether or not you can get existing work products, Jeffery's blog idea is a great one. It allows him an easy way to show that he has experience and know-how, even without a final work product to show. Take a look at his blog entry called "Configuring DNS Zones in Core", where Jeffrey explains configuration details for DNS under Windows. He's created a helpful resource out on the net that will likely improve his blog's Google page rank, and anyone checking him out online can get an idea of his sysadmin skills.

Your portfolio is a powerful selling tool at the interview, and every techie can create one, no matter the type of work she does.

My friend Casey West got laid off the other day, and he wrote a great blog post about it. Casey’s post tells about how he handled it, and his advice for others in his unfortunate situation. I especially like how he discusses that after a layoff, you are effectively a security risk, so understand the company’s handling of you.

Random Manager posts about uncovering disturbing background about a company when researching before pursuing an opportunity:

It may not bother some candidates that a company’s executives are members of a cult that is popular with certain Hollywood celebrities. However, when there is evidence that principles from the cult are being used as management tools within the company, that’s a clear sign to run, not walk, from that opportunity.

While finding out that the company may be run by Operating Thetans makes for a good horror story, the reality doesn't have to be that creepy to make the research worth your while. When you go researching your potential future employer, I suggest looking for people who are part of the company, and find what they have to say.

Maybe you'll find a former sysadmin who blogs openly about how things go at the company. What if the IT department is in the middle of political upheaval over whether to move to Oracle or stick with PostgreSQL? Perhaps the company has had trouble hiring developers, and you'll want to ask about that at the interview.

No matter what you find, or don't, the potential goldmine of information available about your prospective employer makes some online research well worth the investment of time.

A recent post on The Daily WTF discusses a company where they employ The Receptionist Test. The hiring manager has the receptionist stage a tech support problem and asks the candidate, waiting in the lobby for his or her interview, for help. One guy tries to help with a document that won't print, but doesn't realize the printer is off, and so on.

While tricks like this may not be common, there's a reception test that you run into every time you interview. Every interaction you have with everyone in the company is part of your interview that could have positive or negative effects, and the receptionist is the first candidate. The receptionist comes into contact with hundreds of people every day, and is likely tuned into observing people as they pass through the doors.

Whenever I have an interview, the first thing I do after showing the candidate out is ask the receptionist "What did you think? Any comments?" Usually I'll get something bland like "He seemed nice, I like that car he drove up in." Other times I get more interesting comments like "He took a long time to fill out his application. He spent a lot of time on his phone while he was writing, and didn't seem like he was very interested in the interview." or "It must have been a long trip, 'cause he practically ran in and asked for the bathroom." Those specific comments don't affect much as far perception, but it gives an idea of how you're constantly on display.

How you treat the receptionist speaks volumes about you. Were you polite? Did you say "please" and "thank you"? Or did you just grunt and drool before bothering to put on your Happy Interview Face? The receptionist, and those around you, will know.

It might not even be the receptionist who notices your behavior. Maybe that guy in a suit sitting in the lobby isn't another interview candidate, but the CEO waiting for the CFO to go to lunch. I've even sat in the lobby myself before interviews observing the candidate.

Don't make the mistake of thinking that your scrutiny starts when you step into the interviewer's office. You've been on stage well before that point.

I've been reading a lot of Stack Overflow lately, especially the questions related to interviewing and job hunting. It's making me a little sad.

So many of the questions seem to be from people looking for silver bullets that are The Right Way to do things. There are questions like:

• I'm supposed to interview someone for a job tomorrow. What should I ask?
• Should a web designer interview an HTML jockey?
• What's a good practice task for junior developers in an interview?
• What is the best website for .NET interview questions?
• What kinds of code would you want to see in a portfolio?

Asking "What will a prospective employer want to see in my code portfolio?" is like asking "Where should I take this girl on a date tomorrow?" There's no way to answer. We can answer in vague terms, like saying "Put your best code in the portfolio" or "Don't pull a Travis Bickle and take her to a porn movie," but that's about it.

These people seem to be looking for definitive answers where none can exist. Don't fall into that trap yourself. Treat every job in your job hunt as a brand new case, with unique requirements and a unique set of ways that the job can use your skills.

In a job interview, it's crucial you don't pretend to know things that you don't, but you don't have to just say "no, I don't know about that." Here are three responses that are better than "no", in order of preference.

1. Discuss something you've done similar. "I haven't used LDAP, but back in 2006, when I was at Yoyodyne, I set up and administered Active Directory for a 2,500-person company.

2. Show that you're at least familiar with the name. "No, I haven't. Are you doing some sort of enterprise-wide directory integration?" You're showing that you have some understanding of how it's used, and getting more information and it may turn out that you have a different, similar experience, and can turn this into Answer #1 above.

3. Ask what it is, and how it's used. "I'm sorry, no, I haven't even heard the term. What is LDAP, and how are you using it?" You'll show interest in learning more, and may find out that it's similar to something you've done before, and can upgrade your answer to Answer #2 above.

Please don't use the clichéd answer "No, I don't, but I'm a quick learner!" It's good to try to turn a negative into a positive, but "I'm a quick learner" is meaningless because anyone can say it. Use one of the three above.

Finally, don't think of it as a pass/fail quiz and worry that you're doomed for not knowing. I once asked a candidate, out of the blue, if he knew anything about LDAP, because I had been thinking about it as something my department might use. I thought he was going to have a heart attack as he stammered out his "Uh, uh, no, but, uh, I can learn pretty quick!" I reassured him it wasn't something we were using, but I was just curious. Chances are if you've been called in for an interview, you've already the core basic knowledge that truly is pass/fail.