Category Archives: Software Jobs

How to Use Rejection

One of the more exciting things in life is to be accepted to do something that was competitive, and where you stood a good chance of rejection. That could be our stretch choice college that seemed out of our reach. Or that new job or promotion that we technically don’t qualify for. Or as simple as getting a date with someone out of our league.

It’s exciting to punch above your weight.

But, the chance of rejection can sometimes make us not try. We say that we’re not ready. That is probably true. In fact, the more chances you take, the more likely it is to be true.

But, rejection is a great way to find out how to get ready. It’s not something to be avoided. It’s a tool we can learn to use.

Here are ways we can use the possibility of rejection

  1. To motivate us to practice and prepare
  2. To focus our requests for help

Here are ways we can use actual rejection

  1. To ask for specific feedback
  2. To drive a post-mortem
  3. To improve our approach for next time
  4. To help others in our position

Use GitHub Profile Pages to Mirror Your Personal Site

In 2014, I wrote that a direct GitHub link to your profile was not good enough for a resume. At that time, the profile page was not customizable enough and was confusing for a recruiter or hiring manager to use to understand your portfolio.

My suggestion was to link to your-site.com/github instead (for example: loufranco.com/github). I recommended that you organize your open-source work more like a portfolio and highlight the most important work.

But, since 2014, GitHub has made updates to profile pages. Right now, I would say that they are finally good enough to use directly if you want. It’s just a README and you have total control of the text.

But, I decided to just mirror my personal page on it. The one big advantage of my personal page is that I have access to the analytics for it. I am not in the job market, but if I were, I could also put a contact form on it. My own page is also more customizable than a README.

GitHub profile pages will probably rank higher in search and are linked up directly in GitHub. So having something there is also important, which is why I mirrored my personal page.

My 2014 article had some advice on what should be on your profile page. I’ll be revisiting that soon.

Vague Tutorials Would Help with Coding Interviews

I think tutorials should be vaguer because “A [vague tutorial] would get the reader playing instead of reading and help them practice composing code instead of copying it.”

In a typical tutorial, all of the code is inline with the text, which tries to explain it line-by-line. In a vague tutorial, you’d get just enough information to write the code yourself. Some code would be given as a scaffold with blanks you fill in.

This is very much like how coding interviews work, so doing a series of vague tutorials would be good training for them.

This means that the sites that are doing training for coding interview (e.g. TopCoder and HackerRank) are to some extent vague tutorial writers. It’s interesting that they also gamify their sites (mostly via ranking), which gets at the theme of many of my posts, although I think gamification is not as good as playability.

In my last job hunt, I knew my target employers gave very hard data-structure/algorithmic style coding interviews, so I spent weeks on TopCoder (most failing) before I applied. The main things I got out of it was deciphering specifications under time pressure and iterative development. Both of these skills are invaluable when doing a coding interview, because unfortunately, tech job interviews are mostly auditions.

Tech Jobs Are Not Performances, So Why Do We Audition?

I went to see an orchestra perform Beethoven’s Fifth last night, and it reminded me about what bothers me about typical tech interviews. If you want to be in an orchestra, you need to audition. That makes sense because an audition is close to what the job actually is—a performance. This also makes sense for actors, comedians, dancers, etc.

Programming is not a performance

A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it’d be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

I’ve known this for a while. In fact, when I get asked for interview advice, I usually say this directly: “Treat it like you are a violinist trying out for the orchestra. Practice, practice, practice. Ask your recruiter what kind of code you’d typically have to write during the interview (algorithmic, UI, a full-stack app), and practice that. Practice the tools/IDE, frameworks, language, etc. Think of it more like performing a piece.”

Now, to be clear, I’m not a big fan of this kind of interview. But, often as job-seekers, we don’t have the ability to change this—especially if there’s a specific job we want. I had a 22+ year career, wrote a book about iOS development, and had many public artifacts of my work, but I got my last job by passing several “auditions” that I practiced for. I personally don’t intend to ever do that again, but I wanted this specific job, and this was the only way to get it.

Instead, let’s try portfolio review

What I think would be better is a portfolio review. This is what you’d do if you hired an artist, craftsperson, or other professional where the job is to produce works. Portfolios give us insight into what the person could make given typical conditions and not under time constraints with every mistyped keystroke interpreted as a short-coming.

We already know this. When hiring consultants to do tech work, it’s the norm to look at portfolios, and not to do a tech screen. When I was consulting, I prepared a website with a description of my credentials and links to my work. I was never asked to live-code to get a consulting gig.

The problem is that not everyone has a job that produces public works. Even if the product is public, we need to see the code, since that’s the part a programmer makes. There is some privilege in being able to have time to create these works.

