Have you ever been asked “What is your biggest weakness?”

February 20, 2012 Interviews 18 comments ,

It’s become a bit of a joke by now, being asked in a job interview “What is your biggest weakness?” Numerous books and blog posts talk about how to answer the question, turning a negative into a positive, without sounding glib. I discuss it in the “Tough Questions” chapter of my book. It’s been parodied in this movie:

It’s a pretty bad question to ask. Presumably it’s asked to find out how self-aware the candidate is of where they have room for improvement, but there are better ways to find that out. For example, I’ve asked it directly in interviews, “Where do you see room for improvement in your skillset, and what are you doing to make that happen?”

Watching the “biggest weakness” movie above, I realized that I don’t think I’ve ever actually been asked the question in a real job interview. I know that if an interviewer did ask me, my opinion of him would drop considerably. I would wonder if he just got it out of a stock list of questions to ask.

I know what my answer would be, if I was ever asked this live: “I don’t know JavaScript as well as I should. I know enough to do basic form validation and graphic mouseovers, but as far as applications being written with tools like jQuery, I just haven’t gotten into that, and I should because that’s clearly where much of the web is headed.”

What about you? Have you, personally, ever been asked the question in a job interview? How long ago was it? What year? How did you answer, and how did the interviewer take your answer? How was the rest of the interview?

Or is “What is your biggest weakness” almost a sort of urban legend of interview questions, the one that you hear about other people getting asked, but never yourself?

Today’s PostgreSQL indexing gotcha

February 16, 2012 Programming No comments

At work, I have a big 14M-row production table with a bunch of indexes on it.  One of the indexes was bloated, so I built a new version of the index, and dropped the old bloated index.  Got back a gig of space on the filesystem.  Excellent.

Now, from what I understand, that should be all I have to do.  Postgres doesn’t need an ANALYZE on the table to use the new index.  All the column stats for the table in pg_stats are still there, so the query planner can use the index, and it should all Just Work.

Except that all of a sudden slow queries started showing up in the server log, and we were doing sequential scans. The planner wasn’t using the newly built index.

So I did an ANALYZE on the table, and suddenly the planner started using the index. Why was this?

This goes against what I knew. On this page, Robert Treat, Pg guru, says:

When adding indexes, it is not necessary to re-analyze the table so that postgres will “know” about the index; simply creating the index is enough for postgres to know about it.

So why didn’t it work for me? Turns out it was because the index I rebuilt was a functional index.

Apparently, Pg doesn’t know about the functional index unless there’s an ANALYZE to make the planner know about it. I’m guessing that somewhere there’s a pg_stats equivalent that has functional index histograms in it, too.

If you have further insight on this, please let me know in the comments.

Clarify user expectations to the minute to eliminate frustration and extra work

February 9, 2012 Career, People, Work life 1 comment

Vague timeframes like “ASAP” or “in a few days” are a sure way to get sorrow into your work day.  You’ll likely spend too much effort getting something earlier than the customer wanted, or later than he expected, leaving him frustrated.

Consider this simple request: “Can you get me the number of widgets we sold in 2011 ASAP?”  What exactly does “ASAP” mean?  Always ask for clarification.  “When exactly do you need this?  In ten minutes?”  You might get an answer of “Within half an hour. Jim has a conference call to London at 11:00.”  Or you might get an answer like “Oh, no, by the end of Tuesday is fine.”

This is also the same approach to take when someone asks “How long will it take for you to do X?”  She doesn’t really want to know how long it will take, but rather if you can do it in the timeframe she wants.  Therefore, don’t answer the question, but instead find out what the user actually wants by asking “When do you want it by?”

Make sure you always get time requirements down to the minute, not the day.  For instance, if a user says “Can you email me those numbers by Wednesday?” when exactly does that mean?  You might take that to mean “some time on Wednesday”, but she might mean “Wednesday at 8am because that’s when I come in and will want to incorporate them into a report.”  When 8am comes and no numbers are in her mailbox, you look like a chump.  If it’s the other way around and you get her numbers sooner than necessary, you’ve prioritized her work higher than other tasks that need to get done first.

