Scott Porad

After the last two days of posts about resumes, I thought I would take a moment to outline the hiring process we have at Cheezburger for developers.

1. Candidates submit their resume and answer a brief questionnaire at http://jobs.cheezburger.com.  The questionnaire asks a few simple questions.  For example, for a senior position we ask years of experience with C# because it’s really easy to screen out the resume-spam-blasters who apply for every position with out reading the job requirements.  We also as a few logistical questions, such as “when can you start?”.  In total, the questionnaire has less than 10 questions.
2. We screen resumes looking for candidates that meet our core requirements in terms of skills and experience.
3. Candidates who pass our screening are invited to submit a coding sample based on a simple project spec that we provide.  For a qualified candidate, we expect that the project should only take a few hours.
4. As candidates submit their sample projects, we review their code to get a sense of their overall coding ability and style.
5. Candidates who’s coding sample is satisfactory then enter an interview loop where the will meet face-to-face (or in some cases via Skype, depending on the locale) with four people from our team: one senior developer, one other developer, one product manager and me, the CTO.
6. The two developers are tasked with assessing technical skill.  In other words, does the candidate have the chops to do the job.  The way we think about this is that having the skills gets you “in the door”…
7. …then whether or not you’d be a good fit for our team gets you hired.  The PM and I focus primarily on this assessment, although the developers consider this as well.  When we look at fit, we look for two general things: a) does your work style fit with our work style, for example, preferring Agile over Waterfall, and b) does it seem like you’d be pleasurable to work with 8 hours a day.
8. Finally, if the candidate has made it this far—meaning that all four people who have interviewed indicate we should hire—we check personal references.

There are occasions where we vary from this process—for example, when hiring a short-term contractor.  In general, however, we like it because we get to look at three examples of code (the coding project, plus two developer interviews where the candidate is asked to write code), and four face-to-face meetings to assess personal/culture fit.

The feedback in comments and on Hacker News to yesterday’s post about getting your resume noticed was really spectacular.  I don’t purposefully write controversial posts, although I enjoy it when a post is controversial.  I find the exchange of ideas exhilarating.

I encourage you to read the feedback, although my analysis is that it fell in two general camps:

• Sometimes it’s culturally appropriate depending on geography and industry.
• It doesn’t make sense to screen based on a photo when what matters are skills.

As I see it, these two points of view are opposite sides of the same coin: what may be good for the candidate (the first point) is not necessarily good for the employer (the second point).

My intention when writing the post was to address candidates—to explain something that, as an hiring manager, caught my eye.  Although, as I said:

…it wasn’t his pretty face that was the deciding factor; he was a very qualified candidate who would have passed our screening regardless.

However, I was influenced by the commenters who advocated for anonymous resumes and screening.  That is, developing a process to screen resumes that don’t have names, addresses, photos or any other information that which might indicate anything beyond skills and experience.

As a candidate, I’m not sure that anonymous screening would be in my favor (see: yesterday’s post).  Yet, having considered the notion, as a hiring manager, this makes sense because I really do want the most qualified candidates.  The time to assess corporate culture fit is after having identified (through screening and interviews) the candidates who are most qualified to do the work.

I may experiment with this (anonymous job applications and resumes) at Cheezburger, although I haven’t determined exactly how just yet.  If you have suggestions, please leave them in the comments.

In the last few months I’ve reviewed dozens and dozens resumes for potential developer candidates.  After awhile, they start to get blurry and blend together.  I don’t want to miss good candidates, so I only review a handful at a time in order to stay fresh.

But, not all hiring managers might be as conscientious as I am, so this is pretty bad for the candidates: they want to get noticed, but they’re blending in.  In today’s job market, that’s not what a candidate needs.

Today, I saw a new technique for getting your resume noticed.  Something I’ve never seen before, so elegant and simple…literally anybody and everybody could do this and improve their resume in a matter of minutes.

The candidate included a picture of himself.

