Don’t hire team members like they’re consultants


There’s a problem I keep seeing when helping my clients, providing career coaching to job seekers, and participating in interviews myself: Tech companies consistently take the wrong approach when hiring for new team members.

Let’s set up a couple of use cases…

Comparing apples…

Your product has an urgent technical need. Maybe you need to integrate with a new system which uses unfamiliar protocols. Perhaps a creaky old legacy system needs shoring up or replacement. Or maybe you’ve acquired another company and need to convert their billing system over to use your tooling. Whatever it is, it has to happen and it has to happen now.

What you need is a consultant: Someone who’s intimately familiar with the technology causing your immediate problems. Someone who can dive right in, change some code, then get right out. Someone who’ll take a month or six, make the technical pain go away, and then leave for the next gig.

That’s use case number one.

…to oranges.

Now let’s say your company has an open req. Maybe you’re replacing someone who’s moved on. Maybe you’re expanding the team as the company grows and scales. Or perhaps you’re moving into a whole new product or market area. Whatever your reason for hiring, it needs to happen and it needs to be done right rather than right now.

What you need is a team member. Someone who’s able to collaborate, communicate, innovate, and deliver. Someone who’ll commit to the team and the company, who’s in it for the long haul. Most importantly, you need someone who’s able to learn and adapt along with the company’s needs.

That’s use case number two.

Two use cases, one hiring approach

When the differences between these two hiring use cases are so stark, and when the costs of hiring/firing/replacing a poor choice are so high, why does nearly every tech company hire team members as though they’re hiring a consultant? Job postings focus on the current tooling and products rather than factor in future plans. Interviews focus on the immediate technical knowledge and abilities of candidates, rather than on the candidates’ capabilities for learning and adapting. Companies hire the wrong people for the wrong reasons, then are surprised to find they can’t scale or adapt to meet strategic goals.

There are several reasons why this continues to happen. For starters, very few tech companies are equipped with people who have experience with a proper hiring process. Rather than approaching the process like the complex project that it is and gathering requirements before taking action, hiring managers do the best they can with the little information they have. When faced with an unfamiliar situation, we fall back on what we know. In the case of hiring, this typically means copying and pasting a job posting rather than considering the strategic requirements for a role.

It also means interviewing people for skills they have now rather than for the skills they’ll need in order to move the team and company toward their goals. If you’ve never been trained to think strategically about hiring, you’re unlikely to ask strategic interview questions. Again, we fall back on what we know, and what we know is our own tech stack and our own immediate problems. We ask questions about the things foremost in our minds rather than considering the long term needs of the group. This makes it much easier for untrained interviewers to determine a thumbs-up/thumbs-down on a candidate. Do they know our tech? No? Then they’re not a good fit. The question of whether they can learn your tech never even occurs to us. We’re focused on the now rather than the future.

This short-sighted interview strategy is employed in nearly every tech team regardless of industry and makes a expensive trade: the team’s long-term success for the immediate comfort of the interview committee. Otherwise exceptional candidates are rejected in favour of mediocre ones who have more familiarity with the technologies used but less ability to communicate, learn, and adapt. They interview for consultants rather than for team members and the long-term health of the team suffers.

We can do better

It won’t be easy to do, but this is a fixable problem. You can start it in your team today.

First, give more thought to your job postings. Don’t simply copy and paste from the last time you were hiring for this role. Consider not only what the person hired will do in their first month but also how you’ll need them to adapt and make a difference in their first year and beyond. Craft a posting to reflect the long-term needs of the team, not simply seeking someone to scratch an immediate itch you’re feeling.

Next, take the time to seek out and provide training for those performing the interviews. You probably wouldn’t let your brand new intern make changes to a vital production system without a lot of training, yet we regularly have untrained people perform interviews. As with many other elements of software development, interviewing is a skill and must be learned and practiced. There are people who can provide this training, or you can take the time to learn interviewing skills yourself then pass them on to the rest of the team. Experiential interviewing, bias limitation, and strategic thinking are just a few of the skills required for effective interviewing.

Naturally there are other steps for improving the tech hiring process, but these two would be a very good start. Hiring well requires both intention and attention. Don’t throw away the precious opportunity to build something great by phoning it in and treating a long-term investment in the team like a short term investment in a consultant.