There are all sorts of vague terms to clarify.  “End of business” usually means “I really want it the following morning”, and “by lunchtime” probably means “when I get back from lunch”.  In all cases, clarify to eliminate misunderstanding.

Finally, close the conversation by reiterating your commitment and include your understanding of the time frame.  “I’ll email you an Excel document with those numbers by 4pm tomorrow.”  This makes everything clear and gives one more chance for potential misunderstandings to be made explicit.

Why I’m finally leaving GoDaddy

February 6, 2012 Internet 7 comments , , , , ,

I watched the Super Bowl last night, and GoDaddy’s annual brain-dead skinfest reminds me that I have domains to transfer off of this embarrassment of a company. I’ve already transferred away a half dozen, and have nine more coming up for renewal in the next eight months. All will be transferred to new registrars.

I’m not leaving GoDaddy because their TV ads are demeaning to women.

It’s not that their TV ads are demeaning to viewers.

It’s not that their home page currently features seven sexualized women in the first screen. Even playboy.com only has three.

It’s not that they supported SOPA.

It’s not that they changed their stance on SOPA in the face of predictable public backlash.

It’s not that their user-facing admin screens were designed by an orangutan on meth and a committee from Marketing.

It’s all of it. Put together, GoDaddy prove themselves to be buffoons.

The SOPA turnaround was especially telling. The company figured it could come out with some good PR by taking a stand on SOPA, and bailed when they found out they were on the wrong side of it. “Go Daddy will support it when and if the Internet community supports it” said a press release. That’s hardly inspiring, GoDaddy. If you’re going to come out and support legislation, do it because it’s the right thing to do, not because “the Internet community” says so.

Worst, how can I support a company that treats me with such contempt? Every part of every admin process is filled with pitches for add-on services that obscure what I want to do. Bob Parsons thinks that I’m going to be swayed to use his company because they’re edgy enough to show skin.

GoDaddy thinks I’m stupid. And maybe I was for sticking with them for this long. No more.

For me, I’ve been moving my domains to pairNIC and dynadot. Some people have recommended gandi.net, but I think that any company that sells itself with a tagline of “no bullshit™” is only slightly less buffoonish as selling with the Pussycat Dolls.

If you’re using GoDaddy as a registrar, I ask you to consider the contempt with which GoDaddy holds you in next time it’s time to renew your domain names.

Never put “excellent communication skills” on your resume

February 1, 2012 Resumes 11 comments , , ,

Never put “excellent communication skills” in your resume. Who doesn’t think they have “excellent communication skills?” It means nothing. It’s fluff that detracts from the real content of your resume. Instead, give the reader examples of how you use those skills.

Imagine four different people who have put “excellent communication skills” on their resumes, and their thought processes:

  • “I give weekly status presentations to upper management about project status. I can put ‘excellent communication skills’ on my resume!”
  • “I taught a lunch & learn session on JavaScript. I can put ‘excellent communication skills’ on my resume!”
  • “I’ve written articles for the company newsletter. I can put ‘excellent communication skills’ on my resume!”
  • “I am proud of my ability to spell and use basic English mechanics. I can put ‘excellent communication skills’ on my resume!”

So when someone reading your resume sees “excellent communication skills” on your resume, which one will she think it means? Chances are, she’s going to assume you’re the “I can spel gud” guy and gloss over it.

(Have you noticed that while you read this article, you tire of reading the words “excellent communication skills”? So does the poor hiring manager who has to read it on every resume he gets.)

Instead of putting those dreaded three words on your resume, replace it with a description about how exactly you use these skills. Doing that is an iterative process that digs down to find the interesting stuff that the hiring manager wants to read.

The other day I was helping my friend Katie with her resume, and I spotted the dreaded “excellent communication skills” near the top. We had an exercise to come up with something better that went a little like this:

Andy: “Why do you say you have excellent communication skills?”

Katie: “I don’t know, I’m just good communicating. People talk to me.”

Andy: “How do you mean they talk to you? About what?”

Katie: “There was this one time where I was on a project with these outside consultants, and consultants were upset because they weren’t getting what they need, and management didn’t know what was going on. It was just a mess. And people were really frustrated and they’d tell me all the things that were going wrong.”

