Andy Lester

Technology, careers, life and being happy

“Fifteen minutes longer and a thought process and probably you wouldn’t have done that”

| 0 comments

In last month’s Esquire, there’s an interview with George Clooney where he briefly discusses Twitter:

“So one drunken night, you come home and you’ve had two too many drinks and you’re watching TV and somebody pisses you off, and you go ‘Ehhhhh’ and fight back. And you go to sleep, and you wake up in the morning and your career is over. Or you’re an asshole. Or all the things you might think in the quiet of your drunken evening are suddenly blasted around the entire world before you wake up. I mean, when you see, like, Ashton Kutcher coming out going, you know, ‘Everybody leave Joe Paterno alone,’ or whatever he said, you just go, ‘Fifteen minutes longer and a thought process and probably you wouldn’t have done that.’ ”

Granted, most of us don’t live in a world where everything we say can and will be used against us in the court of television infotainment, but it still applies. I’m sure we’ve all said something publicly on the net that we wish we hadn’t.

I think it’s especially true for those of us who live in the little echo chamber of the world of open source. Maybe it’s a snarky comment in a Perlmonks thread, or a flippant remark at a conference, or something rude in a bug report. These things get remembered and hurt us.

“I have often regretted my speech, but never my silence” — Publilius Syrus, 1st century BC, well before Twitter.

How to talk in an interview about problems at your past job without coming off as a complainer

| 0 comments

Someone on reddit asked “Why is talking bad about a previous job a taboo? What’s wrong with complaining? It’s showing dissatisfaction with the rules or environment. If I see a rule that’s unfair or inefficient, isn’t it in the company’s best interest to let them know in order to fix the issue?”

The problem with “showing dissatisfaction” is that it comes across as whining and complaining. You’re telling about how things stink, but not about what you’ve done to make things better. Managers hate complainers because when the complainer gets hired, the manager will have to spend time dealing with the complainer’s complaints. The complainer is likely to cause drama, and nobody has time for that.

However, it’s possible to take a negative at your past employer and turn it into a positive for you in the interview. If you can tell about how you have actually fixed an issue, that’s great. Tell that story.

For example, a common interview question is “Tell me about a project that didn’t go so well.” Here are two ways to answer that.

Bad: “Well, there was this one time that we had a big update to the app for a big trade show. Then, two weeks before the show, Director of Marketing comes and says ‘We have to change the color scheme’, and it was two solid weeks of redoing all the screens and re-testing and more than a few hours of overtime.”

This is complaining. Now, tell that story again in another way.

Good: “One time we had a big app update for a trade show, and two weeks before the show, Marketing decided to change the color scheme. It put is in a bit of a crunch, but we pulled it off and the show was a success. After the show, we looked at what happened and discovered that we weren’t communicating enough with the project stakeholders, and as a result we made sure that we had weekly updates to show project progress to the people that mattered.”

That is not complaining. That is describing a problem that came up and how you improved it as a result. That’s why you get hired: To do work and to solve problems.

A good interviewer will follow up with the “Tell me about a project that didn’t go well” question with “And what did you learn from the experience?” Don’t wait for that follow-up. Make your answer include what you learned. Then you’re not complaining.

Make the Linux chkconfig service list easier to read

| 1 Comment

If you run a Linux box, and you want to see what services start up at which level, you use runlevel:

$ chkconfig
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:off   4:off   5:off   6:off
blk-availability        0:off   1:on    2:on    3:on    4:on    5:on    6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:off   4:off   5:off   6:off
...

Boy is that hard to read at a glance. All the “on” and “off” look very similar to each other, and that blk-availability service’s length screws up the tabbed columns. I decided I needed a better way, which I called cclist.

$ cclist
  2345  acpid
   345  atd
  2     auditd
 12345  blk-availability
 12345  cpuspeed
  2345  crond
  2     cups
...

Here’s the code to ~/bin/cclist:

#!/usr/bin/perl

open( my $fh, '/sbin/chkconfig --list |' ) or die "Can't open chkconfig: $!";

while (<$fh>) {
    if ( /^(\S+)(\s+\d:o(n|ff)){7}/ ) {
        chomp;
        my @cols = split;
        my $service = shift @cols;
        for ( @cols ) {
            my ( $level, $status ) = split /:/;
            print $status eq "on" ? $level : " ";
        }
        print "\t$service\n";
    }
    else {
        print;
    }
}

Those “illegal job interview questions” aren’t actually illegal

| 0 comments