3 ways to improve your hiring process

The new year often brings the end to a lot of finance- or holiday-imposed hiring freezes and a rush to get the hiring process wheels back into motion.

Aside from having done a ton of hiring myself over the years, I recently had the opportunity to help several people through the hiring process at many different companies. This reminded me of some of recommendations I made to my clients when I was a tech/biz management consultant.

What follows are three recommendations for improving hiring at your organization. There’s a lot to be said about each of these topics, so I’ll just hit the highlights. As with most things (including hiring), how much you get out of these recommendations will depend on how much you put into them. Which is to say: Your Mileage May Vary.

These recommendations are written for a tech company audience, but they apply to most every team and industry.

1. Write Better Job Postings.

The majority of the job postings don’t reflect the position being filled. They may share the same title, but the details are lacking or inaccurate. Often they’re copied from a posting written years ago, for a position on which the requirements have evolved but the posting text has not.

Ensuring the text of the job posting accurately reflects the position being filled not only makes it easier for candidates to self-select for interest and qualifications, it also confirms that everyone on the hiring team is on the same page.

The description for the position should be specific, reflecting the job to be done and the work necessary to perform it. Examples of projects on which the candidate may work can make it easier for them to gauge their interest in applying. Also helpful is the name of the position to which this one reports.

The requirements and qualifications listed for the position must be limited to those actually required to do the job. "What-ifs" and "Maybe we could use" qualifications are not requirements. What they are is a sign that the hiring team hasn’t defined what they’re looking for.

If the tasks performed by the role do not require a formal education, either in computer science or any other pursuit, do not list a degree as a requirement on the posting. Including a degree requirement is a lazy shortcut on considering the skills legitimately required by the role. It’s also elitist, typically unnecessary, and discourages highly qualified but un-degreed individuals from applying.

All job postings should be reviewed for gender and cultural biases. Studies show that certain language in postings cause women to avoid applying, which leads to perpetuating the gender imbalance in the tech industry. Tools like Textio and the Gender Decoder for Job Ads can help uncover unconscious and unintentional bias in your job posting text.

2. Ask Better Interview Questions.

For years companies like Microsoft and Google were known for their trick interview questions. Where the big dogs go the little dogs follow, so a lot of companies were soon using this approach to interviewing. It came as no surprise to many when both Microsoft and Google revealed that their studies showed that this type of question did not help them hire better people and that they were discontinuing their use. Your company should follow suit.

Only ask questions which are directly applicable to the job. Real world discussions are more effective hypothetical questions, every time.

These discussions should determine the candidate’s ability to learn, to perform the job, to problem solve, and to get along well with others. Trick questions, inquiries into their personal lives, or those which ask for information which can be found on their resumes are not good questions for an interview.

During the drafting of the job posting you already determined the concepts and qualities which are necessary to succeed in the role. Many of these skills, such as building or using an API endpoint, are not programming language specific. Languages are, relatively speaking, easy to pick up once you’ve mastered your first. Unless in-depth mastery of a language is necessary for the role, avoid language-based questions.

Avoid questions which imply or require a formal education in computer science. For instance: if the candidate is unlikely to write Big O Notation on the job, do not ask about it in the interview. By all means ask about algorithmic complexity and optimization…if it is required to perform the role.

If the role requires that a candidate regularly write pristine standard-library-free code on a whiteboard, include a question about it. But only in this case. In all others, try talking through a recent or current problem the team is solving to see how the candidate will approach it.

3. Standardize The Process.

Most interviews are a bit of an ad hoc process. You see who on the team is available, hand them a candidate resume, and allow them to use whatever questions come to mind. This is wrong.

An inconsistent approach to interviewing will lead to inconsistent results in hiring. You cannot compare candidates fairly if you do not treat them equally.

