Category Archives: Software Jobs

Communicating Salary in Job Postings

This is part of my continuing series on applying Jobs-To-Be-Done product design theory to the problem of recruiting. In my first installment, I explained the concept and gave some idea of applying JTBD to recruiting would mean:

In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.

Next, I wrote about the problem of hiring passively looking developers, where the key question I addressed was: “What would you do to your recruiting efforts if you wanted to hire people that aren’t looking for a job?”

Following along that vein, and again, using JTBD techniques, let’s talk about “progress making”. Essentially, people switch (products, jobs, houses, etc) because they are trying to make progress in their lives. In order to design products that make people switch to them, we need to know what kind of progress our users are trying to make.

In this case, it’s pretty uncontroversial to say that our potential applicants are looking to make progress in their compensation, or, if they are willing to trade that against other things, they have a lower limit.

Salary, for a potential job switcher, hits all of the forces of progress making.

  • They are pushed toward switching by the feeling that their current job doesn’t value them enough;
  • they are pulled toward switching by a job that pays more;
  • they are pulled back from switching by familiarity with their current pay structure and raise schedule;
  • they are pushed away from switching by anxiety that other jobs won’t pay as well (or have less potential for future salary growth).

Dissatisfaction, aspiration, allegiance, and anxiety: to get someone to switch we need to address all of these, and increase the first two while lowering the other two. (learn more about the forces from JTBD Radio).

Our potential applicants have total knowledge of their current salary, so to help people realize they will make progress, they need to know what we are offering. For the passive looker, who is not willing to invest much in each opportunity, the risk of early filtering is high. The unknown feeds the anxiety component and does nothing to drive aspiration (the two forces our offer directly controls), so they won’t associate “progress making” with your job description.

[ASIDE: I know why we don’t list salary in job postings, but I would say that whatever those reasons are need to be balanced against wanting to make our job attractive to top developers, which we believe are not actively looking for a job. So, if we accomplish “having a good starting point for negotiation”, but not “attract top developers to applying for our job”, we failed.]

To alleviate anxiety about your offer, I would try social proof, a lossy communication channel, or possibly a transparent salary ladder.

For social proof, get candidates via referrals from your employees. People will make a judgement about your salary scale based on what they know about their contact.

By lossy communication channel, I mean a way to communicate salary possibilities such that the candidate gets an idea, but knows that it might be wrong and doesn’t interpret it as an offer. One way to do this is with a 3rd party recruiter — you give them a range, and they will leak it to the applicant, who will have skepticism for anything a recruiter tells them. You could try 3rd party ads that “estimate” a salary or write up truthful descriptions in something like GlassDoor or other salary reporting places.  No one thinks those are definite, but at this point, they just need some idea.

A third option is to have total transparency and a completely non-negotiable salary ladder. This is what union and government jobs do (so it has a bad rap), but I’ve seen tech companies try it — here’s a really old post from Joel Spolsky about Fog Creek’s compensation and here’s a very recent article about Buffer’s compensation policy. Both use a formula based on mostly objective criteria.

Your goal is to throw something out there to alleviate anxiety enough to get them to contact you.

Recruiting Passively Looking Developers

This is the second in my series at applying Jobs-to-be-done (JTBD) techniques to Recruiting. To recap, our open job position is hired by applicants (gets a job done in their lives) and has hiring criteria that the applicant applies when making decisions about it.

In their JTBD training, Bob Moesta and Chris Spiek teach how to interview to understand the JTBD Timeline (here’s a great description of the JTBD Timeline from Ross Belmont and here’s Bob and Chris’s JTBD Timeline Diagram). In this post I want to concentrate on the beginning of the timeline — the part where someone has the first thought that they might switch and up until active looking.

I believe that that the vast majority of excellent software developers are not actively looking for a job. Back in 2007, Joel Spolsky put it this way:

