Skip to content

Instantly share code, notes, and snippets.

@vmbrasseur
Created March 17, 2015 18:15
Show Gist options
  • Save vmbrasseur/fc621922b09f5fbc5caf to your computer and use it in GitHub Desktop.
Save vmbrasseur/fc621922b09f5fbc5caf to your computer and use it in GitHub Desktop.
Senior Engineer description

We're currently unable to support more junior engineers and therefore are looking for people who are more senior. Unfortunately, a large percentage of our applicants are very junior. That will always happen to some extent, of course, but it would be good to minimize it rather than having to reject good (but too junior) people.

In reviewing our job descriptions, I see that they don't really mention a desired experience level. There's a little "mid level" at the top of the posting, but it's non-obvious. I'm looking to revamp the postings to better reflect our needs (mid-/senior-level) to allow candidates to self-select out if they do not have enough experience to qualify.

I believe that defining seniority by "$x years of experience" is a pile of crap and is used simply because it's easy. So instead I'm considering stating that a mid-/senior-level programmer is necessary (perhaps calling out that we're unable to support more junior engineers at this time) and then listing some of the character experiences through which a mid-/senior-level programmer has been. Describe the role/level by experiences/knowledge rather than shortcutting to years.

This is, naturally, easier said than done (which is probably why I can't find anyone who does it). As well, there's the danger that (depending upon how they're presented) the experiences might be mis-interpreted as requirements rather than characteristic examples. But careful wording may avoid that problem.

OK, that's all introduction. Now for some brainstorming on some experiences which might be shared across senior engineers:

  • Been all hands on deck for a fire drill/tire fire/crisis/call it what you will
  • Resolved enough gnarly problems to have a decent intuition for where to start looking when a new bug arises
  • Able to express why a specific piece of code could use refactoring and in what way
  • Propose using a new technology not because it's new but because it's the right thing to do (and able to support why it's right)
  • Recognize it's never a good idea to write your own parser for HTML, CSV, JSON, or similar (unless it's a personal project to challenge yourself)
  • Are more likely to look for existing solutions than immediately start writing your own (general case of the above point)
  • ...?
@vmbrasseur
Copy link
Author

Comments from IRC:

[14:31:03] <> 08:22 I'd say the difference between junior and senior is entirely about being able to make independent decisions about how code is put together
[14:31:07] <> 08:24 so this comes down to: choosing appropriate tools, structuring code appropriately (as well as "correctly"), and being able to justify the quality of the code (through testing or otherwise)
[14:31:09] <> 08:24 conversely, being able to provide "correctness" is about the only skill I'd expect of a junior

@vmbrasseur
Copy link
Author

Relevant tweet:

https://twitter.com/scalzi/status/578979830890377217

Being an expert/pro doesn't mean you're right about everything in your field. It does mean you likely know when others are wrong about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment