• The best career advice my father ever gave

    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.

    Read on →

  • Two important numbers for job seekers: 7.5% and 1:11

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

    Read on →

  • How does a contractor make his resume appealing to a hiring manager?

    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 ..."

    You can also try to turn this potential negative into a positive. "I've worked on a wide variety of database systems, including Oracle, PostgreSQL and DB2, for companies from a 10-person accounting firm to a Fortune 100 textile manufacturer." You'll show the breadth of knowledge you bring to the position.

    If you're concerned about the resume not being seen along with the cover letter, I'd suggest adding a final bullet point to the professional summary at the top of the resume, such as:

    <blockquote* Experienced contractor looking to start a long-term full-time position in DC area </blockquote>

    In some ways, it's the dreaded Objective, which should never appear in your resume but I think that if you put it as the last bullet in the summary, you'll put the reader's mind at ease, before she gets to the work history that shows you're a contractor.

    I saw a comedian once explain that if there's anything out of the ordinary with you (very tall or short, a speech impediment, etc), you call attention to it at the beginning of your routine. If you don't, your audience will fixate on that aspect of you and not listen to what you're saying. Just do half a minute to acknowledge the attention-grabber, and move on. That's the approach I suggest you take in this case.

    Sometimes when we write resumes, we're so concerned with short sentences and bullets, we forget about the power of a cover letter. In this case, the cover letter shows that you're interested in that specific company, because your cover letter discusses the very specific relationship with the company you'd like to have, and heads off a potential problem. That shows foresight and it shows that you're thinking like the hiring manager.

    Read on →

  • On breadth vs. depth of technical knowledge

    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.

  • Should I switch jobs to learn better development processes?

    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!

  • What can go in a sysadmin’s work portfolio?

    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.

  • How to get laid off properly

    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.

    Read on →

  • Do your due diligence when researching a company

    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.

  • Passing the receptionist test

    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.

  • There are no silver bullets in job hunting

    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:

    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.

  • How to say "I don’t know" effectively

    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.

  • The Career Manifesto

    This brilliant list comes from http://www.execupundit.com/2006/12/career-manifesto.html.

    1. Unless you're working in a coal mine, an emergency ward, or their equivalent, spare us the sad stories about your tough job. The biggest risk most of us face in the course of a day is a paper cut.
    2. Yes, your boss is an idiot at times. So what? (Do you think your associates sit around and marvel at your deep thoughts?) If you cannot give your boss basic loyalty, either report the weasel to the proper authorities or be gone.
    3. You are paid to take meaningful actions, not superficial ones. Don't brag about that memo you sent out or how hard you work. Tell us what you achieved.
    4. Although your title may be the same, the job that you were hired to do three years ago is probably not the job you have now. When you are just coasting and not thinking several steps ahead of your responsibilities, you are in dinosaur territory and a meteor is coming.
    5. If you suspect that you're working in a madhouse, you probably are. Even sociopaths have jobs. Don't delude yourself by thinking you'll change what the organization regards as a "turkey farm." Flee.
    6. Your technical skills may impress the other geeks, but if you can't get along with your co-workers, you're a litigation breeder. Don't be surprised if management regards you as an expensive risk.
    7. If you have a problem with co-workers, have the guts to tell them, preferably in words of one syllable.
    8. Don't believe what the organization says it does. Its practices are its real policies. Study what is rewarded and what is punished and you'll have a better clue as to what's going on.
    9. Don't expect to be perfect. Focus on doing right instead of being right. It will simplify the world enormously.
    10. If you plan on showing them what you're capable of only after you get promoted, you need to reverse your thinking.

    My favorites are #6 and #9. I'm devoting a chapter in my upcoming book to the ideas hidden within #6, which technical people are notoriously bad with.

  • Give just the facts when job hunting

    When faced with the daunting task of summarizing themselves, whether on paper in a resume or face-to-face in an interview, job hunters often fall into the trap of trying to encapsulate everything into a few simple, pithy phrases. I’ve seen these chestnuts far too often:

    • I'm a hard worker
    • I have a strong work ethic
    • I'm reliable
    • I'm a good listener
    • I work well with others
    • I take pride in my work

    The hiring manager’s mental response, assuming his eyes haven’t glazed over, is likely to be “You and everyone else, pal.” Is there anyone out there who would not feel justified in using all of the assessments above to describe themselves? (I certainly hope that you wouldn’t be foolish enough to vocalize it if not.)

    Read on →

  • The worst reason to quit your job

    When you’re in a job that makes you unhappy, it can be easy to start thinking about making a move elsewhere. Maybe the work’s not as fun any more, or you’re not advancing when you should be. While there are plenty of good reasons to leave, there’s one that shouldn’t enter your mind: Not liking the people you work with, even if it’s your boss.

    Read on →

  • Twelve items to leave off your resume and cover letter

    You're working on your resume, trying to give the recipient an idea of what a determined, hard worker you are, and you drop in this sentence.

    After my wife and I arrived from Germany at age 35, I trained my son to play piano at our church.

    You're showing that you're a committed family man with strong roots in your heritage, that you have the skills to raise a child, and you're active in your church community, right? Wrong. You're making the person reading the resume very nervous, and probably excluded yourself from a job. That one little sentence covered five bits of information that reveal your membership in various protected classes against which it's illegal to discriminate in the United States.

    • Are you married?
    • What country are you from?
    • How old are you?
    • Do you have kids?
    • Do you go to church? Which one?

    Providing information that is not relevant to the job, or would get me, as a hiring manager, in trouble if I asked for it, makes me very nervous.

    The rule to follow is: If the employer can't ask you, then don't volunteer it.

    I once got a cover letter that started "As a proud black woman, I am..." It immediately went into the discard pile. Not only was it foolish for her to put her gender and race on her resume, because I was not legally allowed to ask it, it made me wonder why would she tell me those things. Could I expect someone with a big chip on her shoulder? If I didn't hire her, would I get accusations of racism and sexism?

    The following items should never be mentioned on your resume or cover letter, or discussed in an interview, even indirectly:

    • Age
    • Sex/gender
    • Disability
    • Race/color
    • National origin, birthplace, ethnic background
    • Religion
    • Marital status
    • Children/pregnancy

    These are the big eight that are just absolute no-nos, and that most people know are illegal. Nobody reading this article is being cast in a movie that needs a 65-year-old wheelchair-bound Jewish man, so none of those are bona fide occupational qualifications, or BFOQs.

    Sometimes unscrupulous employers can ask questions that get at this information. For instance, if you answer the question "when did you graduate high school?" with "1984", he's found that you're roughly 39. By extension, you should leave dates of high school off your resume.

    Other items that may not be illegal, but may cause problems, include:

    • Appearance, including photo
    • Sexual preference
    • Political affiliations
    • Clubs or groups you belong to, unless professionally related

    There may be exceptions in certain cases. For example, my friend Tom Limoncelli is socially and politically active. In 2003-2004, he worked as a sysadmin for the Howard Dean presidential campaign. In this case, working for Dean is valuable work experience that should be noted on his resume, and it directly relates to the work that he's known for.

    Clubs and groups may not be obvious red flags, but are best left alone. To you, it might be cool that you race motorcycles on the weekend, but someone reading your resume might judge you as having a hobby that's detrimental to the environment, or overly risky. Your weekend volunteer work at Planned Parenthood could be a black mark in the eyes of someone strongly pro-life.

    The type of outside work is relevant, too. Handing out literature for an activist group has no place on a resume, but that might not be the case if you overhauled their web site using PHP. It partly depends on what job you're applying for. You might exclude your Planned Parenthood website work if applying to a Catholic school, but include it when applying to Ben & Jerry's. This is another example of why there's no such thing as having "a resume", a single static document you send around.

    In general, follow the rule that if something does not directly relate to your skills, and how you would perform the job in question, leave it out.

    You might think "I wouldn't want to work for someone who would discriminate against me because I fit into group X," but that's not the point. The issue isn't overt discrimination as much as the perception of the possibility of discrimination. I wouldn't discriminate against a black woman, but I did immediately exclude someone naive or foolish enough to mention being one.

    Finally, even if all this verboten information is available on the web with minimal web searching, it's not OK to put on your resume. The issue is what you present as yourself, not what people can find.

    And don't think employers won't search Google about you extensively before interviewing. But that's a topic for another article...

    For more information about hiring discrimination, see the EEOC website.

  • Your second most important relationship

    As I sit here on this Labor Day weekend, I ponder who it is we labor for. I want you to as well.

    Most of us in the computer industries are lucky enough to be doing what we love. Programming, system administration and the like are in our blood. We've done it as a hobby, and now we're getting paid relatively large amounts to do it. Plenty of other people don't have it nearly as good as we do.

    And yet, so many of us are unhappy with where we're at. We work with jerks, or the companies we work for have Mickey Mouse rules that treat us like children, or even worse, hourly workers. Maybe you're in a company with motivational posters on the wall where you can't miss 'em when you have to take a leak. It's a sort of ongoing battle for your soul, where the day-to-day grinds down at you and makes you miserable over time.

    Seems to me, however, that the most common source of bad jobs is having the bad boss.

    I had lunch with my friend I'll call Bob who had just been let go from his job after a short, confusing month. His boss was vague in expectations, yet also a micromanager. He'd demanded on Wednesday that Bob have a project done by Monday morning at 9am, because it was Crucial To The Company. On Friday night, after Bob returned home from a long-planned dinner with his wife and some friends, he found in his inbox on his return a note: "I see you logged off at 6pm, this project is crucial to the company." The boss badgered him all weekend until Bob finally declared that his work was done on Sunday.

    Add to this that even though Bob had the work done, there were other unspoken, unmet expectations. The boss rattled them off to Bob at his summary firing, but Bob didn't understand them after the fact.

    I offered "It doesn't sound like much of a loss. Your boss was crazy, or stupid, or just a bad boss. He wasn't like that when he interviewed you, was he?" Bob replied "I'm glad you think he was a bad boss, because I kind of picked that up in the interview."

    Now here's what astonishes me. Here's a guy who's a good programmer, who works hard, and yet he's willing to take a job with someone who he strongly suspected of being dumb and/or crazy.

    Bob's not the only one, of course, or I wouldn't be writing this. I've got other friends who jump into a job relationship hoping for the best, and coming out miserable. Some people may be desperate and have no choice, but it happens so often, that can't be the case most of the time.

    I suspect that most people miss that word "relationship", because it is exactly that.

    Your job is a relationship.

    It's a relationship with your boss, yes, but it's also a relationship with the company, with your co-workers, with the commute, with everything that goes into your job.

    It's a relationship that you spend 40+ hours a week on. How many hours a week do you actually spend awake with your spouse? Probably a little bit more than that, but it's roughly the same in size.

    The relationship with your employer is as important to look at as the relationship with your spouse. That means both before and after you commit.

    I'll write more about this in weeks to come, as I work on my upcoming book, Pragmatic Job Hunting.