From a recruiting perspective, the problem is that the people I consider to be in the top 1 percent in my field barely ever apply for jobs at all. That’s because they already have jobs. Stimulating jobs. Jobs where their employers pay them lots of money and do whatever it takes to keep them happy. If these pros switch jobs, chances are the offer came through networking, not because they submitted a resumé somewhere or trolled a job site like Monster. Many of the best developers I know took a summer internship on a whim and then stayed on. They have applied for only one or two jobs in their lives.

If you want to run a world class development team you need to internalize this. What would you do to your recruiting efforts if you wanted to hire people that aren’t looking for a job?

Here are a bunch of things that won’t work at all

  1. Advertising on job sites
  2. Tweaking your “Company > Careers” page
  3. Hiring headhunters (despite the hunter name, they are usually gatherers)
  4. Tweeting, Updating Linked-in statuses, etc.

It’s fine to do these things — there are actually active job-seekers. But, if you look at typical recruiting, this pretty much sums up the entire effort.

Also, targeting the passive lookers is a long-game. If you need someone right now, then traditional recruiting is your best bet. But, in the long run, if you know you need a steady stream of applicants to succeed, you have to have a plan to target passive lookers.

Here are some examples of what others do;

  1. In the link above, Joel’s solution is an internship program. Not just any one — he treats it like the critically important company building tool it is:

    I send a personalized letter to every promising computer science major that I can find. Last year I sent 300 letters to fill six intern positions. Not e-mail. My letters are printed on a real piece of Fog Creek letterhead, which I sign myself in actual ink. Apparently this is rare enough that it gets kids’ attention.

  2. Matasano Security is “always hiring security consultants. Really.” In order to help build a pipeline of passive developers who know they exist and what they do (and that they are hiring), they have a “Crypto Challenge” email campaign. When you sign up, they email you list of crypto coding puzzles. They don’t recruit through this e-mail, but if know Matasano at all, you know that they are always hiring.
  3. I work in developer tools, so I know that our marketing department is always talking to developers (hey, we’re hiring a Developer Evangelist to help us do that even better). If you market to developers, you should have a plan for making sure they know how great it would be to work for you. If you don’t, but you need to hire a lot of developers, adding an SDK product to your line-up is not a bad idea (it’s probably a good idea anyway — the software business is all about platform proliferation).
  4. You absolutely need to have a functioning referral program — almost everybody has something, but if you aren’t getting a significant number of leads this way, you need to be having a tough conversation with your developers about why they wouldn’t recommend that others work with them. The answer is NOT that the referral program doesn’t pay enough, but you could probably make it work if you overpay.

I believe that #4 is your indicator that you have solved the JTBD for recruiting (which is that the product is right — your developers love their job and would recommend that others with them). Look at the end of the timeline I linked at the beginning of this post — it ends with satisfaction (or not), and the point of that is repeat business and word-of-mouth.

Four interesting tech jobs in the Pioneer Valley

