Don't let skills define you. This past Friday, at my Salty Legs Career Club, Stephen Balzac of 7StepsAhead presented what he has learned about how to "Interview for Success." Steve did a particularly effective job illustrating how to avoid being trapped in debates about skills.

It's hard to convince an interviewer you have the best skills, because if you allow skills to define you, there will always be someone better. I'm looking at a job posting right now that calls for a mysql DBA--and despite the fact that I have been working with databases since 1986--on an ancient system known as Ingress...despite the fact that I walked into one company and migrated their mysql database to Oracle...despite the fact that I set up Microsoft SQL Server replication, stored procedures, triggers, log shipping...and then transfered my knowledge over to mysql in my last job...I just KNOW there are tons of people out there who would make better mysql DBAs. I never took a test.

My skills do not define me. They are tools I use to solve bigger problems...problems like how to keep the business running without hiring more people. Or how to get a prototype from a developer's laptop onto the first two enterprise customer's websites before they run out of VC money. Or how to launch a startup within a big company without paying licensing fees for Microsoft SQL Server. Oh, yeah, needed to relearn Linux systems administration and virtualization too...no problem. Point is, I now realize my resume is TERRIBLE...listing all those skills I picked up when really, what I should be talking about are the incredible results I achieved--how I was an unstoppable force of technological scrappyness...but I digress.

Steven's talk is worth watching. You may disagree with some of his more "aggressive" recommendations insofar as questions to ask or the willingness to walk away from some situations. But the perspective is helpful to think about how you present yourself and how you can take control of an interview to present your strengths most effectively without becoming entangled in a debate over technical details or making the mistake of jumping in and solving problems before you know what the interviewer is really looking to solve.