How to get a Great Tech Job

This post is a guest post from Sandy Smith, a hiring manager and PHP developer at Forum One Communications in Alexandria, VA. It was originally an email to a mailing list in response to a job ad posted by a recruiter. The job requisition was worded in such a way to make it sound like the recruiter wanted someone with every web-tech skill and a “mastery” of it for about $75,000 (USD), a salary that is extremely low in the Washington, D.C. area. His response was so good that I asked if I could reprint it. He obliged. Follow Sandy on Twitter at @SandyS1 or at his blog.

So, random thoughts from a hiring manager, speaking entirely for myself, not for my company (My team has no open positions, though Forum One is hiring):

1) This is perhaps not the best job ad in history but it is not that bad. “Mastery” is a very vague word, and nobody wants to advertise for someone who’s “mediocre” at PHP, etc. So cut them a little slack that word, which seems to be the big problem for most people.

2) Learn to read job ads for what they really want. They almost all must pass through an HR person who is NOT a programmer, and sometimes vetted language is helpfully “punched up” by some editor before going out, not realizing they’re effectively changing the requirements by using more “positive” and “colorful” language. I’m going to use “needless” “quotes” some more, “here.”

3) When we’ve worked with recruiters–and I assure you as a hiring manager I see the same ratio of good/bad ones (hint: don’t call me to ask about a position and then demonstrate that you never bothered to visit the company website to look at the description we have posted–and hint: when I say I don’t deal with recruiters and you’ll have to talk to the same HR person who didn’t call you back the last time, you not getting a gig doesn’t mean I’m suddenly empowered to deal with recruiters…so…don’t call me), we’ve usually just supplied a position description to them. They didn’t alter it much, so the wording may not have changed much if someone from the hiring org posted it themselves.

4) The years of experience and the main technologies mentioned are the important parts of a job ad, as are some of the “types of work environment” experience credentials. The extra stuff is usually requested by the HR person to give them a way to sort through the avalanche of applicants, most of whom are barely if at all qualified, who arrive in their inbox. So if there is, as I once abused a quasi-governmental agency for requesting, a ‘magical pony who craps rainbow sherbet is flitting around a meadow somewhere thinking to itself, “You know, I think I’d rather have a government web job,”’ they can find it.

5) The key word is “Drupal.” They’re not really asking for somebody who can invent a new algorithm better than quicksort or even bridge C++ to Ada to PL/SQL to PHP or implement a perfect Strategy pattern using techniques borrowed from OCaml…they’re asking for a PHP web developer who can configure, theme, and write some custom modules for Drupal that might work with some outside systems that others seem to be responsible for. Your best bet is to send in a competently formatted (and spell-checked–seriously, do not put “detail-oriented” and have spelling errors) resume and a cover letter addressing the important points and showing how your experience matches those points.

6) And yeah, if you can’t hang some Javascript and CSS with XHTML onto those template files, then you’re probably not right for the job, and you should move on. And start Googling some tutorials because I know I expect basic Javascript, CSS, and X/HTML out of even backend PHP developers.

7) There are a lot of people applying for much lower-paying jobs, but quite frankly, there are a lot of people who believe in spamming every open position they find with the same resume regardless of whether they’re qualified or not. Trust me, it’s really obvious to the people on the other side when you do this. You will get much better results if you target your application to the position, and skip ones that you know you’re not really right for. I realize this is hard when you’re not currently working, but a better effort on likely positions will get you more than minimal effort on every position you find.

8) Not every technical team is that great, and even if they are, they aren’t always great at finding the right people for the job, as the temptation is to hire someone like yourself, because hey, you’re awesome! Even if someone like yourself isn’t really right for the job. It’s not smart, but it’s really human. So while I have many issues with recruiters, I don’t think you can always lay the blame at their feet for not making their clients smarter. Who among us hasn’t had to swallow our pride and do something kinda dumb because the guy with the money said he didn’t care, he just wanted it that way?

9) If your organization is hiring for a PHP-centric position and you haven’t posted the job ad here–and there’s no legal/contractual reason you can’t–for heaven’s sake, why???