I’ve been doing some research on how people advertise tech jobs, and I found a few interesting jobs in the Pioneer Valley that I want to share

  1. Fiksu: This company has offices in Boston and Northampton (right in downtown), and has an opening for a Software Developer in the Northampton Office.

    Fiksu, Inc. is a progressive, creative, fast growing, cutting edge
    advertising technology company for mobile applications.  We build the
    leading user acquisition platform to help brands achieve their
    business goals faster and more efficiently than ever before.

    Fiksu is looking for talented developers with a deep interest in big data, distributed systems, high scalability, open source technologies, and cloud computing.  You might not have much experience, but you’re a disciplined software engineer who is excited to learn and use new technologies and methods.

  2. Communicate Health: This company is right down the block from my house — I pass it every day. I met their Senior Designer, Molly McLeod, at the Western MA Hackathon, and she posted this job recently:

    Senior Web Developer
    CommunicateHealth, Inc. is a health education and communication firm specializing in improving health literacy through user-centered design, policy, research, and content development. At CommunicateHealth, we believe people deserve clear information about their health. This doesn’t mean using short words and lots of pictures — it means making sure the information and services our clients provide can be accessed, understood, and used by the people who need them most.

    The senior web developer will take the lead on many projects as our primary technical staff member.

  3. HitPoint Studios: The CEO, Aaron St. John, wrote to tell me about this position in their Amherst office.

    Windows 8 XAML/C# Engineer
    HitPoint Studios is looking for an experienced engineer to work on the development of engaging front-end user interfaces for Windows Store and Windows 7 games. We are seeking someone with one or more years of experience with WPF/XAML, familiarity with Windows 8 development (Windows Store apps for Windows 8 and Windows Phone 8), a strong background in MVVM design patterns, and a good eye for UI and UX design. The position involves maintaining and improving an existing reusable code base for multiple Windows Store and Windows 7 titles with similar front end functionality but varying UI views and feature sets.

  4. Atalasoft: Atalasoft publishes developer tools for imaging and capture applications. We have a great job for a web developer that wants to spend time helping software developers get to know our company and products better. It’s in the marketing department, and you’ll be creating technical content (demos, sample code, blogs, tutorials, copy for brochures, newletters, e-learning, etc) that we can use to reach developers and get them interested in our company’s products.

Apply Jobs-to-be-Done (JTBD) to Recruiting

Jobs-to-be-done (JTBD) is a theory for what causes us to buy things. The quick description is: jobs arise in our lives and then we hire products or services to do them. The key insight is that the job attributes should be used to guide product development, not the customer attributes. Here is Clay Christensen describing the concept if you haven’t heard it before.

This theory was publicly introduced in his book, The Innovator’s Solution, but is being popularized by Bob Moesta and Chris Spiek in Switch Workshops and soon at the Business of Software conference.

I was lucky enough to participate in some training with Bob and Chris, and so I often think of Jobs theory whenever I wonder why people do anything, and recently I’ve been thinking about recruiting (yes, Atalasoft has a job opening for a software developer in our marketing department to help evangelize our products).

Now, when hiring we naturally think of the job we need done, and of course, we are explicit about that when writing the ad, evaluating resumes, interviewing, ultimately hiring someone. The job has hiring criteria and we use it.

But, at the same time, potential applicants also have a job-to-be-done in their lives, and they are judging us with hiring criteria. In this case, we usually fall all apart. We try to write job descriptions that sell ourselves too, but, frankly, I’m not sure they actually address the applicant’s criteria.

In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.

I’m sorry to say that I haven’t done this, so I don’t really know what needs to change.

In any case, I’m going to be thinking and posting more about this — hopefully trying it in practice. In the meantime, if you are a web programmer (preferably in .NET or Java), have at least 5 years of experience, and you want to work in a developer tools company’s marketing department, creating technical content (demos, blogs, articles, sample code, tutorials, brochures, etc) to help developers learn more about our products, get in touch with me. At Atalasoft, you’ll work with smart and hard-working colleagues, where we have an enormous amount of respect and trust in each other. Some of the best programmers in Western MA have chosen to work here, and we can’t wait to meet you.

 

Interview question advice: What’s the difference between an interface and an abstract class

I met a recent CS graduate last week who was wondering the right way to answer “What’s the difference between an abstract class and an interface”. In his case, the question was in a Java context, but this applies to C# (and other .NET languages).

Here are the keys to answering a question like this:

1. You need to actually know the correct and complete technical answer

I’m not going to get into a detailed analysis of the difference. There are a few StackOverflow answers that are worth reading if you don’t understand. I will say that this question is fairly basic, and if you don’t have a firm grasp of the answer, you should do more than just read some websites — write code that uses interfaces and abstract classes and really try to internalize the difference. Look at examples of both in the standard library and think about the difference it would make if an interface was changed to an abstract class or vice versa.

2. Understand why the interviewer is asking the question