A better process:

  • Build a team of interviewers who will meet with every candidate. Some people may resist this as a large investment in time keeping them from their "real" work. Usually a reminder that interviewing is also an important part of their duties is enough to quell any objections. However, please make sure to balance their other duties so everything can still be accomplished in a standard number of working hours per week (read: no more than 40).
  • Meet w/interviewers in advance so they all know exactly what the position is and what to look for. To avoid duplication of questions, assign each interviewer qualifications to query and discuss which questions they will use. Please allow them the agency of writing their own questions and using their own voice.
  • Each interviewer must meet with each candidate. They also must ask the same questions of each candidate. Both of these can be difficult to schedule, but are worth the effort. In this way the interviewer has the best idea of how each candidate compares against the others on the qualifications.

Like I said, these recommendations typically apply to all situations. However if they don’t, or if you’d like to chat about how to apply these or other suggestions to your hiring process, drop me a line.

How NOT to Hire an Entirely Remote Workforce

Recently there was an article in the Harvard Business Review about how a particular company hired a 100% remote work force.

I highly recommend hiring a remote workforce. I have a lot of experience helping companies do so and even present talks on the subject. I wholeheartedly agree with the article’s author: there are incredible benefits to supporting a remote workforce.

That said, the Clevertech hiring process as set forth in the article is not only a bad way to interview for and hire remote workers, it’s a bad way to interview for and hire ANY workers. That such poor advice was provided in a publication as well-respected as the HBR is disappointing, to say the least.

From my nearly 20 years of experience in this industry, I cannot see anything in the Clevertech process which can lead to hiring and building more effective remote teams. I would not recommend these processes for any team, and especially not for those which are distributed by default. Instead, the processes set forth in the HBR article would lead to expanding the echo chamber of an organization and blocking the hiring of those with new and potentially challenging viewpoints.

This post will help to clarify why the Clevertech process is not one which companies should follow, either when hiring on-site or remote employees. It is a master-class in how not to run the hiring at your organization, unless, of course, you are looking to minimize the diversity within your company.

Let’s start where the article starts: the job description. The Clevertech approach is to make the job description as vague as possible in order to entice curious onlookers to ask for more information. The claim appears to be that this somehow attracts employees who will thrive in a telecommuting environment, though it’s not expressed how vagueness of job posting aids in this.

Making a job posting at all vague is arrogant and disrespectful to candidates. You, as a company, are starting your relationship with your potential employees by playing games when instead you should be respecting them as professionals and providing them the data required to make an informed decision.

For those who wish to telecommute, expressing clearly and unambiguously that the position allows it is usually enough enticement for them to continue reading, if not also to apply. Not providing additional details, however, is going to lead to a large number of unqualified applicants and a commensurately large amount of staff time spent filtering out and declining these applicants.

Wasting the time of staff and candidates is unfortunate, but it’s not as problematic as the exclusionary nature of a vague job posting. Studies show that women only apply for jobs if they feel they meet 100% of the requirements.

If no requirements are listed at all? It’s unlikely that many women will apply for the Clevertech positions. Vague job postings aren’t only exclusionary to women, but also to people of any gender expression who do not think exactly like everyone else in Clevertech. This leads to a lack of diversity of ideas as well as of genders.

The article then continues by extolling the virtues of a “Log in with Google” call to action. The reasoning provided is that “If someone doesn’t have a Google account and isn’t willing or able to set one up, that person probably isn’t advanced or flexible enough to work remotely and positively impact our company.”

Again, the article does not explain why the willingness to have a Google account is in any way generally advantageous for remote workers. Without a valid explanation of that, this particular data point is invalid as to the topic at hand: advising how best to hire telecommuting employees.

This is another example of how the Clevertech hiring process is exclusionist. There are a great many reasons why a person may not be willing to have an account on a particular service. For instance, I know many privacy advocates who have either avoided signing up for a Google account or who have closed the one(s) they had open.

If Clevertech is using the “Log in with Google” as a way to filter out people who will not use Google on principle, that’s their choice to make. However, stating that the reason for the requirement is that it leads to candidates who are better qualified to telecommute is both disingenuous and unproven. There is no correlation–let alone causation–between the two.

But that’s OK, because the article continues, “If candidates are put off by our unorthodox approach, we know immediately that they are not a good fit for our firm.”

In tech we are more and more often supplied proof that the phrase “not a good culture fit” is code (subconsciously, perhaps) for “not exactly like us” and a sign that a company may not support a diversity of thought or of hiring.

