Archive for August, 2011

“Building and Managing a Project Community with Github”, St. Louis, MO, 2011-09-03

August 31, 2011


On Saturday, September 3rd I’ll be presenting “Building and Managing a Project Community with Github” at ArchReactor, a hackerspace in St. Louis, MO.

ArchReactor
Jefferson Underground Building
2400 South Jefferson Avenue
St. Louis, MO 63104
http://archreactor.org/location

There will be a social hour from 4:00-5:00pm, and my presentation starts at 5pm sharp. I hope to see you there!

Advertisements

Your github account is not your portfolio, but it’s a start

August 24, 2011

Gina Trapani started a Google+ thread about using Github as a portfolio of your work to show potential employers. This in turn was prompted by a blog post by PyDanny titled “Github is my resume.” It’s a great idea, but it’s only a start. Your portfolio should be more curated than that to be effective.

I shouldn’t complain too much. Far too few job seekers consider the power of showing existing work products to hiring managers. That’s probably because so few employers ask to see any. In my book Land the Tech Job You Love, I cite Ilya Talman, one of the top tech recruiters in Chicago, estimating that only 15% of hiring managers ask to see samples of work.

Consider the manager looking to hire a computer programmer. She has hundred résumés from respondents, all claiming to know Ruby and Rails. She knows that anyone can put Ruby, Rails, or any other technologies into a résumé without knowing them. Even well-meaning candidates might think “I read a book on Ruby once, and Rails can’t be too tough, so I’ll put them on my résumé.” Looking at sample code is a great way to separate the good programmers from the fakers.

Since creating a repository of someone else’s good code is only slightly more involved than putting “Ruby on Rails” in a résumé document, a good hiring manager will ask in the interview about the code. When I interview candidates, I ask for printed code samples of their best work for us to discuss. Pointing at a given section on the paper, I’ll say “Tell me about your choice to write your own Perl function here instead of using a module from CPAN“, or “I see your variables seem to be named using a certain convention; why did you use that method?” In a few minutes, I can easily find out more about the candidate’s thought process and coding style than a mile-long résumé. This method also exposes potentially faked code.

So as much as I applaud candidates having a body of work to which they can point employers, simply saying “Here’s my Github repo” is not enough. The hiring manager doesn’t want to see everything you’ve written. Although everyone is different, she probably wants to see three things:

  • quality of work
  • breadth of work
  • applicability to her specific needs

Most important, she doesn’t want to go digging through all your code to find the answers to these questions.

Consider my github repository as an example. There are 28 repositories in it. Of these, nine are forks of other repos for me to modify, so clearly do not count as code I’ve written. Three repos are version control for websites I manage. Some are incubators of ideas for future projects that have yet to blossom. My scraps repository is a junk drawer where I put code I’ve written and might have use for later. How will an interested employer know what to look at? It’s arrogant and foolish to tell someone looking to hire you “here’s all my public code, you figure it out.” It’s the RTFM method of portfolio presentation, and it doesn’t put you in the best light possible.

For an effective portfolio, choose three to five projects that show your best work, and then provide a paragraph or two about each, describing the project in English and your involvement with it. There is literally no project or repository, on Github or elsewhere, about which I can say “This work is 100% mine.” Everything I’ve ever worked on has had work contributed from others, and the nature of those contributions needs to be disclosed upfront and honestly.

None of this is special to Github. There are plenty of online code repositories out there, such as Perl’s CPAN, which can act as a showcase for your work. Of course, you can also create your own online portfolio on your website as well. The keys are to highlight your best work and accurately describe your involvement.

A common complaint I hear when I discuss code portfolios goes like this: “Most of my work is private or under NDA, so I can’t have a portfolio.” Hogwash. You can go write your own code specifically to show your skills. If your area of expertise is with web apps, then go write a web app that does something fairly useful and publish that as your portfolio. Assign it an open source license so that others can take advantage of it, too. You’ll be helping your community while you help your job prospects.

Do you have an online code portfolio? Let me know in the comments, and include the URL for others to see.

Should I put ____ on my résumé?

August 15, 2011

I read Reddit’s résumé subreddit regularly, and it’s one of the most common questions asked: “Should I put such-and-such item on my résumé, or leave it off?” The variations are endless:

  • Should I put a job on my résumé that I was at for only three months?
  • Should I put my college work on my résumé, even though I only was in for two years of a four-year degree?
  • Should I put my hobbies on my résumé?
  • Should I put my volunteer work on my résumé?
  • Should I put my high school education on my résumé?

The answer is the same for each of these examples: It depends on the job for which you’re applying.  Here’s how to analyze the situation and make the right choice for the job.

First, remember that the purpose of a résumé is to get you a job interview. Therefore, the question you have to ask yourself is “Will this piece of information help convince the reader to call me in for an interview?”  If it won’t, then leave it out.

Second, every position is different, so you must ask the question as it relates to the job for which you’re applying. You don’t have a single résumé that you blast out to the world. Consider every point on your résumé as it applies to the job for which you’re applying. For example, you probably don’t want to put on your résumé that you play guitar when applying for a job as a system administrator, unless you’re applying for that sysadmin job at a music publishing house.

All that said, here are a few items that you should almost definitely leave off a résumé:

  • “References available upon request,” which is assumed and is therefore noise.
  • A list of references, because these will be asked for at a later point in the hiring process
  • A photograph, which is inappropriate in the United States

Band naming made easy

August 9, 2011

My friend Rob Warmowski has a new band named Sirs. They have a show coming up with another band opening for them. The second paragraph is key.

Join Sirs Saturday, August 20 at 4 PM with a live performance to celebrate the release of our 12″ EP “Boo Hoo”. Where better to do this than at Saki, the fine purveyor of records located at 3716 W. Fullerton in Chicago? Nowhere, that’s where.

Opening band: Small Trabajo. (Note: nobody in Small Trabajo yet knows that their name is Small Trabajo. We were told by store staff that the band, being very new, was having a hard time coming up with a band name. Hearing this, I went to the first Captcha I could find (http://captcha.net) and solved the problem immediately.)

The Internet has a solution for every problem!

No, you can’t ask about money in the job interview

August 2, 2011

So often I see it posted to reddit: “When do I ask about money?” You don’t. You don’t ask about money in the job interview. You wait until the company brings it up, often in the form of a job offer. There’s a time and a place for everything, and the time and place for compensation discussion is in the job offer, or when the company chooses to bring it up.

When you go into a job interview, your focus must be on the company’s needs, or what work the hiring manager wants you to do. You want to talk about what you can do for the company, not ask about what they can do for you. Asking about salary, benefits, vacation, or other forms of compensation tells the interviewer that you’re more concerned with what’s in it for you, rather than how you can help her. Whether that’s true or not doesn’t matter. You still run a risk of coming across that way.

(This is also part of why an objective is the worst way to start a résumé, because it says “Hi, I’m so-and-so, and here’s what I want from you.”)

The goal of a job interview is for you to get a job offer, or to move closer to getting one. If you don’t get the job offer, it doesn’t matter how much the job pays.

An interview isn’t a one-sided affair, of course. It’s also about you finding out about the company, about worklife, about the sorts of projects you’d work on, because these all fit into things of benefit to the company. Compensation, however, is a one-way benefit to you. What if the interviewer doesn’t discuss salary? Then you just wait for the second interview or the job offer, where the specifics of compensation will all be laid out.

People have countered my stance on this with “I just want to know what it’s paying so that I can save time for both of us by not going through an interview for a job that’s not going to pay enough.” That’s what we programmers refer to as a premature optimization. Just as it doesn’t matter how fast your program runs if it gives the wrong answer, it doesn’t matter how quickly you get through the hiring process if you don’t get the offer.

Have some patience. Focus on selling your skills and experience to the interviewer. Talk to the interviewer about her problems and how you’ll solve them. And don’t ask about compensation.