It’s common knowledge that it’s illegal for US employers to ask about your age, sex, religion, marital status, national origin, or other protected statuses. Thing is, it’s not illegal for them to ask.  It’s illegal for them to discriminate, but it’s not illegal to ask. Still, the idea of the “illegal interview questions” is a common one. Search for “illegal interview questions” on Google and you’ll get 50,000 hits. Lots of blog posts and news articles, but nothing from anyone I see as a legal authority.

I’m certainly not a lawyer, but I feel confident in quoting the US Equal Employment Opportunity Commission’s website for this (emphasis mine):

As a general rule, the information obtained and requested through the pre-employment process should be limited to those essential for determining if a person is qualified for the job; whereas, information regarding race, sex, national origin, age, and religion are irrelevant in such determinations.

Employers are explicitly prohibited from making pre-employment inquiries about disability.

Although state and federal equal opportunity laws do not clearly forbid employers from making pre-employment inquiries that relate to, or disproportionately screen out members based on race, color, sex, national origin, religion, or age, such inquiries may be used as evidence of an employer’s intent to discriminate unless the questions asked can be justified by some business purpose.

Short version: It’s not illegal to ask those questions, but it’s stupid to do so because it gives the candidate ammo to use in a lawsuit against you.

I think it’s an important distinction. I read plenty of comments on reddit and the like where people seem to think that being asked about their marital status is somehow going to get them a job because that’s an illegal question. It’s not. Other than feeding one’s sense of righteous indignation, there’s not much that will probably come out of being asked an “illegal question.” There has to be a lawsuit for anything to come of it, which means you need to find a lawyer who thinks that you can win a discrimination suit, because the lawyer will be able to prove discrimination.

The key is that you have to prove that you were discriminated against. Simply saying “They asked me an illegal question” isn’t enough. Here’s what a random employment law firm’s website says:

An employee in an employment discrimination and wrongful termination case must prove that the reason he or she was fired, or not hired or not promoted, is because of his or her “protected classification.” In other words, you have to prove that you were denied employment or a promotion because of your race, gender, ethnic background, age or other discriminatory factor.

It’s also important to know that in addition to the Federal laws, you may have rights in other states. For example, some states forbid discrimination based on sexual orientation, while many others do not (yet). Search Google for “discrimination laws [your state]” and you should get hits for your state’s government agency that covers this topic.

None of this is to endorse employers asking such questions. A good employer shouldn’t ask you any questions that aren’t related to the job.

What to do if you’re asked a question that gets at something discriminatory? Check out this article on how to handle bad interview questions.

The simple math of why your resume probably isn’t getting read.

| 0 comments

You spend hours slaving over your resume, crafting every word of every bullet point, and yet you’re getting no interest from the companies you send the resume to.  Maybe your problem is that you’re ignoring the most important part of your resume: The first half-page, or the first screenful.

Let’s do some simple math here.  Last time I posted job ads for programmers I was getting 300-400 responses per ad, so let’s say conservatively that a job posting nets a hiring manager 250 resumes. If he spends 10 minutes on each resume, examining each in detail, that comes out to:

250 resumes x 10 mins/resume  = 2500 minutes = 41.2 hours

That’s one entire work week doing absolutely nothing but reading those resumes 8 hours a day.  That’s not going to happen.

Much more realistic is for the reader to spend maybe a minute on each resume determining which ones are obviously crap, and which ones have potential and get put aside into a pile for closer consideration.

250 resumes x 1 min/resume  = 250 minutes = 4 hours

That’s much more manageable.  Now the hiring manager is able to set aside the 5-10% of the resumes that are not clearly garbage, or shotgunned to everyone, or from offshore consulting firms offering their services.

So you have at most a minute of actual reading time, max.  I’ve seen the claim of 10-20 seconds per resume commonly cited, too.

What does this mean to you, the resume writer?

Nobody is going to read past the first half-page of your resume unless you give them a reason to read the rest.

Think of the top half of your resume as a movie trailer, a teaser for what’s in the rest of the movie.  You want that top half-page to put all the best about you out front.   You’re going to start with a summary of what’s to follow, such as:

  • Six years experience system administration for 20-30 Linux and Windows servers.
  • Fully certified as both Red Hat Something Something and Windows Certified Blah Blah.
  • Extensive experience with backup strategies to physical media and offsite solutions.

In three lines, you’ve summarized who you are and given the reader reason to read the rest.  Yes, it is redundant to what’s in the rest of the resume, but that’s OK, because (and I know I’m repeating myself) nobody is going to read your entire resume unless they have a reason to.

The top half-page of your resume is so crucial it’s why an objective is absolutely the worst way to start a resume.  Consider a typical resume objective:

JOB TARGET: My goal is to become associated with a company where I can utilize my skills and gain further experience while enhancing the company’s productivity and reputation.