If I may be allowed for a moment to judge purely by appearances, Clevertech does, indeed, appear to fit into that camp. 94% of its work force is technical in nature (IT or development). 4.8% of its workforce is female. 0% of their technical workforce is female. Zero percent.

There is not enough data from this one article to show that hiring processes of this sort lead to a lack of gender diversity at Clevertech or any other company which uses them, but there is certainly enough data to cast suspicion upon such practices and processes.

Another arrow in Clevertech’s remote hiring quiver is a “badge” system, wherein the employees get to bequeath each other with points every month for embodying the company’s core values. Again, it’s unclear how this helps when hiring remote employees. It’s even more unclear how this helps within the company itself.

Just a tip, Clevertech: If you have a numbers-based gamification in your company, the engineers WILL game that system. When your organisation is 94% percent technical staff, either the system is already being gamed or the engineers don’t care enough about the system to bother gaming it. If 94% of your staff do not care about a policy, drop it and take the time to find a substantial method for appreciating the contributions people make to the company, its culture, and its values.

Clevertech’s interview process relies upon the candidates being willing to video themselves answering supplied questions. The reasoning behind this is that it shows the interviewers how the candidate reacts under pressure. If you’ve ever been in a software development department when there’s a crisis situation, you know that how one is able to perform on camera is nowhere near the top of necessary criteria for resolving the issue at hand.

All interview processes for all positions, remote or otherwise, should relate 100% to the position for which the person has applied. For a newscaster, performing on camera is a vital part of the job and therefore asking them to create a video is a valid part of the interview process. For an engineer or IT professional, it is not. Asking engineers to make videos to supply answers to questions is quite silly and a waste of everyone’s time. It will not provide much information which is relevant to the position and the problems it will face. It will, however, turn off candidates who are not extroverted, who are not comfortable in front of a camera, who are afraid of being discriminated against because they are older or are fat or are female or wear religious artefacts or are disabled or are not precisely like the rest of the team they had applied to join. Requiring candidates to send videos is a gating question. It allows the company to filter out those who are not like them. Who are not “a good culture fit.”

The article states that the video questions asked of the candidates help to filter out those who are “…put off by the intensity of the questions…” as well as to attract “…applicants who respect the high level of our questions…”. Setting aside for the moment that neither of the example questions provided were either intense or high level, it’s worth considering that these particular questions and the method in which they are presented and evaluated are not, again, optimized for the hiring of remote workers. What they ARE, in fact, is optimized for filtering out those candidates who are not 100% in sync with the existing opinions and norms of the organization. Once again, these are questions which lead to groupthink and a dangerous lack of diversity both of people and opinions.

As you can see, there are no hiring or interview tips raised in the article which are in any way connected with whether a candidate will be a good telecommuting employee. Instead, almost every tip is one which can lead to a lack of diversity of genders, backgrounds, and opinions in a company. A truly innovative company values these differing views and strives both to maximize them in their workforce and to leverage them for the flashes of brilliance which they bring to otherwise mundane situations. Hiring practices such as those expressed in this article are a bad business practice and bad for the bottom line. Please do not use them.

For resources on how to hire and work with remote teams, check out this curated list of resources.

Badass: Making Teams Awesome

I read Kathy Sierra’s BADASS: Making Users Awesome back in February and haven’t been able to get it out of my mind since. The premise of the book rang true in a way I’ve not experienced from a book for a very long time. Reading it leads to the sort of, “well, DUH” moment which only follows when you come across an idea so brilliant and genius that it seems–in retrospect–so obvious.

Judging from the reviews on Amazon, O’Reilly, and elsewhere on the net, I’m in very good company with appreciating the book and the value it provides. Thank you, Kathy, for this great tool you’ve given us.

Whenever we read a book, we do it from our own unique point of view. I’m in tech management, so most things that I read are viewed through a managerial filter. This book is no different, which is why it has stuck with me so tenaciously over the past few months. Read with this perspective, BADASS is one of the most insightful management books I’ve had the pleasure to experience.

“But wait!” you protest, “This is a book about user experience! About product management! What do you mean it’s an amazing management book? You, my dear, need to smoke more mad crack.”