10) None of this is to suggest that recruiters don’t have problems of bullet-point matching that other people have brought up, or that they shouldn’t match candidates to positions using something better than what any random HR person can do in order to make them worth the money.

Photo by Utopian Branch Library

Buzz Kill

By now, if you follow the technology world at all, or if you use Gmail, you’ve probably noticed a new thingy released by Google in the last few days. The thingy is called Google Buzz and it is billed to be a “status update” tool to allow your friends to know what you’re up to?

Sound familiar? Yeah, it’s supposed to be going after Twitter or some nonsense like that.

I enabled Buzz on my Gmail account and then promptly disabled it (you too can disable it, if it’s already turned on for you, by clicking on the “turn off Buzz” link in the footer of your Gmail account).

I’m going on record today to say that Google Buzz is and will continue to be an absolute failure. The reasons why are fourfold…

No one cares about the Google community

This thing is all about tying the Google community together, though they do have support for Twitter and Flickr as well because, well… no one can ignore those massive communities and have legs for the long run. People care about the YouTube community (a Google property). To a lesser extent, people care about the Blogger community (a Google property). No one cares about the Gmail community. It’s email!!! It’s not about community, it’s about utility and communication. Not community. I get spam in my Gmail. I get business conversations in my email. I get a searchable index of messages sent back and forth over the last five years in my Gmail. I don’t get community in my Gmail. The only community feature in Gmail is Google Talk and I don’t use that in Gmail. I use it in an IM client (Adium).

Google is too spread out to worry about community. They have products to meet needs and diversify web experiences, but their forays into community have sucked. Badly. Last time Google’s OpenSocial was a factor in the collaborative, community space was… oh, well, never. That’s dominated by Facebook. Not Google. Last time Picasa was an actual factor in the photography community was… oh that’s right… never. That’s controlled by Flickr.

And the next time Google tries to be a player in the “status update” community will be… oh, that’s right, never. That’s because Twitter dominates. Just ask Oh, and Facebook.

Friendfeed is still something small and irrelevant

Why do I bring up Friendfeed? Well, my argument against Friendfeed still exists. Even Louis Gray, one of the biggest historical champions of Friendfeed, acknowledges that it remains a small community. It never has and never will go mainstream. So why has Google essentially ripped Friendfeed off and expect different results?

Comment? Like? Sounds familiar…. Oh, Facebook and Friendfeed do that.

Buzz is insecure

It’s well documented at this point that Buzz is actually pretty insecure. Because it operates out of Gmail, it assumes that your most frequently emailed people should automatically be friends. Except that that assumption is inherently insecure because friends are publicly viewable. Take these hypothetical situations for instance:

  • Bill has been corresponding with a major possible client under NDA. For any number of reasons, the communication should not be revealed to the public. Yet, due to the volume of email between Bill and his contact, his contact is automatically made a Buzz contact.
  • Kelly is negotiating an acquisition of a company. If this information were public, the deal could be off.
  • John is trying to take his wife on a big, secret getaway for her 40th birthday. In emailing with a variety of resorts over the period of several weeks, those resort contacts become part of John’s publicly viewable community.

Are we seeing the problem here? This is like Facebook Beacon all over again.

Why add more workflow and more social networks?

The argument has been made in favor of Buzz that Google has a huge Gmail userbase to jump off of. While this is true, this is one more area of workflow for users to utilize. Why do it? We have YouTube and Flickr and Twitter and Facebook? Do we really anticipate Buzz being added to the repertoire? I think not.

Buzz will have the same result as most other social networks: it will die. Very few have legs because very few are innovative and do new things. Twitter was an accidental success because it innovated on the concept of microcontent over SMS… yes, that’s how it started. Buzz is just one more has been and offers nothing new. It will stay in the bowels of early adopter-hood until it is forgotten.

That’s my story and I’m sticking to it.

Update: VentureBeat reports that Google has tweaked their privacy settings.

Do Not Lock In To One Device Lest You Kill Your Company