Andy: “Good! And so what did you do?”

Katie: “I talked to the project leader, and explained what was going wrong that he hadn’t heard about, and we worked on ways to make sure everybody could keep track of the deliverables, and get them to the consultants. And then the project leader asked me to do status reports for upper management. It all worked really well.”

Andy: “So would you feel comfortable saying ‘Reworked project process to increase communication, both vertically and horizontally, across the company and with outside consultants?’ And can you specify how many people were on the project, too?”

Katie: “Yeah, that sounds good. And plus, there was this other time….”

Notice how with just a little digging and iteration (shortened for this article) Katie and I turned her vague “excellent communication skills” into something that tells the reader exactly how she has used those skills to benefit the business. What we wound up with is far more impressive than being able to write clearly.

As I’ve said before, don’t put self-assessments in your resume. Give the evidence and let the reader make her own decision.

What are your dreaded cliches on resumes that mean nothing? Let me know in the comments below.

The most important pig in the office

January 26, 2012 Programming 1 comment , , , ,

In the world of devops, we have complex software packages like Jenkins to take care of continuous integration of source, and intricate monitoring systems like Nagios and Icinga to keep an eye on the state of your servers. For notification of problems, however, sometimes the low-tech solution is best. Ladies and gentlemen, I present to you: Olivia the pig.

Olivia normally sits on my bookshelf at the office. She’s a toy from when my daughter Quinn was much younger, the star of the Olivia picture books that she loved back then. When Quinn decided she no longer wanted to play with Olivia, I gave Olivia a new home at the office, where she serves two important purposes in the web development department.

First, Olivia is a warning flag. She’s a plush visual semaphore that says to all the developers “Something is wrong with the website source code.” Like most shops (I hope!), we practice continuous integration of our source. The rule is that we must be able to roll out trunk to the production website at any time. Projects are done on branches, so that we don’t have half-done work in progress committed to trunk. If code is committed to trunk, it’s ready to go live at any time.

Olivia is the visual indicator that says “we cannot push to production.” Normally, Olivia sits on my bookshelf. where she is only seen by me. When she is on top of my cube, she can be seen by everyone on our end of the building, including all of us developers. She can’t be missed. If Olivia is out, Job #1 is to fix trunk and get it stable.

Sometimes Olivia comes out intentionally, such as when we start a project merge to trunk. Olivia stays out until we’ve passed all our smoke tests, lest someone push out unproven code. Olivia tells everyone that things have not yet been proven to be stable.

Many organizations have physical semaphores like this. In the Perl 5 world, the person who is allowed to make changes to the master source tree is said to be “holding the patch pumpkin.” Why did the Perl community come up with the name “patch pumpkin”? Chip Salzenberg explains:

David Croy once told me once that at a previous job, there was one tape drive and multiple systems that used it for backups. But instead of some high-tech exclusion software, they used a low-tech method to prevent multiple simultaneous backups: a stuffed pumpkin. No one was allowed to make backups unless they had the “backup pumpkin”.

In Chip’s example, the physical semaphore granted privileges. With Olivia, the semaphore of her being atop my cube indicates a problem. In both cases, they’re low-tech but they work.

One Saturday afternoon at the office I had Quinn with me, and she asked why I had her old Olivia stuffed animal at work. I explained Olivia’s purpose, and Quinn thought that was pretty cool. A little later she came back with the picture below. Change “Andy’s computer” to “mission-critical web application that drives all company revenue” and she’s got it right: If Olivia is out, the web app is broken.

The visual semaphore is so simple and unmistakable, a then-eight-ear-old understands it.

But Olivia has a second purpose that I didn’t expect. She’s also a conversation starter, and so an ambassador for the department.

We web developers sit near a main entrance to the building, so many people walk by throughout the day. When Olivia is up on my cube, I’m often asked by a passerby why I have a stuffed pig up there. That’s my chance to do a little department PR. I can tell the person about automated testing, continuous integration, and how we make sure that everything is going well.