To that I reply, “You have an adorably limited definition of ‘user’ and ‘product’.”

Simply speaking, a product is anything which you produce. Unless you’re an assembly line (in which case: my condolences), you produce things through skill and craftsmanship. As management, it is my job to help produce effective teams. It is a job which I take very seriously. It is not easy and it requires a lot of knowledge, experience, and time to do it properly, as does any craft, but the end result is always worth the effort.

As for user, there’s an old chestnut which says that only drug dealers and software developers call their customers “users.” But, that aside, a user is anyone who avails themself of or benefits from your product. Very loosely speaking, from a management point of view a user is someone who benefits from the team you’ve built, including (and especially) the members of the team itself.

Within this context, then, many of the concepts from BADASS are highly applicable to building strong, effective, and cohesive teams.

For instance, on the topic of performance:

Technical definition of badass: Given a representative task in the domain, a badass performs in a superior way, more reliably.

If performance can’t be evaluated in some way, we can’t help someone build it.

On coaching:

The difference between extrinsically (external) vs. intrinsically motivated experiences is the difference between short term and sustained motivation.

They [the users] don’t want to be badass at our thing. They want to be badass at what they can do with it. They want badass results.

In the perfect scenario, we give our users as many options as they could want or need, but we also give them trusted defaults, presets, and recommendations. Especially in the beginning, we make decisions so our users don’t have to. Be the expert, the mentor, the guide.

On productivity:

Make sure your users spend their scarce, easily drained cognitive resources on the right things.

On success:

The key attributes of sustained success don’t live in the product. The key attributes live in the user.

When you’re more skilled at something, it’s as though a part of your world got an upgrade. It’s as though pre-badass-you had been experiencing the world in Standard and now a part of the world has become High Resolution.

And on YOU:

They don’t need you to be perfect. They need you to be honest.

These are only a few examples of unexpected nuggets of managerial wisdom in this book. In fact, most of the ideas espoused in the book are applicable to many different walks of life. It really is a remarkable piece of work and one I recommend to anyone who wants to help make life easier and better for those around them.

OSCON 2014

Another year, another OSCON. Now that I’m approaching caught up, here’s a quick recap of that busy week.

It was a busy OSCON for me this time around. I had two talks to give, only one of which I’d finished writing before I arrived. Oops. Ah, well. They both went well and were well-received and -reviewed, so I’m a happy camper. The slides and my webcam videos of both talks are available on Internet Archive:

Because my current job is so variable, my session attendance was equally variable. I didn’t really focus on any specific things, instead giving preference to talks by people I know and respect.

And, of course, there was the evening of Perl goodness: rjbs with a whole hurricane of lightning talks (in lieu of the State of the Onion, since Larry’s recovering from eye surgery), then a dozen or so individual lightning talks. As usual, rgeoffrey ran a tight ship and kept the talks moving smoothly.

Really, though, most of my time was spent sitting or standing around and talking to people. So many people. So, so many people. I’m not even going to attempt to list them all, but it was all time well-spent. I’m grateful for the opportunity to meet and befriend so many amazing and inspiring people.

One thing that did not happen that week was productivity. Beyond talking (both on stage and off), I accomplished little of substance. Not only does that make this subsequent week more difficult, it’s also an opportunity missed. I could have done some excellent collaboration that week. So when I read rjbs’s OSCON trip report I was intrigued by his idea to set up shop at a table & just get shit done next year. I’d back that play. I have plenty of projects which need love and attention, so having a personal OSCON Hackathon wouldn’t go amiss. Thanks for the idea, Rik!

Overall it was a great trip but an exhausting. I’m honored that I was once again invited to speak and overjoyed to have spent so much time with so many great friends, both old & new. You’ve filled my head with knowledge and ideas and wowed me with your accomplishments. Now I just need to figure out how best to apply all my newfound inspiration.

Dear Mister Independent Recruiter,

Hello.

I saw your resume on the web and am writing to see if you or anyone that you know who may be interested in the following position in $city. It is with a top $industry startup, located in a gorgeous location of $region, pays top dollar, great benefits, options and bonuses.

You will be working on top tier financial technology with a great team! If there is any interest, please email resume to $email_addr.