As you can see from the image below (which is actual size) it was just a small head-shot taken with a digital camera.  Nothing fancy or garish.

In fact, the rest of his resume was pretty ordinary and tedious.  Yet, the impact of that photo was immediate and powerful.

Automatically, the picture caused me to form a personal connection with this candidate.  For better or worse, in my mind, I could look at his face and imagine what it might be like to work with him.

In the end, from a set of 30 resumes, his was one of 8 that were selected for the next phase in our interview process.  But, it wasn’t his pretty face that was the deciding factor; he was a very qualified candidate who would have passed our screening regardless.

There’s a counter-argument: wouldn’t it be awful to be judged by your photo in the blink of an eye?  Yes, it would be, but I think the gains out weigh the risk.  To me, personal connections are priceless, so the value of the image is entirely worth it.

I am reminded of how Malcolm Gladwell wrote about the power of first impressions in his book Blink.  The core assertion of Gladwell’s book is that:

There are lots of situations…when our snap judgments and first impressions offer a much better means of making sense of the world.

This candidate was able to tap into the power of first impressions by using the simple feature of Microsoft Word that allows an author to embed an image into a document.  As a result, he strengthened personal connection, and increased his chance of being hired.

Recently, I’ve had conversations with Marcelo and Jennifer at Seattle 2.0 about the Seattle Startup Index.  Often they receive complaints because they don’t include blogs or content sites in the index, and just about everyone they deny says “but you allow Cheezburger!”

I can understand why an outsider would think this because I often describe Cheezburger as a media company, and our product as “a collection of entertainment sites”.  Many consumers and people outside the company see Cheezburger as just a blog.  Nothing could be further from the truth.

The business story is that of a media and content company, but it’s built upon innovative use of technology.  Our technology story has four pieces:

1. Dealing with scale and volume.
2. Creating a product where audience drives the content that broadcast to them.
3. Building a platform where we can launch new sites very inexpensively.
4. Building our product by using the most progressive product development practices.

All of this technology is in support of a business.  That’s right…the technology is just the means to an end.  Our mission is for that end to make everyone happy for five minutes per day.  And, we’ve developed some pretty innovative means to do that.

For example, one component of our technology strategy is to rely on commodity software as much as we can instead of “rolling our own” in-house.  Instead of spending time to build a display layer for our product we chose to use commodity software—Wordpress.  Wordpress is commonly used as a blogging tool, but is easily adapted for use as a general purpose content management system.

We chose this route because we believed that our technology resources were best put toward more difficult and valuable problems.  In many quarters, this is considered a “best practice”.  I cringe to use such consulting-speak, but we’re often faulted for this choice.

On the other hand, if we had spent time building our own display layer instead of figuring out how to moderate high volumes of content we might have not ever reached this point.

How much content?  Every day, we receive 15-20k submissions that are each moderated and evaluated by our team and community, then the top content is published back onto our sites.  This is not a trivial task, and for it we need a system that can’t be bought off the shelf like Wordpress.  This is software we wrote to meet the unique needs of our business.

But, really…does software to support  a business really a technology company make?

I’m not intimately familiar with every company on the startup index, but my personal opinion is that very few of them are actually technology companies.  Perhaps I’m old school on this, but my view is that a technology company is in the business of creating and selling hardware or software.

Most “technology startups” today don’t do that—they use technology to make existing business models (or social models) easier-better-faster-cheaper.  In other words, they use technology, like we do, as a means to an end.  I’d argue that if smoke signals were easier-better-faster-cheaper than the web to achieve the end, then that’s what would be used.

Finally, I would be remiss if I didn’t mention our software development practices.

Cheezburger is pioneering and embracing the most modern and progressive development practices.  The piece I enjoy highlighting is a continuous deployment system we’ve built that—with the exception of one human checkpoint—performs a completely automated commit-to-deploy cycle.  (We don’t trust our robots completely…yet.)