It’s funny. Comical even. A few weeks ago, I wrote that The iPhone is to Smartphones as IE6 was to Browsers. Most of the readers of that article agreed with me but almost all had a “but, but, but…” argument. This is because the iPhone is one sexy beast to users, even though AT&T can’t seem to support the iPhone, as we also noted.

This is a comical observation because my position was endorsed (if not directly) by Peter-Paul Koch who daintily comments that “[He] will shout at web developers who think that delicately inserting an iPhone up their ass is the same as mobile web development.” He goes on to slam the web development community to catering to the iPhone in the same broken-record way that web developers catered to IE6 ten years ago.

Photo by Matt Buchanan

And adding insult to injury, the Guardian also picked up that story and offered their own ringing endorsement for both Peter-Paul and my perspectives.

I just got off the phone with an unnamed entrepreneur who wants to build a product that, while looking to the future and planning to diversify over a variety of products, looks at Apple’s forthcoming iPad as the launch device. I will offer you the same advice I offered him as well as the same advice I offer to iPhone only products like Gowalla.

If you want to start on the iPad, fine. You better be damn sure you’re ready to diversify quickly. I don’t care if you put it on a non-touch device like, oh I don’t know, the web with a normal browser on a normal computer… do not disenfranchise users. Peter-Paul Koch notes, in the article I linked to above, that the iPhone carries only 15% of the worldwide mobile market. Yet it gets an insane amount of attention as if it was the most important product ever created.

Newsflash… it’s not. It’s not even close.

In fact, it’s still not a business class phone (with rare exception). And in fact, developers continue to ignore other platforms… like the BlackBerry.

Sidenote: It’s okay to have a mobile web interface but don’t lose the forest through the trees. Users will feel like second-hand citizens if you don’t pay attention to their needs.

Mobile developers: Think before you develop only for the iPhone or only for the iPad. Entrepreneurs: Think before you start a company or launch a product made exclusively, or designed with a business model only for the iPhone or the iPad.

HipHop, PHP, and the Evolution of Language

A lively little discussion developed over the past few days on the DC-PHP developers mailing list. We have a very active developers group here in the DC area – much larger than most cities, in fact. Part of what makes our group great is the diversity of background and experience that is in the group.

This was front and center over the past few days when one of our members, Hans, offered his opinions on Facebook’s new HipHop for PHP product. We have already expressed our intent to help make WordPress compliant with HipHop, something that will be beneficial to major WordPress sites like TechCrunch, Mashable, VentureBeat,, the NFL Blogs, the NY Times blogs, the Cheezeburger network (LOLcats, FAILBlog, etc) that carry large amounts of traffic. I hope to be able to consult with some of these organizations on moving into a HipHop system once my head is wrapped around it and WordPress is compliant.

Photo by Josh Hunter
Photo by Josh Hunter

Hans is an extraordinary developer. I have never met him personally, but his depth of knowledge on issues of security and scalability is downright frightening. He offered his own opinion of HipHop on the mailing list and so I’m going to pick on him a bit:

This HipHop thing is interesting, perhaps in much the same way as HipHop music: it feels like a hack. — And I mean that respectfully in both cases; I like hip-hop music, and appreciate how it pays homage to R&B roots, remixing/reinterpreting them, etc; and I think that the idea of taking one language and building it out to something else is also something I should support. After all, I’ve embroiled myself in code generation tools (e.g. Propel) that are operating on the same philosophical groundwork. But I also believe that there’s a general rule like “if you need code generation, there’s something wrong [in your design or in the tools you’ve chosen or …]” … so those tools also feel like hacks.

In all of life, there is an evolution that happens. One iteration of something becomes better with improvements over time. This has happened on a micro level inside PHP. Without PHP 3 there would be no PHP 4. Without PHP 4, there would be no PHP 5. Ben Ramsey talked about this evolution before Christmas.

Why is it a hack to improve upon the tools used with a language? Is it a hack to use Memcached with PHP? Is it a hack to run on nginx instead of Apache or to implement FastCGI? All of these are third party software or extensions outside of PHP. So how is HipHop any different?