I’ve become pretty good at cramming everything into a minute. I’ll say something like “The source code to the website gets 100,000 tests run against it every hour on the hour, so we know we can always update it if we need to. If we discover that something is wrong, Olivia tells everyone that something is wrong. She’s like an oil light on your car’s dashboard.”

I’ve found that people are generally interested in hearing about how we do the magic of running the website. Talking to people helps them understand what it is we do as developers, and helps squash the idea that we just sit around all day typing. They find out just what sorts of processes go into keeping business-critical systems running.

Does your organization have similar low-tech tricks as part of your process? Tell me about them in the comments.

Open source is improv, so say “Yes and”

January 23, 2012 Communication, Open source, People 4 comments , , , , ,

In her fantastic book Bossypants, Tina Fey has a sidebar about how improvisational comedy has changed her life, and given her a new worldview. We in open source would do well to adapt these ideas to how we conduct our projects as well.

Improv and open source share many characteristics. A group of people come together to create something without a plan, and the result is greater than any one person could have created on his own. Everyone has a wellspring of ideas, and adds to the work created by others. In improv, the people make a scene or a sketch. In open source, they make software, or a body of knowledge, or a community, or a gathering.

From her book:

The first rule of improvisation is AGREE. Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt. But if I say, “Freeze, I have a gun!” and you say, “The gun I gave you for Christmas! You bastard!” then we have started a scene because we have AGREED that my finger is in fact a Christmas gun.

Now, obviously in real life you’re not always going to agree with everything everyone says. But the Rule of Agreement reminds you to “respect what your partner has created” and to at least start from an open-minded place. Start with a YES and see where that takes you.

As an improviser, I always find it jarring when I meet someone in real life whose first answer is no. “No, we can’t do that.” “No, that’s not in the budget.” “No, I will not hold your hand for a dollar.” What kind of way is that to live?

The second rule of improvisation is not only to say yes, but YES, AND. You are supposed to agree and then add something of your own. If I start a scene with “I can’t believe it’s so hot in here,” and you just say, “Yeah…” we’re kind of at a standstill. But if I say, “I can’t believe it’s so hot in here,” and you say, “What did you expect? We’re in hell.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “Yes, this can’t be good for the wax figures.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “I told you we shouldn’t have crawled into this dog’s mouth,” now we’re getting somewhere.

To me YES, AND means don’t be afraid to contribute. It’s your responsibility to contribute. Always make sure you’re adding something to the discussion. Your initiations are worthwhile.

Too often in open source, we do the opposite. We quickly say no, without regard to its effects. In improv, “no” kills a scene. In open source, it can drive away a contributor or kill an improvement to a project. It doesn’t need to be the word “no”, but any negativity towards a fresh idea.

Consider this exchange, all too common in mailing lists and IRC channels right now.

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “Language Y is a pain in the ass.”

In one quick bit of snark, Bob has taken a giant crap on Al’s idea, even though his only disagreement was in the implementation. Chances are Al will lose enthusiasm for the probject. In many cases, Al’s reaction might just be “Screw it, I don’t need this.”

Consider this alternative response from Bob:

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “That sounds like a cool idea. I bet a lot of people could use X. I have some concerns about writing it in Y if you’re interested in hearing them.”

This is not “sugar coating the truth” or “being politically correct.” It’s being polite. It’s being a human who understands that other people have feelings, and that those feelings drive behavior.

I’m certain that some reading this will say “If Al gives up based on that, Al needs to toughen up. If someone doesn’t like something I’m doing, I’ll still do it anyway.” That’s great for you, Mr. Self-Esteem. Not everyone is as highly advanced as you are.

The “suck it up and take rude criticism” attitude might make sense if your project can be picky enough to only take contributions from those with your level of self-esteem. No project that I’m on is so overflowing with contributors and code that it makes sense to drive away those who want to help. It’s my job in my communities to help bring in more contributions, and I suggest it’s yours, too.

Open source is not standup comedy. It’s never one star on stage, doing it all himself. It’s a worldwide improv ensemble. Try saying “YES, AND” and see what can come out of it.

Don’t waste your time with fancy resume sites and video resumes

January 9, 2012 Job hunting 1 comment ,