To achieve this we have written several pieces of proprietary software that I consider some of our core competitive advantage.  One of them has to do with how we manage our database schema and allowing us to do upgrades on the fly with out downtime.  I’m not going to get into the details of how it works, but a) I’m certain it would be a profitable business if we sold it independently, and b) it’s a beautiful piece of software that makes my geek-engineer heart go pitter-patter with glee.

This post is quite a bit longer than I planned, so I’ll stop beating you over the head with why we’re a technology company.  Oh, wait…we’ve also developed a social network at cheezburger.com, a public API, and we’re working on our own iPhone and iPad apps as well.  (And, as soon as I can hire a developer with the right experience, we’re going to build a Facebook app too!)

So, as you can see, the technology story never ends…

I am a huge proponent of test automation.  That is, having robots that exercise the code to verify that it’s working as expected.  There are numerous and endless reasons for why test automation is important, but I’ll leave it up to you to search the Interwebs and learn why.

In an automated test environment, it’s important to understand how much code is covered by the automated tests.  Knowing the portion of code that is covered influences trust in the automated testing, and how much manual testing is needed.

There are tools that will do this for you called “code coverage” tools.  (For example, at Cheezburger we use a product called NCover.)

Typically—and forgive me for the gross oversimplification—these tools watch your code while the automation is running and keep track of which lines were executed and which weren’t. The executed lines are considered “covered” and the others are considered “uncovered”.  As a result, what you end up with is a code coverage ratio:

code coverage ratio = covered code / total code

Unfortunately, using a code coverage ratio is not the best way to measure test coverage effectively, and many teams make this mistake.

To understand why, back up and think about the goal of measuring test automation code coverage.  The goal of test coverage is to ensure that all your code is covered.  In other words, that you have zero uncovered code.

When measuring coverage by percentage, it’s easy for the code coverage ratio to look like you’re moving in the right direction when you’re really not.  In other words, yesterday coverage was x%, and today bunch of code was added, and coverage is still x% (or greater than x%), so we’re all good.

But, you’re not…let me illustrate by example: say for example on Monday you have 50% code coverage.  Then, on Tuesday you write a new feature which adds a flim-flam to your wiga-magig.  After you introduce the new feature, you run the coverage report and see that your new code coverage is 51%.  Hooray…the code coverage is moving in the right direction!  That’s good, right?

It is good, but it’s also deceiving.  Let’s look more closely at our codebase:

   Day  LOC*  Covered   Uncovered   Ratio
   Mon  1000      500         500     50%
   Tue  1100      560         540     51%
   * - LOC = Lines of Code

On Tuesday, when you wrote your new feature, there were 100 new lines of code introduced, a 10% increase in the code base.  And, most of those lines of code were covered by automated tests.  But, there are still 40 lines that are uncovered.  In other words, even though your code coverage ratio increased, you moved further away from the goal of zero uncovered lines.

So, what’s the right way to do this?  If the goal is to have zero lines of uncovered code, then the correct metric to monitor is…the most effective way to measure test automation coverage…here it comes…wait for it…lines of uncovered code!

Notes:

• For the purposes of illustration, I used lines of code.  There are more precise metrics than LOC, such as methods or, my preferred, symbol points.
• Also, I do know that coverage isn’t everything.  When thinking about test automation there is “quantity” and “quality”.  Coverage tells you quantity—how much of the code is covered?  It does not tell you quality—are the automated tests any good?

A quick post to update you on my whereabouts.

I’m here as I ever was.  I took a vacation at the end of May, and that got me out of rhythm.

Plus, work has been crazeee bizzy lately.  Did you see that a profile of Cheezburger was the #1 most popular article on the New York Times web site?  Check it out:

I read the New York Times every day, so that feels pretty darn good!

Anyhow, I’m back in the saddle now, and am going to work at getting back into my daily rhythm.

• Google style perks at your scrappy startup? | Jackson Fish Market
  (tags: Culture)
• Your company culture is a meaningless platitude
  (tags: Culture)