Best Regards,

$name
Independent Recruiter

Oh. How…common. My response:

Dear Mister Independent Recruiter,

I manage software engineering departments. I also do technical management consulting. I also do independent recruiting. What I do NOT do is DBA. Which you’d have known if you’d even glanced at the resume you claim that you saw.

You are not an independent recruiter. You are little better than a spammer. Your email is the sort of ignorant and blind outreach which gives legitimate recruiters a bad name.

Please stop harvesting resumes and then sending emails based on little more than the simplest of keyword searches. Take just a moment to look over a resume before mailing someone. Qualify your damn candidates. Stop spamming tech professionals. Start recruiting them.

Five Tips for Better Cover Letters

A question from a friend for whom I consult on occasional career coaching matters:

What’s your take on cover letters: make ’em short ‘n sweet, or go to town and try to sell yourself there rather than in the resume?

To answer my friend’s question: You should always be trying to sell yourself, both in your resume and in your cover letter. I’ve already had a brief discussion on how to improve your resume. Now here’s the companion piece: some tips to improve your cover letter.

Cover letters are a surprisingly polarizing topic among those who do hiring in technology. Some people find them to be a waste of time and will never read them, instead relying purely on a candidate’s resume. Some companies don’t even make provision for submitting a cover letter in their online application processes.

Naturally, your resume is an important document in the job hunt process. It tells your prospective employer what you’ve done and what you know. Similarly, your portfolio (Github, etc.) shows the hiring manager the how of your career: how do you implement the code or the design or the document?

As for myself, I require cover letters from all applicants and here’s why: I hire people; I don’t hire shopping lists of tech skills. While, yes, your skill set is important to me and I will be scouring your resume for every possible nugget of gold, I’m far more interested in who you are, what you can do for me, and how you interact with others. I can teach anyone how to use our technology. I can’t teach someone how not to be an asshole. Your cover letter is going to tell me who you are and, importantly, why I should care. What problems are you going to help me solve? Without that cover letter I have no insight behind the resume or code sample and little motivation to learn more. You’re just another faceless resume in the stack.

Now for those tips I promised…

Customize!

If your cover letter arrives on my desk and is obviously a cut and pasted template, I’m less likely to follow up on your application. To me, it doesn’t feel like you want this job; you’re just looking for any job.

Which isn’t to say you should necessarily rewrite a cover letter from scratch for every job to which you apply. It’s OK to have some sort of scaffold as a foundation around which you build individual letters.

Each of those letters must be customized for the position to which you’re applying. Do your research about the company and position and incorporate that into the letter. Some examples of what you could include:

  • What problem are they trying to solve? They wouldn’t be hiring if they didn’t have problems to solve, so how can you help them?
  • Who is the hiring manager? Address them directly in the salutation of the letter. Decades of direct marketing research show that personalized messages are more likely to be received favorably. Plus, going this extra mile to address your potential manager reflects well on you.
  • What are the company’s values and mission? If you agree with these things, incorporate them into your letter. Naturally, if you don’t agree with the values and mission you should not apply for the position.

It’s not about you; it’s about me

I, as the hiring manager, have needs. I have deadlines to meet and bugs to fix and code to refactor and rearchitect and people to hire and mentor and meetings upon meetings to attend. How are you, $applicant, going to make my life easier?

What many applicants forget is that as a manager I really want to hire you. I need to get the right person in the door and productive so my team can keep moving forward and hitting deadlines. If your cover letter tells me how you will help us do that? I’m already predisposed to like you.

But, really, it’s about you

Your cover letter is your opportunity to show the hiring manager that you’re going to be an asset to the team. You’re skilled, sure, but you also work well with others. You’re well-spoken. You’re witty. You support the mission of the company. You’re going to join the team and make things better for me and here’s how. Tell me who you are and why I should care.

Predict and elucidate