But, I don’t think it needs to be a huge piece—it’s likely that an interviewer could only spend 20-30 minutes looking at it. The important thing is that the work conveys a positive answer to the question: “can this person do the job?”.

I wrote about portfolio-based interviews back in 2011.

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’m kind of surprised that this hasn’t become more common by now, as it did seem like it was happening organically. GitHub links have been common for a while. StackOverflow introduced Developer Stories in 2016, which are focussed on showcasing your work. I have never seen one as part of an application.

Bonus: They could be blind

When orchestras started using blind auditions, gender balance improved:

Using a screen to conceal candidates from the jury during preliminary auditions increased the likelihood that a female musician would advance to the next round by 11 percentage points. During the final round, “blind” auditions increased the likelihood of female musicians being selected by 30%.

We could probably do our current tech interviews blind using a voice changer over a screen sharing service, but it would be awkward. A portfolio review is easy to do blind.

In fact, tech conferences that use anonymized proposals, often result in a more balanced speaker group. See !!Con:

Proposals will be anonymized to avoid bias. Although we ask for your name, email address, and so on in the proposal submission form, only one or two organizers who serve as anonymizers will actually see this information, and they won’t review your proposal. The rest of the organizing team will review your proposal without knowing who you are.

Here are the speakers that resulted from that process.

A blind process won’t guarantee a balanced result, but I believe we have enough evidence to believe it would improve balance.

What Employers Could Do

If an employer wanted to move to a portfolio review, I’d suggest something like the following

  1. Explain it clearly in the job posting
  2. Make it clear that the piece does not have to be big
  3. Ask for code and writing samples (blogs, StackOverflow answers, etc)
  4. Give some idea of the judging criteria
  5. Offer to pay applicants to create the portfolio piece if they don’t have one. I would say to do this on self-reported need. Perhaps after passing a resume screen
  6. Do it blind
  7. Create a rubric that takes many attributes into account (not just “algorithm implementation”). Examples: documentation, tests, consistent code style, reasonable abstractions, correct use of language/framework idioms.
  8. Train the judges and have each portfolio scored by many people

And for their current employees—give them time to create public works (open-source, blogs, etc).

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.

GitHub Profiles Update

The latest GitHub update includes some nice additions to the profiles page. A few years ago I wrote that you should never link directly to your GitHub profile in your resume or online bios:

GitHub’s public profile isn’t customizable and doesn’t do a good job of describing a person’s contributions. I recommend:

1. Create a page with a simple URL on your own domain (e.g. example.com/github) and write a narrative that takes me through your repositories.

2. Link to that page in your resume and in your GitHub profile.

I played around with my profile and even though it’s more customizable, my recommendation still stands: link to a page where you can put context around your profile.

In addition, I think it’s worth using the repository pinning feature to highlight the projects you would want someone to look at if they should get to your profile page some other way.

 

Resume Tip: Link to yoursite/github, not github.com/you

UPDATE: I revisited this recently in my post Use GitHub Profile Pages to Mirror Your Personal Site. Be sure to read that too.

I look at dozens of tech resumes and StackOverflow Careers profiles a day and I’m glad that more of them have GitHub links with some code to look at. In 2011, I wrote that I thought tech applicant assessment should be more portfolio based. I described what I would be looking for as an interviewer — one point was:

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.

Now that I’ve been spending time in GitHub with the intent of understanding a developer, I can see that I need an overview of the whole repository. GitHub’s public profile isn’t customizable and doesn’t do a good job of describing a person’s contributions.

I recommend:

  1. Create a page with a simple URL on your own domain (e.g. example.com/github) and write a narrative that takes me through your repositories.
  2. Link to that page in your resume and in your GitHub profile.

What exactly you do on this page really depends on your specific contributions and what kinds of jobs you are applying to. I made a GitHub tour page to dogfood my own suggestion, but also because, as a consultant, I imagine that some prospective clients look at my GitHub. I decided that a reasonable organization of my page was (approximate) reverse chronological order, but that might not be right for you. If you have a particularly popular project, you probably want that at the top. If you are looking to get a job in a specific technology, you should highlight contributions using it. Most importantly, edit the list down to what someone should look at.

Another benefit of this page is that I can mix-in the non-open source parts of projects. For example, App-o-Mat is not open source, but the app template is, so I can highlight a project that you can’t even see very well on my personal GitHub page. I can also describe a contribution where the code isn’t very interesting, but context is.

Whatever your contributions, I am sure that your own organization of them will be a lot better than GitHub’s default.

UPDATE: I revisited this recently in my post Use GitHub Profile Pages to Mirror Your Personal Site. Be sure to read that too.

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.