Catching­­ Unicorns & Purple Squirrels

Catching­­ Unicorns & Purple Squirrels

I recently ran across a job listing for a Solution Architect position.  It’s common to see these include significant knowledge and experience requirements in high (or low) level languages, recent experience in new technologies, and solid fundamentals in well-established standards.  Check.  What was confusing to me though was the buzz-word bingo sheet that the job listing appeared to be.  Recruiters have started calling this candidate the Purple Squirrel for good reason.

To paraphrase: they wanted “Expert” level knowledge of Java, “Expert” level knowledge of Microsoft Stack / C# / .Net, significant experience with Microsoft and Google cloud platforms, and “preferred” someone also have knowledge of Node.js / npm / etc.  This was in addition to all the standard database proficiency and having both desktop & web experience.  The last two are often in some ways are orthogonal to each other unless you are a consultant, or you like to switch projects frequently.  I’ve even been guilty of contributing to this when we start to add skills to an existing role definition without re-evaluating what that position really needs.  Recently when tuning a job listing for a candidate Senior Software Engineer position, I scratched off half the carry-over items that had been on the existing list for years prior since they were irrelevant now.

This reminded me of the cartoon where someone was asking for a developer with 5 years of [JavaScript/NodeJS/JQuery] experience when the language/project was just two years old.  Nowhere in the job listing did they mention skills that would make this person a good fit within a delivery team.  Nowhere did they list that they needed someone that was diligent, a team player, and had a great attitude.  Sure, these are things I usually interview for, but it was the true “Purple Squirrel” list, or quite possibly an ideal one-man-band that could play basically every position needed equally.  If you see this, walk away.

I don’t think I’ve ever fully met every single bullet on a “required” skills list on a job posting [upcoming link to: [“Fake it til you make it”]]. If I did, I would immediately know I was overqualified for the position.  Maybe it’s pent up frustration from being denied employment from McDonald’s when I was 15 years old for being “too qualified” (which lead me to start a business assembling and selling PCs in my parent’s basement, literally), but I have always strived to look beyond my current role, and instead, to where I could be growing and contributing more.  If you can do everything on day one that a position requires, where will you find professional growth opportunities and fulfillment?  I would absolutely say you should be applying for jobs where you will be stretching yourself, but not the truth during your interview.

I wish at some level recruiters and hiring managers would be more authentic and honest in their listings.  Of course, that is a double edge sword.  “Looking for incredibly skilled engineer to join a team that is way behind on a massive project with mountains of technical debt and no management strategy in sight other than to hire quickly” – probably doesn’t attract as many candidates as: “Looking for an expert in X, Y, and Z languages that has solid fundamentals and recent technology experience (that may help shovel the hole back in that we dug ourselves)”.  Of course, both listings may be for the same job which is scary.

One of the most effective delivery teams I can remember working on was a scrum team with developers with well-defined skills that many would consider “full stack”, but each had room to grow.  I called this team “The Dream Team” after the 1992 Olympic Men’s Basketball team.  My fellow developers weren’t perfect purple squirrel, nor was I.  One developer was very strong in JavaScript and helped research and implement a strong front-end framework for the new application.  Another was incredibly gifted at optimization, SQL and data structures.  When I thought incorrectly that a feature request was “impossible”, he came up with a fantastic solution of a denormalized data structure that would be regenerated nightly, detect changes, and then heavily cached.  I provided comic relief and established an architectural pattern we could all contribute in that is still in use to this day (~12 years later).  Sure, if one of us was sick or on vacation for a week the team would continue to operate in the true meaning of scrum, at slightly degraded velocity.

If all the developers on that scrum team had been full stack purple squirrel ninjas we would have had little to learn from each other.  Additionally, our small startup would have had to pay a handy ransom to keep us together every time someone caught wind of us and tried to break up the band.

I have seen other effective team structures before and after this one, but none have matched the mutual respect, comradery, and sheer output of that dream team.  It was one of the first times I had seen a team become close to burn out due to the high cadence of features we were able to release.  If you are reading this from that team, then you know who you are and you likely remember those times as fondly as I do.  I hold a special place for you in high admiration for how well we supported each other’s strengths – and weaknesses.  We may not have been purple squirrels then, but we definitely deserved the Gold medal.

P.S. I recently ran across this listing for a Technical Program Manager at Providence Digital Innovation. I think they read my mind as I couldn’t help but be inspired and in awe of the way they described in detail WHO they were looking for, not just “WHAT”.