If I ask this question, it’s usually during a pre-screen. Since I believe the question is basic, I just want to make sure that the candidate meets a minimum qualification to be asked hard questions. Given that, I expect a fairly quick and smooth delivery of the answer. I never need perfection, but I don’t expect much struggling with this concept.

But, the real reason I ask questions like this is to see how the candidate explains technical concepts. I want to see that they know how to organize their thoughts and express themselves clearly. Nearly every programming job ad says something about spoken and written communication being important; it’s on the interview that you show that you have this skill.

3. Be able answer beyond the basics

You should know the mechanical differences like syntax and limitations of each, but if you stop there, you have only given a minimally correct answer.

A better answer follows this basic recipe

  1. Explain how they are the same (differences are only interesting if there are similarities)
  2. Explain the mechanical differences
  3. Explain when one is better than the other — then explain when the other is better
  4. Give concrete examples from your work or the standard library. Pick an example where the choice isn’t obvious, and work in your best project.

By the way, this works for any “What’s the difference …?” question.

What I look for when I hire

I recently wrote this in an e-mail to an ex-colleague who was looking for advice on hiring:

Here’s what I look for when I hire:

#1: I worked with them before and I know them to be great
#2: Someone I trust (who is a #1 for me) says they are a #1 for them (worked with them and says they are great).

After that, it’s been luck — I’ve actually been thinking about this a lot lately — getting a little better

Here’s what I look for:

  1. They must program on the interview — I don’t care which language, but I want to see something.
  2. I want to see evidence that they have set and met long-term goals — ones that take perseverance — not just ones that are what they are paid to do for work, but something that augments that (or even something unrelated). So, leading and completing a big work project is not what I am looking for, exactly, because you don’t have a choice to do or finish them, and there are rewards all along the way (your paycheck)
  3. Along those lines — self-improvement — learns about new tech, languages, etc. Tries to build things on their own.
  4. Community involvement — could be twitter, a blog, going to dev groups or even stuff totally unrelated to tech (volunteering, etc) — if not, it’s nice if they have broader interests (music, art, etc). There are a lot of user-generated content outlets out there (StackOverflow, CodeProject, GitHub, FooCamps etc. — do they contribute to any of them)
  5. Some evidence that they read our company’s website, the blogs of our employees, twitter feeds, etc. I can’t understand why people don’t prepare for interviews — but I take it to mean that they don’t prepare for anything.
  6. Must be able to write — I want a nice cover letter that is a convincing argument for why I should hire them.
  7. Some evidence that they care about their work and are self-critical
  8. They must be experts in something — I don’t care what it is, but whatever it is that they are doing, they must know it deeply. If they have been web-programmers for 5 years, I should be able to ask any question I want to about HTTP life-cycle, JavaScript debugging, etc. They can’t have total blanks on the core stuff they are supposed to know.
  9. For very entry-level, I teach them something simple in one context, and then later ask questions where they need to apply that knowledge.
  10. They must explain things to me that I don’t know, and I have to be able to understand it.
  11. I’m looking for go-getters — so, I like people that reach out to me (I am easy to find) — that follow up after interviews — do more than what is expected in the interview process.

Job seeking advice from a 16 year old

A couple of weeks ago I called my “little brother” Josh for his birthday (we’re in BB/BS). “Guess what I got,” he said, “a job at Big-Y”

His sixteenth birthday was the first day that he was eligible to work, so it’s pretty amazing that he (1) got his working papers already and then (2) actually got a job. It’s tough out there for young job seekers (not to mention everyone else), so Josh must have been lucky or connected.

Not exactly.

Josh has been really determined to get a job. So much so, that he went to Big-Y a few months ago and filled out an application even though he wasn’t qualified yet. He has an awesome resume, so the manager told him to come back when he turned sixteen.

“What?” you must be thinking, “How does he have an awesome resume? I thought you said that he couldn’t work”

