Closer To The Ideal

Sarah Lewis has this suggestion for freelancers:

Prove you can follow directions

This is first in the list because it’s the most important advice I can offer you. In my postings, I asked for three specific things:

1. A link to an online portfolio
2. An hourly rate with a tentative time estimate
3. Current availability

You would not believe how many people sent me “applications” without giving me that information.

Listen, if you aren’t willing to read and follow the instructions on a job post, stop wasting everyone’s time. If the instructions are too complicated or you can’t follow them for some reason, the job is probably not a good fit anyway, so you’re better off spending your time finding and applying for a job that works for you.

I’ve my own tip, about those applying to work: do not put anything on your resume that you won’t be able to defend in an interview.

I’ve written before about the stretch when we were desperate to hire people.  There were about 4 years, from the summer of 2004 to the summer of 2008, when anyone with any talent had more work than they could handle. During that time, we struggled with the question: should we hire inexperienced people and train them or should we hire talented people and pay them a lot? We often had to hire inexperienced people because all the experienced people were way too busy. And we learned that, even if we only paid the inexperienced people $10 an hour, they were very, very expensive. First, they took a lot of our time, and second, they made mistakes we then had to fix. For instance, it is difficult to tell a beginner what separates good quality HTML from poor HTML. Generally, they would write poor HTML, and then we would have to fix it.

For most of 2007, one of my main clients was monkeyclaus. After Darren Hoyt had gone back to working full time with Category4, we tried very hard to hire some additional people to help us out. The interviews were amazing. People would claim all kinds of things on their resume that they couldn’t defend when we met for an interview.

One woman said she knew Javascript. During the interview, I asked how well she knew Javascript. She said she’d taken a class in it during 1999 (that’s 8 years previous!). Could she write a single line of Javascript now? Um, no. But, uh, if she started working with it, she was sure it would come back quickly.

One fellow said he knew PHP and MySql. Turns out his experience consisted of a single small project he’d done for fun, at work. He was working as a tech support person at a local community college, and one of his main tasks was to help people when they forgot their passwords. So he wrote a tiny database program into which he could record usernames and passwords and email addresses. This consisted of about 6 screens. The PHP code was unbelievably primitive: he didn’t know what functions were, so when he wanted to break up his code into pieces, he put each routine into its own file, and then he would include that file when he wanted to trigger the code. And all the HTML was hard coded into the PHP. Awful. And the poor guy had no idea how much he still had to learn.

We spoke to a woman who said she knew Java, but had no Java projects that she could point us to, not even little demos on her laptop.

Many of the people we spoke to were just moving past the point of unconscious incompetence. They simply had no idea how they appeared to us.

We spoke to a lot of people who were clearly beginners, yet they claimed to know more technologies than I do. A typical list: Javascript, CSS, HTML, XHTML, RSS, Atom, Flash, ActionScript, Java, .Net, C, C++, Python, Perl, PHP, Linux, MySql, Oracle, Microsoft Server, Windows, Apache, IIS, Photoshop, FinalCut Pro, iMovies, Mac OS, and SOAP.

Wow. I mean wow. If you know all that, you can have my job. You clearly deserve it.

What a lot of beginners seem to do is they include on their resume stuff they were briefly exposed to during some class in college. So if, for one day, they got to write some SQL queries against a dummy database set up in Oracle, they then claimed that they knew Oracle. I think what this approach communicates, more than anything, is insecurity. I realize that it is tough to get one’s career started, but still, you might want to leave off the stuff that you’ve only had a day or two exposure to.

Many of the resumes set my expectations unreasonably high, so that then the actual interview was a disappointment. And when I felt like someone had lied on their resume, I tended to become a bit more aggressive in my questions. At one point Peter Agelasto (who was there for several interviews) said “Damn, Lawrence, I’m glad I don’t have to do an interview with you.”  But I would not have been so aggressive had the resume not set my expectations so much higher than what the  person could defend. An example: if you claim you are programmer, you should at least be able to define what the phrase “object oriented programming” means (bonus points if you tell me there are several definitions, and go on to explain why the partisans of each definition feel so strongly about the issue). If you’re working in PHP, then maybe you haven’t done OOP yourself, and that is fine, but if you’ve never even heard the phrase, then I will doubt if you are intellectually curious about the field that you are attempting to get a job in. At least for me, personally, a lack of curiosity would be a major negative factor.

Bottom line: don’t put anything on your resume that you won’t feel comfortable defending in an interview.