I come from the product development side of things, which means that generally speaking I’ve spent my professional career surrounded by people who don’t have a lot of respect for “the idiots in marketing”.  As you, my loyal readers know, I have outgrown that mindset.

If I were to describe the job of marketing it is to find efficient ways to get the product in front of people who will actually pay.  So, that implies three tasks, none of which are easy.  Let’s break them down.

People who will actually pay — maybe the hardest of the three for a startup, and this is the question I always ask entrepreneurs: Who is going to buy your product? I have a friend who has built a great product, but his startup doesn’t really know anybody who will pay for it.  (Actually, that’s only partially true…it would be an excellent acquisition for one of about 3-5 companies in the entire world.  If they can get one of those firms to bite, then they’re golden.)

In front of people — this is what most people thing of marketing as…getting stuff in front of people, i.e. buying advertising.  But, the thing is, just buying advertising basically doesn’t work unless you’re selling something to a mass/mainstream market which most startups are not.  Most startups are targeting a niche, and finding those people is really tricky.  See the previous point: finding just one of them is tricky…try finding many, many, many.

Efficient ways — now, here’s the real trick: in theory, you could just buy SuperBowl ads, but that would be inefficient.  In other words, you’d probably spend a lot more than you make.  So, not only does the marketer have to find customers, and figure out how to sell to them, they also have to do it for less money than they make on a sale.  Some companies can’t do that, so they trick themselves into “lifetime value”.  (I suppose that’s not a trick if can retain your customers and have enough money to hang around for a lifetime.)

So, there you have it, the three-bladed gauntlet of marketing.  Now, think about your job for a minute…would you want to trade it for that?  Sure, maybe at a well-established company that has many customers, that’s not so tricky.  But, what about at that brand new company with the brand new product that nobody has ever heard of before?

My grandma turns 91 today.

Ninety One.

Just think about how much has changed in 91 years.  Every single piece of technology that is being used for me to create this blog post, and for you to consume it…not a single one of them existed then.

There were no phones, smart or otherwise, no cars, no NFL, no…I wonder if they had radio in 1919?  Sure, they must of had radio.  Yes, absolutely they did.  But they didn’t have all these fancy kitchen appliances or fancy automobiles.

And, as far as I can tell from TV (which they didn’t have back then either) all their clothes were shades of grey.  Can you imagine that?  My grandma didn’t even have color!

Awhile ago I asked my grandma about The Great Depression and she said, “well, it didn’t seem as bad as it does now because nobody had as much of anything back then”.

More recently, she told me that her grandfather (my great, great grandfather) had a men’s clothing store.  I did not know that.  When I asked what ever happened to it she replied, “it went out of business in The Depression, [you idiot,] what do you think happened to it?”

My grandma comes from a different era; and era where ladies were far too polite to actually say, “you idiot”, but her tone of voice subtly conveyed the message just the same.

Thing is, I wonder if they had more happiness back then.

Something I’ve been thinking about a lot lately is how I spend my free time.  Or, more specifically, the activities I do when I want to relax.

What I’ve noticed is that my relaxation activities are mainly “consumption” activities—watch the tube, read a magazine or a book, surf the web.   On the other hand, it occurred to me that many people relax via “production”—by writing, or painting, or working in the garden.  I wish I were more like that.

So, I’m trying to find ways to relax by producing, as opposed to consuming.  In other words, by being a light to the world, as opposed to being a black hole.

This is harder than it seems because most types of production seem like work, although the other day I wrote a chapter in my book instead of reading a magazine.  It felt good to do that.

One thing I personally struggle with is “screen time”.  I work in front of the computer for most of the day, and many of the relaxation activities I do—consumption or production, regardless—involve being in front of a screen.  Working on my book—screen.  Watching a movie—screen.  Except for gardening, this is quite a challenge.  (Actually, there’s more than gardening…there’s exercise, I suppose.)

So think about that: how to produce without being in front of a screen.  These days, that’s harder than it seems, and I’m not sure that’s a good thing.