Sometimes when writing your cover letter you must channel your inner Carnac, answering questions before they’ve even been asked. After reviewing your cover letter and resume, the hiring committee may be left scratching their heads over some subjects. This head scratching implies effort on their part to discover the answers. These people are quite busy. If there are other candidates who initially appear as qualified as you but whose applications do not leave so many question marks hanging in the air, your resume will not be put in the short pile. However, if you predict the most pressing questions of the hiring committee and provide the answers up front in your cover letter, it can make all the difference. Some examples of questions which your new team might have when reviewing your application:

  • You haven’t been working for a while. What have you been doing in the meantime?
  • This job is based in Austin, TX but you’re in Portland, ME. Are you looking to relocate or work remotely?
  • You’ve spent the last ten years as a software engineer. Why are you applying for a position as a tech writer?

Form follows function

Coco Chanel once said, “In order to be irreplaceable one must always be different.” Don’t pay attention to those job hunt books you get from the library. They’re wrong: there is no rulebook for the format for your letter.

Your cover letter should reflect your personal style as well as the style and culture of the organization to which you’re applying. Most often, that will be a basic letter in which the content speaks for itself. However sometimes it may make more sense to stand out more. Perhaps a “letter” written in the form of a stack of calls to the company’s public API. Maybe a link to a website you designed solely for this purpose. Animated cat GIF? Um…OK, but only if that’s what makes sense.

Always remember: Don’t be clever purely for the sake of cleverness. The goal of your cover letter is to show the hiring manager who you are, what you can do for them, and turn heads in the most appropriate way. No one likes a cocky show-off.

The Rising Costs of Aging Perlers: Part 2, The Business

At this point you’re entirely justified in asking, “So what?”

The fact of the matter is, the lack of junior programmers is a very big deal from a business point of view, both to companies which already use Perl and those who might otherwise consider it. This directly and strongly impacts the bottom line of any Perl-using development shop.

According to Payscale.com, in San Francisco the median pay for a junior software developer is $66,000. For a senior software developer it’s $111,000. To be honest, we’re in a boom here right now. It’s my experience as a software development manager that each of these numbers is at least $20-$30K too low, but let’s run with the Payscale numbers. It’s obvious that a senior software developer is going to cost a shop a minimum of nearly $50,000 more than a junior developer.

Now consider the structure and needs of your typical software development department. There are a number of tasks which absolutely require the skills and expertise only a senior developer can bring to bear, but the majority of the work most likely can be performed by more junior developers with appropriate supervision. You do not need every member of your team to be senior and, at an extra $50K a head, you can’t afford to do it anyway. That sort of staff expenditure is an irresponsible business practice. However, as unreasonable as it is to expect a company to pay so much more for experience they don’t need, it’s equally unreasonable to expect a senior developer to accept less pay than (s)he has earned through years of training and experience.

Companies in this position, in order to continue using Perl, will have few options available to them. One of those options is to start training all incoming developers to use the language. While this is possible (undoubtedly some companies already do this), it is itself a very expensive proposition, often costing tens of thousands of dollars in training costs, time and productivity. A number of companies may run the numbers on the investment they’d be required to make in training and decide that it provides a much lower return than undertaking the arduous task of rearchitecting the software to use a language where they are able to hire staff (and at a more reasonable rate of pay).

Alternatively, companies which do not yet use Perl may be turned away from the language for similar reasons. The harsh financial realities of running a business—rather than technological merit—will end up dictating which programming language a company will use for their product. Selecting a language for which you can only hire senior developers is a very bad business practice, which leaves Perl in a poor position from a business point of view.

From where I’m standing, it does not appear as though the Perl community is doing much to correct this issue. As I detailed in my earlier post, in many cases Perl’s new programmer outreach appears fairly crummy if not virtually non-existent. This needs to change before Perl starts to face a cultural extinction. Perl needs to start creating fledgling Perlers to help sustain and grow the language through it’s next twenty-five years. As well, this will add new blood to the community and help diversify the gene pool. The more diverse a community, the better it’s able to adapt to the changing conditions which might otherwise overwhelm it.

A diverse or deep gene pool gives a population a higher chance of surviving an adverse change in conditions. Effects that cause or reward a loss in genetic diversity can increase the chances of extinction of a species. Population bottlenecks can dramatically reduce genetic diversity by severely limiting the number of reproducing individuals and make inbreeding more frequent. Wikipedia page on Extinction

In the final post of this series, I’ll detail some suggestions for avoiding this cultural extinction. Read Part 3.