There is absolutely nothing in that to make the reader want to read further. Everything is about what the writer wants, not what she can bring to the company. That resume is bound for the reject folder.

You have less than half a minute to convince the reader to read your entire resume.  Make the first part of your resume tell all the important stuff, and only the important stuff.

My bash prompt with git/svn branch+status display

| 2 Comments

After spending a few hours last night switching between three different branches in the ack2 project, and typing “git br” over and over, I decided I needed to put branch status in my bash prompt. The only question was: Which one would I steal? Fortunately, Rob Hoelz was online and I mentioned it to him and he handed me his, so I stole it and also added Subversion support as well.

Note: Edited to fix a problem with detecting SVN branches.

#!/bin/bash

# Adapted from from https://github.com/hoelzro/bashrc/blob/master/colors.sh

function __prompt
{
    # List of color variables that bash can use
    local BLACK="\[\033[0;30m\]"   # Black
    local DGREY="\[\033[1;30m\]"   # Dark Gray
    local RED="\[\033[0;31m\]"     # Red
    local LRED="\[\033[1;31m\]"    # Light Red
    local GREEN="\[\033[0;32m\]"   # Green
    local LGREEN="\[\033[1;32m\]"  # Light Green
    local BROWN="\[\033[0;33m\]"   # Brown
    local YELLOW="\[\033[1;33m\]"  # Yellow
    local BLUE="\[\033[0;34m\]"    # Blue
    local LBLUE="\[\033[1;34m\]"   # Light Blue
    local PURPLE="\[\033[0;35m\]"  # Purple
    local LPURPLE="\[\033[1;35m\]" # Light Purple
    local CYAN="\[\033[0;36m\]"    # Cyan
    local LCYAN="\[\033[1;36m\]"   # Light Cyan
    local LGREY="\[\033[0;37m\]"   # Light Gray
    local WHITE="\[\033[1;37m\]"   # White

    local RESET="\[\033[0m\]"      # Color reset
    local BOLD="\[\033[;1m\]"      # Bold

    # Base prompt
    PS1="$LCYAN\h:$YELLOW\w$LCYAN \\\$$RESET "

    local dirty
    local branch

    # Look for Git status
    if git status &>/dev/null; then
        if git status -uno -s | grep -q . ; then
            dirty=1
        fi
        branch=$(git branch --color=never | sed -ne 's/* //p')

    # Look for Subversion status
    else
        svn_info=$( (svn info | grep ^URL) 2>/dev/null )
        if [[ ! -z "$svn_info" ]] ; then
            branch_pattern="^URL: .*/(branch(es)?|tags)/([^/]+)"
            trunk_pattern="^URL: .*/trunk(/.*)?$"
            if [[ $svn_info =~ $branch_pattern ]]; then
                branch=${BASH_REMATCH[3]}
            elif [[ $svn_info =~ $trunk_pattern ]]; then
                branch='trunk'
            else
                branch='SVN'
            fi
            dirty=$(svn status -q)
        fi
    fi

    if [[ ! -z "$branch" ]]; then
        local status_color
        if [[ -z "$dirty" ]] ; then
            status_color=$LGREEN
        else
            status_color=$LRED
        fi
        PS1="$LCYAN($BOLD$status_color$branch$LCYAN)$RESET $PS1"
    fi
}

if [[ -z "$PROMPT_COMMAND" ]]; then
    PROMPT_COMMAND=__prompt
else
    PROMPT_COMMAND="$PROMPT_COMMAND ; __prompt"
fi
__prompt

Just drop that into your ~/.bash directory as prompt.sh, and then add

source ~/.bash/prompt.sh

to your .bashrc. Now you have color-coded branch names: red for dirty, green for clean.

ack 2.0 has been released

| 6 Comments

ack 2.0 has been released. ack is a grep-like search tool that has been optimized for searching large heterogeneous trees of source code.

ack has been around since 2005. Since then it has become very popular and is packaged by all the major Linux distributions. It is cross-platform and pure Perl, so will run on Windows easily. See the “Why ack?” page for the top ten reasons, and dozens of testimonials.