I came across a website that offers a service to host your resume in a snazzy web 2.0 format. It offers a custom URL that you can send employers to, and it lets you host a video resume. The site is all pretty with the latest pastel colors and rounded corners, and there are little tabs you click on to get to different bits of information. Somehow this is supposed to make you stand out and let you take control of your career or something.

Don’t believe it. It’s extra work for the hiring manager, and will work against you in the hiring process.

Consider the hiring manager who has 100 resumes in his inbox. He’s looking to weed through the crap and find the good people. Now here’s an email that says “I don’t have a resume, but here’s a link to my Yadayadayada.com page”.

You think that hiring manager is going to click through? Not very likely.

Say he clicks through and sees all the Web 2.0 colorful goodness. Hey, look, a video. You think he’s going to watch a video about you? Not very likely.

And then say you put up a video, and you fill it with meaningless blather like “I’m a hard worker and I’m a team player” and don’t tell anything about what you’ve actually done and haven’t given the viewer any details about what you’ve actually achieved in your career. Now you’ve wasted the hiring manager’s time to tell them the same nothing.

Video resumes aren’t a new idea. They’ve been around since the 80s when people thought it was brilliant to mail a VHS tape to an employer. Now it’s the 10s, and it’s only slightly less time-wasting.

It’s all about WHAT you say, and not about making it flashy. Flashy works against you if it gets in the way of the hiring manager quickly and easily finding out what he wants to know.

And what does a hiring manager want to know? Three key points:

  • What can you do for me?
  • What have you done in the past, in specific?
  • Are you going to be a pain in the ass if I hire you? Or are you one of those guys who comes in and disrupts a team and has to be fired three months later?

A resume and cover letter that answer those questions are worth 100x more than a video resume and branded website.

Video: How to give a conference presentation, by Mark Jason Dominus

December 8, 2011 Communication No comments , , , , ,

Mark Jason Dominus is one of my inspirations for giving talks at technical conferences. I saw him give this presentation at YAPC 2002 in St. Louis and was inspired to try it myself. The video below is from OSCON a month later.

The video is horrible by today’s standards, but it’s the audio that matters. You can follow along with his slides since they don’t always show up in the video.

Thanks to MJD for his kind permission in letting me post it to YouTube.

How do I make my resume stand out?

November 29, 2011 Job hunting 2 comments , ,

All the time I hear people asking “How do I make my resume stand out?” It’s a great question to ask, because your resume is one of dozens or hundreds of others. The problem isn’t that you want your resume to get noticed, but that you want the reader to be interested in what you say and call you in for an interview. How do you do that?

Remove fluff

Do you have an objective? Don’t. It’s filled with meaningless fluff. “I want to leverage my skills to add value to the bottom line of a forward-thinking blah blah blah bullshit bullshit bullshit.” That says nothing other than “I want this job.” No kidding. Never use an objective.

Do you make meaningless claims like “Excellent written and verbal communication skills.” Crap. It means nothing. Anyone can say that. Give just the facts, not your own assessments. “Excellent written and verbal communication skills” is not a fact. It is an opinion, a self-assessment. Leave it off.

Those are all vague, meaningless generalities. Give details!

Add numbers and other details

Use numbers in everything you can. Numbers draw the eye and give detail. You should have at least one number on every bullet line in your resume.

Let me repeat: Every bullet point in your resume should have a number that gives size of the job.

Instead of saying “Worked on the help desk, answering user questions” you say you “Worked on the help desk, answering an average of 30 user questions per day.”

“Proficient with MS Office, Windows suite and all around tech savvy” is hopelessly vague and uninspiring. Tech savvy according to who? Your grandma? Oooh, you know Windows. So does my dog, and he died six years ago.

Now, if you’ve done amazing presentations in PowerPoint, then say that. “Created three presentations in PowerPoint in a year for area sales directors.” That says much more than “I know Office.”

Remove fluff. Add numbers and details. That’s 90% of the battle right there. If you can do that well, you’re ahead of the pack.

Looking for ideas on how to add details to your bullet points? Post them in the comments and I’ll see if I can help.