Putting Away My Pitchfork: The Yahoo Remote Worker Announcement

On February 22nd, 2013, Yahoo! CEO Marissa Mayer announced that all remote employees will be required to work from their local Yahoo! office by June.

The internet grabbed its pitchforks and lit its torches then exploded with anger and derision.

Does this announcement place a hardship on remote Yahoo! employees? Probably.

Is this a draconian move by Mayer? It seems that way.

Would I have done the same in her place? I don’t know. And neither do you.

The fact of the matter is that none of us are in her place. As a company, Yahoo! has been foundering for years and Mayer is now at the wheel trying to right the ship. I’m not their CEO. Neither are you (unless you actually are Marissa, in which case, “Hi!”).

To be entirely clear and open: My initial reaction to the announcement was horror and anger. I am a supporter of remote working arrangements, and not only because I have one myself. I realize that there are good people everywhere and setting up an infrastructure to support remote workers allows companies to find the best people for the job, no matter where they’re located. However I also realize that without the appropriate infrastructure a remote working arrangement can be disastrous to a product and a company. It’s not for everyone. It’s not for every company.

Mayer is many things, but one thing she is not is a fool. Before this decision was announced she knew it wouldn’t play in Peoria. She knew there would be PR fallout. She knew the internet would cast her in the role of the wicked witch. She also knew a hell of a lot of other details to which none of us are privy.

This could not have been a swift decision, made in a moment of passion. Undoubtedly it was researched, calculated and discussed ad nauseam. Without access to that research and the discussions around it, none of us can know whether this is a good decision for Yahoo!.

I feel for the Yahooligans who now must uproot their working lives, I truly do. But I’m going to resist my impulse to pillory Marissa Mayer for her decision until I know more about what led to it.

Is it OK to apply at a company which doesn’t excite you?

A question which just arrived at my desk:

There’s a company that has some openings for what I do. I’ve met with a couple of employees from there and wasn’t wowed by what the place is doing. Is it OK for me to apply or would that be unethical?

To answer the question: Yes, it’s OK for him to apply and No it’s not unethical. There are two reasons for this.

First of all, this is only an application and—as we all know—submitting an application is no guarantee of getting an interview. Even with the contacts he’s already made at the company, it’s possible that his skill set won’t be what the hiring manager needs or that someone else better fits the bill. There is no risk to him in applying for the position.

Secondly, speaking with a couple of current employees of the company may not have given him the information he needs to judge whether he would enjoy working there. I applaud that he’s taken the time to sit down and chat with these people. Ideally this is a step everyone would be able to take in their job hunting process. It is, however, only half of a picture. The other half comes with the interview, when he’s able to speak with a broader range of people within the company, including managers who may be able to give him the lowdown on the exciting things planned for the team. It may be that once he’s spoken with more people he’ll decide that it’s a company and a project he really believes in, but he’s not going to know for sure until after that interview.

Applying for the position allows the company to decide whether he might be right for them. Interviewing allows both parties to decide whether they are right for each other. Both steps are purely fact-finding in nature. There’s no risk. There’s no commitment.

The question of ethics comes in when and/or if a job offer is made. If, after all of the steps in the interview process, this man is still not particularly interested in the company then it’s best for all involved that he not accept the offer. To commit to a job and a company which you don’t really want leads you to have a life of drudgery, which is bad enough, but it’s also disingenuous to your new coworkers. They assume you’re there because you want to be there and that you care as much as they do about the mission of the team. Accepting a job just so you can phone it in and collect a paycheck is a dishonorable way to make a living.

Of course there are always going to be exceptions to this rule. For instance, if you’ve been out of work for a long while and need any job to keep the children fed and the mortgage paid then, by all means, accept the job you are offered rather than await the one of your dreams. There will be time enough to trade up once you’ve provided some security for your family. Exceptions aside, it’s generally a bad idea to accept a job about which you feel, at best, ambivalent.

Many thanks go to this anonymous gentleman who sent this question my way. As a tech hiring manager it’s a relief to see people who really think and care about their careers.

On a related note: if any readers are looking for a skilled technical project manager who is as friendly as he is knowledgable, I may know someone in the market. Drop me a line and we’ll talk.