That’s all fair, but I feel like the problem here is that somewhere a long, long time ago, Facebook *must* have realized that they were going to have scaling problems. Long before they started having a problem, someone *must* have thought “maybe a compile-at-runtime language isn’t the right solution here”. I guess to me this cross-compiler is just a public way to admit that PHP is not the right tool for the job, but they’re stuck with all these developers that only know PHP so it was somehow cheaper to engineer a way to change PHP to C++ than it was to retrain developers on C++ (or, probably more realistic, Java).

I responded in that conversation with an only slightly edited response. While I appreciate, and always have appreciated, his frank, honest, high level view of PHP, web security, web applications, etc., he strikes me as somewhat naive and puritanical.

What I can say is *I*, along with dozens of other technology people in and out of DC, in and out of PHP, never look at our initial ideas as scaling ideas. We look at them as ideas and experiments to see if they have legs. In fact, I’d go so far as to say it is counter-productive to think about scale before thinking of concievability (is that a word?).

There’s a reason why Rails (God help us) is popular. It’s a great prototyping tool. You stand up an app quickly and let it into the wild to see if it has legs. Does it go? What are the market influences? What are the
pros and cons? Do we have to adjust?

After a concept is proven, then a solid dev team with solid tech leadership brings in their expertise to see if the idea can be built into something sustainable. As a sidebar, please take a read of Brad Feld’s very awesome
post from a few years ago “The first 25,000 Users are Irrelevant“.

My point is, it’s silly and a waste of resources for startup people to start thinking about how big they might get maybe 5 years down the road. I think you’d find out that, in most cases, successful technology, web-based companies happened by some dumb luck. Twitter. Facebook. Name-the-popular-app. Dumb luck.

Hey, I’d even argue that when too much comp-sci brain energy goes into an app, you get things like Wolfram Alpha. Cool. But useless. And not nimble enough to actually do the scaling necessary to need all that comp-sci engineering prowess.

Balance, my friend. Balance.

Facebook (and others) start with PHP because PHP is fairly ubiquitous and easy as pie to drop into production. However, there is a point of no return where you are committed to PHP and that’s where HipHop comes in.

Personally, I wish we had HipHop when I was at b5media. We had a ton of scaling problems with PHP and we were running fully clustered Apache servers (25 deep, if I recall), sharded MySQL across 6ish database servers, and we had massive I/O bottlenecks. We ran eAccelerator and Memcached and had squid-based load balancing and damn if Grey’s Anatomy or the Oscar’s didn’t pin our entire network on more than one occasion. What could have happened with an alternate to opcode caching. What could have happened if I had resources to put on developing C++ binaries of our frequently used PHP libraries.

I’ll tell you. It would have rocked. We were already committed to PHP. We were already committed to WordPress. And when the company started, we were all volunteer resources. There was no assumption that our idea had legs or I think everyone on the team would have quit our jobs immediately and put everything into building that company. It took a year to get there.

This is, for better or for worse, the way companies get started in the real world.

Facebook's HipHop and What it Means to WordPress

This was originally posted on my company blog and reposted here for posterity.

By now, the news has hit the street about Facebook’s new PHP pseudo-compiler technology that is looking set to change the PHP world once again. It is called HipHop for PHP.

Here at Emmense, we build on PHP and more specifically, we build on WordPress. The PHP community as a whole continues to innovate the language and Facebook has been a longstanding member of that community. WordPress stands on the shoulders who have gone before, and there are certainly instances of large-scale installs of WordPress that could stand to use some acceration.

It is our intention, here at Emmense, to support the Facebook HipHop methodology where appropriate. We will be exploring the use and implementation of this technology in the days and weeks to come and will be working to build solutions that leverage it in the WordPress world for our clients. Where possible, our work will be conributed back to the WordPress core where appropriate.

While we expect that many more service providers will likely leverage this technology, we want to continue to lead in the WordPress community in an ever-open exchange of ideas between the PHP and WordPress communities.