ack 2.0 has many changes from 1.x, but here are four big differences and features that long-time ack 1.x users should be aware of.

  • By default all text files are searched, not just files with types that ack recognizes. If you prefer the old ack 1.x behavior of only searching files that ack recognizes, you can use the -k/--known-types option.
  • There is a much more flexible type identification system available. You can specify a file type based on extension (.rb for Ruby), filename (Rakefile is a Ruby file), first line matching a regex (Matching /#!.+ruby/ is a Ruby file) or regex match on the filename itself.
  • Greater support for ackrc files. You can have a system-wide ackrc at /etc/ackrc, a user-specific ackrc in ~/.ackrc, and ackrc files local to your projects.
  • The -x argument tells ack to read the list of files to search from stdin, much like xargs. This lets you do things like git ls | ack -x foo and ack will search every file in the git repository, and only those files that appear in the repository.

On the horizon, we see creating a framework that will let authors create ack plugins in Perl to allow flexibility. You might create a plugin that allows searching through zip files, or reading text from an Excel spreadsheet, or a web page.

ack has always thrived on numerous contributions from the ack community, but I especially want to single out Rob Hoelz for his work over the past year or two. If it were not for Rob, ack 2.0 might never have seen the light of day, and for that I am grateful.

A final note: In the past, ack’s home page was betterthangrep.com. With the release of ack 2.0, I’ve changed to beyondgrep.com. “Beyond” feels less adversarial than “better than”, and implies moving forward as well as upward. beyondgrep.com also includes a page of other tools that go beyond the capabilities of grep when searching source code.

For long time ack users, I hope you enjoy ack 2.0 and that it makes your programming life easier and more enjoyable. If you’ve never used ack, give it a try.

When it comes to job hunting advice, question everything you’re told

| 1 Comment

Punk pioneers Stiff Little Fingers‘ signature tune “Suspect Device” admonished “Don’t believe them / Question everything you’re told.” It’s sound advice for anyone looking for guidance in the job world.

The other day on /r/GetEmployed, a user asked how he should write his resume objective for a job as a sales clerk at Bass Pro Shops. He said that the prof for his Communications in the Business Environment class told him to have an objective on his resume.

I’m guessing the prof might also have advised to put “References available upon request” at the bottom of the resume, too, which is also bad advice. I’m also guessing that the prof hasn’t created a resume in the non-educational world ever.

The key here is that the original poster of the question (the OP) didn’t ask why an objective is important. He just accepted it as true without an understanding. This is a mistake. Whenever someone gives you advice, about anything, not just jobs, ask why. Ask specifically, “Why do you say I should put an objective on the resume?” or “Why do I have to wear a suit to the interview?” You need to understand why you are doing anything, and not just follow it blindly, so that you can make a decision on if you want to follow it or not. You will get conflicting opinions on everything in life, so understand the logic behind it.

I’m guessing that if the OP had gone back to his prof and asked why to have an objective, the prof’s answer would have been not much more substantive than “because that’s just what you do”. If he were to ask me why you should not have an objective, I’d explain “because it is a waste of space that says nothing except that you want the job that you’re applying for, instead of telling good information about you and why you’re good for the job”. Based on those two reasons, the OP can make his own decision.

Note: There is a time when objectives may make sense: when you’re handing out resumes blindly, like at a job fair or something, where it’s not clear what sort of job you’re looking for. Then it makes sense. But if you’re sending in a resume for a specific job, and your objective is “to get a job that is exactly like the one I’m applying for right now”, then leave it off.

Ask questions. Understand why you’re doing what you’re doing. Don’t follow anyone’s advice blindly, including mine.

How to prepare for a job interview: The 4-point summary

| 1 Comment

The core of your preparation for the job interview:

  1. Learn what they do.
  2. Learn how they do what they do.
  3. Figure out exactly what skills, experience and background you have that will help them do what they do faster and cheaper.
  4. Plan how you’re going to explain #3 to them.

Everything else is implementation details.

You should have the first three figured out before you even send a resume. If you don’t have what it takes to help them do it cheaper and faster, then don’t waste your time applying for the job.

Tell me about weird, frustrating or bad job interview questions you’ve been asked.

| 4 Comments

I’m working on an article for SmartBear on handling bad or weird job interview questions, and I’d like to get input from you.  Have you been asked weird, insulting, inexplicable or just plain bad questions in a job interview?  Please let me know about them, and where you were interviewing, or at least what type of company and job was involved if you don’t want to name names.  I want to include real examples in my article and then include suggestions on how to effectively answer them.  I’ll also be discussing alternatives to these bad questions that get at what (I suspect) the interviewer is getting at.  I’m looking for first-hand accounts rather than questions you might have heard a friend talking about.

I’m sure many of you have had estimation questions like “How many light bulbs are there in the city of Chicago?”.  I don’t see those as weird if you’re interviewing at Google, where estimation and scaling are core competencies, but may be in other other contexts.  Have you been asked these sorts of questions elsewhere?  I get a sense from reading things online that these are asked by managers who think they’re cool questions, but without a business need for asking.

Please let me know in the comments, or email me at andy@petdance.com.