Sure, he couldn’t work, but he could volunteer. Josh has been volunteering hundreds of hours a year since he was 11. He has served food at the community center, worked parades as a junior Lion cub, helped out at the local Food Pantry, was a member of his high school’s Key Club, and we have done a few BB/BS volunteer activities together — last month we helped artisans move in their wares for the BB/BS Annual Winter Craft Fair.

I asked him why he volunteers so much, and he said that he had a blast, met great people, and wanted to get used to working several hours a week for when he was able to get a job.

If you know any teenagers who aren’t old enough to work, but will want to when they can, you might want to share Josh’s advice. I told him he should teach a class.

You Need More than a Resume

Job seekers need strategies for standing out and need to start thinking about this well before they need a job—maybe be thinking about it all of the time.

My advice is the same as it has been in the past:

  1. Hone your craft. Be the most qualified person for the job you want.
  2. Research the company you plan to apply for, and tailor your application.
  3. Put together a portfolio. This will become the norm—right now, it’s a way to stand out.
  4. Build up your professional network. You’re more likely to get a job through an introduction rather than adding your resumé to their pile.

Start now. Doing these things while you are looking for a job is too late.

Towards a Portfolio Based Interview Process for Programmers

I don’t usually ask for a code sample, but I do accept them if they are offered. I don’t ask for them because the code samples I have received have been disappointing and perhaps do not represent the potential of the person giving them to me. The biggest problem is that they weren’t written to be shown and are usually just plucked from some project as part of the job application.

It’s extremely hard to take a piece of a large project out of context and make sure that it’s self-contained and interesting. More experienced developers have the added problem that a lot of the code they have written is proprietary, and they cannot share any of it. Generally, side-projects and school projects just aren’t written with showing it at an interview in mind, and I don’t think it’s fair to put the interviewee on the spot by asking for it.

When I get them, my best use of code samples has been to use them as a jumping off point for an initial line of questioning. I try to identify a small chunk, like one function, that I think can be improved. I tell the interviewee my problems with it (like a code review) and ask them to be prepared to improve it when we meet.

But, I’d like to do a lot more, and to make it more likely that I’ll get good samples, I’m going to document what I’m looking for and hope to hear some feedback about it.

  1. Let’s stop calling them code samples. They should be prepared portfolio pieces. That means working code that I can run, and access to all of it. Probably the best thing is a running website and a github repository. If the software is hard to run, then a video walkthrough or screenshots are acceptable substitutes.  
  2. I only want to see code that you intended to be read. I understand that you might have taken short-cuts on your side-project to get it done, and that your Junior year sudoko solver is a hacky mess. Don’t show me those – either fix them for review or write something small that you want to be read as an example of the work you will do if hired.  
  3. I could use an orientation. I need a starting place. The bigger the project, the harder it will be to jump in and take a look around. Give me what you’d give a new contributor.  
  4. You can’t have a total blank on design. I am not looking for designers, and so I am prepared to give you a pass on this, but it can’t be horrible. Just get a free template or use ultra-standard GUI guidelines. Make it easier on yourself by keeping the project small.  
  5. The repository is part of the review. I am probably going to look at commit comments and the progression of the project.  
  6. I need to know what part you did. It’s probably better to send solo projects, but if your best piece is a collaboration, then I need to know what part you did.  
  7. I’d like a writing sample as well. This could be the walkthrough, the project description, or your blog. This is an important part of your portfolio, and just as important as your code.  
  8. The right size is probably about two week’s worth of work. If you don’t have a public project, and are thinking of preparing a portfolio piece, it doesn’t have to be a giant project.  I think something with a dozen or so code files is about the right size to review. If you are showing me something much larger, then point out a part that I should focus on. 

I think my process will be the same to start. I will look for a part to code-review and give it to you beforehand. 

What I’m hoping for is that these prepared pieces will offer much more insight into the person I’m interviewing and allow for a much deeper line of questioning.

I’d love to hear any any experiences on both sides of a code portfolio review. What worked, what didn’t. If you have something like a code portfolio prepared, I’d love to see a link.