Don’t be an Ant! Control Your Career

Ant Magnifying Glass


We’re all ants. Alone we’re crushed under foot and fear the magnifying glass. Our daily grind is borne from lack of belief that there’s another way. There is a way out. A colony of ants can repel much larger predators – just ask anyone who’s stepped on a fire ant hill. You may ask #WTF does this have to do with hiring, careers or job satisfaction? Please read on and I’ll explain.

The projectSHERPA team started our journey to #HackHiring and to be a Sherpa to companies and people seeking their equal and opposite. We want to be the best job search resource for candidates and in serving candidates, we believe companies will come to engage. The market has been constrained to think, as hiring managers, that we need to hire someone who has been there and done that. As candidates we fear (some more than others) applying for jobs where we don’t fit the litany of bullets points on a job description. This has led to inertia, myopia and fear, leaving no room for aspiration and elevation. There is a negative feedback loop where companies recruit the wrong talent, by giving people little room for upward mobility, and people work in jobs that often leave little room for growth.

We at projectSHERPA ask you to stand with us and to take part in a movement that will lead to increased output through greater career satisfaction and proper alignment of aspirations, for both companies and people.

You stand a much better chance of retaining your stars when they feel connected to the mission and were given opportunities to grow into the role. They will only leave for a truly better opportunity vs incrementally more happiness (and/or money). This requires more planning and foresight and also adhering to what I co-opted from Glengarry Glen Ross, Always Be Recruiting #ABR – mentioned in a previous post here –

Hiring teams should learn something from #LeanProduct development by identifying what matters and think of hiring like building a product. Simplify and make it a positive process. I’ve seen companies that look for reasons to eliminate people instead of committing to what they need to hire someone. What you’re often left with is the candidate that has the least amount of weakness vs. the person that could be great.

Only when the trajectories of companies share enough overlap with a candidate’s vision for their career, can we guarantee less turnover and more career satisfaction. Let’s start a brand new colony. We’re taking the first step by launching a new product that will make it easier to build a community and process incentivizing shared goals. Contact projectSHERPA to learn more.

The Skill Cloud, Q2 2014

Updating our skill cloud results to cover all jobs scanned into our system between April 1st, 2014 to June 30th, 2014, the new skill cloud looks very similar to the old skill cloud (see our last set of results here):

Skill Cloud 8.3.14

Last time the top five skills were SQL (25%), Java (23%), HTML (16%), Linux (14%), and JavaScript (13%). This time it’s SQL (29%), Java (22%), HTML (16%), Oracle (15%), and JavaScript (14%).

Results are based on 1,771 NY tech jobs, where we’ve removed posts from agency recruiters (only counting direct postings to cut down on the spam) and accounted for de-duplication (included only new job postings, not recirculated postings with a new due date). The best takeaway I can give for developers is that with the proliferation of Java and JavaScript based libraries, you’ll never go hungry knowing Java, which is ironic since I myself don’t know Java (yet). Also, SQL isn’t dead.

None of these skills suffer from what I call “word soup”, which is what happens when job posters put down a laundry list of skills that might or might not be directly applicable to the job. In addition to the skill cloud we also calculate a skill correlation matrix, which gives us an idea of how different skills are paired together in job postings (see previous posting for a full explanation of the skill correlation matrix). The word soup winner this quarter was Underscore.js, which was highly correlated to [NoSQL, Angular.js, Agile, Rails, MySQL, Riak, jQuery, Java, CoffeeScript, HTML, Node.js, C#, CSS, MongoDB, JavaScript, and C++]. We only picked up two job postings that required Underscore.js, so these results really reflect the law of small numbers and not any real trend. For those that are interested, we also picked up jobs that require Riak (3 jobs), Akka (2 jobs), and Gunicorn (1 job). Gunicornists of the world, we have just the job for you!

The Importance of Being Earnest…in Your Recruiting Efforts

Market honestly if you want to attract software engineers. They are not stupid and are masters of research and information arbitrage. Don’t assume that just because you think your idea is unique or proprietary that it actually is. The beauty of the internet is that given enough effort, anyone can find just about anything, about you, your industry, past attempts to solve the problem etc. By not properly articulating the good, the bad and the ugly, you risk a few things:

1 – Someone you want to hire bails during their due diligence process.

2 – Someone you hire discovers that your company isn’t what you told them it was and they become pissed off, toxic and eventually leave you. Everyone they know will now be unattainable.

3 – They stay with your company but are so checked out that you eventually have to fire them, but not until they have drained your budget and caused massive scope creep.

4 – This will lead to a bad review on GlassDoor and any other anonymous site, where you’ll have very little power to refute and any effort to do so will be met with extreme skepticism.

People generally respond to adversity they know they will face and if prepared, can mentally steel themselves. Of course there are always going to be unforeseen circumstances and you can’t be blamed for that – this is just referring to issues you know to exist. It’s important to paint the vision for the future, but still have sketches grounded in reality because vision is just that until it’s executed – then you have a winner. Good luck and if you need help hiring, call a Sherpa!


Building Stuff is Hard. Keep Trying.

Building a company is hard. No shit sherlock. Well it’s not so obvious when you have certain apps that are built around a stupid colloquialism and have otherwise very smart people pouring money into it. We have become a world that is avoiding solving tough problems and focusing solely on short term gains of material wealth (with some exceptions). Where are the fountainheads for innovation? They walk a lonely path of having ideas and companies die because they can’t demonstrate the right metrics around user or revenue growth. Had the innovators of the past been tied to similar metrics, I shudder to think where we would be as a society. We tout the advancements of our technology and our internet of things, but all of those things are nothing, when thinking of the brilliance of things like AWS. But ironically, AWS has been the catalyst allowing dilettantes to build a generation of meaningless things, rather than germinating true greatness. I love and loath it for democratizing entrepreneurship, because it creates lower barriers to entry and allows anyone with a little cash to pursue ideas, regardless of intrinsic value. The common retort is that someone values it so it has value, but that is pandering to the lowest common denominator.

In the past 2.5 years I have worked to solve a problem that would truly benefit all market participants, only to have to bow down to the Lean startup notion. While I understand using the scientific method to validate whether the smallest test of whether something is truly useful, one must ask, does the public really know what is good for them? Copernicus and many others come to mind when thinking of revolutionaries, and I certainly don’t profess to be as innovative as them. However, in pandering to the almighty metrics of revenue growth or user growth, I find myself making endless compromises against what I truly believe is the right solution. It seems like the flavor of the year is mobile connected commerce, where you have a basic workflow connected to an app. While I applaud those businesses for generating revenue, I hope the successful among them follow in Elon Musk’s footsteps and use that wealth to pursue the next level problems that will be beneficial to society. Remember, until we have legalization of stem cell therapy en masse, you will die before 100 years of age. Let’s think a little about future generations and remember, you can take it with you. In the meantime, I’ll continue bootstrapping my little company hoping that maybe someone with deep enough pockets will say you guys don’t completely suck and have some valid ideas.

How to Create a Model

As requested by Ben, here are the steps I follow when creating a model:

  • Determine the model outputs
  • Brainstorm the model inputs
  • Validate my assumptions
  • Build the model

The first step when I want to model something is determine what the model is supposed to do, i.e. what are the outputs? This sounds like a fundamental step, but when it comes to creating models the expected outputs can be ambiguous, especially if you’re doing something new. In the world of finance (where I come from) the expected outputs are usually well defined (e.g. NPV, accrual, delta, etc), but in data science the goals can be harder to discern.

To determine the model inputs I take a blank piece of paper and write down everything I know about the subject. My mother was an elementary school teacher, so growing up I was exposed to a lot of “webbing”. I tend to free associate for anything that I think is related to the topic – I don’t exclude any ideas at this step and pretty much write down any random thought.

The next step is where I start to go through my input list and pare it down. I’ll start searching online to see if anyone has done this approach before, and exclude ideas that aren’t viable (usually ideas that don’t have enough usable data or are not relevant to this topic). I’ll gather information and see what’s correlated to what to reduce the size of the required data. I don’t have a model yet, just a collection of possible inputs.

Once I’m done with the inputs is when I determine the shape of the model, based on the goals of the model and the actual data I have available. I’ll test and retest with different configurations (e.g. normal, lognormal, mean-reverting, etc), always checking to make sure the results I’m looking for make sense. I’ll probably have some simple examples prepared to test the model, to make sure it’s working as expected. During this time I make sure I don’t fall into the trap of modeling for modeling’s sake. If I have a 20-factor model that returns the same results as a 2-factor model, I’ve wasted my time on 18 factors. I try to keep the model simple.

When I have something that I think works I’ll run the model and the results past someone who’s familiar with the topic to make sure I’m staying within reality. The purpose of any model is to measure something – if the model isn’t measuring what I planned for it to measure, then it’s not a working model. I recommend this book, which I’ve found useful in helping to clearly define what I plan to measure.

Test Driven Specifications

A lot of the functional specifications I’ve worked with in the past have a similar format – business use case, a couple of mock screenshots, and some business rules (BR 1, BR 2…BR N). Usually they’re enough for me to get started, or least get a handle on the project we need to deliver. This is where I think business analysts and developers tend to differ – I think of the spec as a jumping off point, and most of the analysts I work with take it as the final word.

Because of the nature of coding, developers tend to be very rule based. The disconnect I’ve had with analysts are usually about the nature of the rules presented in the spec – from a business use case, the rules are usually through (i.e. “Under these circumstances, the user should be able to do X” type of rule). From a development standpoint, the rules tend to be too generic and don’t cover enough specific cases (developers tend to ask questions like “If A and B are selected together, should the result be C or D?”).

Once the functional spec is completed, I think there should be an additional step where all involved parties get together (business analysts, developers, and testers) and propose examples that the business analyst has to mock up with all of the expected results (no dummy numbers!), i.e. “If I choose A and B together, I expect to see C as the result” type of scenarios. I tend to ask for a lot of these types of mockups when I’m working on a project, and the outcome is usually positive – since we’re able to visualize what the results should look like, it makes it easier to determine the underlying rules in other cases. Creating concrete examples also helps the analyst determine if the business rules in the spec actually cover all possible scenarios, and gives the tester something practical to test (and create permutations of that test) during the testing cycle.

Follow the Five-Fold Path to Great Hires

No matter level the hire, you want people who demonstrate what we projectSHERPA – @sherpaproject feel are the 5 keys to hiring strong technical folks – Communication, Collaboration, Coding, Raw Aptitude and Problem Solving. I’ll briefly define the 5 keys.


While it’d be nice if everyone sounded like Barack Obama when they spoke, it’s not necessary. Accents are ok, but do you need to clearly and efficiently express concepts. This is increasingly important as you have leaner teams that own end-to-end product development. Front Office roles in Capital Markets or Lean Startup engineers MUST have effective communicators. 


This is whether a person is able to clearly communicate with others and work towards solving a problem. This doesn’t mean being artificially nice. It means adding value, and being willing to say this isn’t working, let’s try another approach (in a pleasant way), while also being receptive to criticism.


Does your code reflect best practices? Have you brought a mindset of refactoring and like good writing, is it concise? Remember, someone else may inherit your code. Be nice and be consistent in your approach. Efficient code requires that you understand use cases and are writing lots of tests to achieve the most elegant solution. This in turn requires buy-in from management to adopt this approach, which may slightly slow the development process, but should lead to much better Total Cost of Ownership (TCO) and ROI.

Raw Aptitude

This one may be controversial. annoying and Google recently said that brainteasers have no bearing on future success. It’s a small component of being successful, but necessary nonetheless. If people are simply unable to grasp complex concepts, they probably will not be successful. You don’t have to assess raw aptitude with long tests, but this is where you present someone with an unfamiliar scenario and see how quickly they learn/adapt.

Problem Solving

The whiteboard may be more useful for a big company, where often you don’t reserve time to do paired programming over a half or full day. It can be particularly powerful in assessing problem solving, which is critical to understanding whether someone will be a good architect or product designer. Do they have the combination of inductive and deductive reasoning skills to build highly efficient and effective solutions, which balance speed vs. feature depth vs. cost, etc.? When assessing this, I ask, “do they understand the algebra of solutions design? If they lack this ability, they will always have to be given tasks vs. being able to take ownership.

Closing thoughts

Have a Plan

Understand how you evaluate people. This doesn’t mean you can’t change your approach – in fact, you should always be refactoring your approach, but have a logical reason why.

Hire for Culture

No matter how exceptional someone’s technical skills may be, if they don’t fit your culture, they will not succeed and you will have turnover. Further, poor culture fits can create toxicity in your culture, leading to turnover.

Be Future Greedy When Hiring

You should strive to hire based on fulfilling present need, but trying to align career growth. Otherwise, when your hire soothes the “hair on fire” pain, they will likely be bored and leave.

Lastly, if you want specific advice based on your own use case, reach out. Remember, the path is treacherous, but it’s always safer with a projectSHERPA

Hopefully this helps,

Ben Ross,


The Skill Cloud

 Skill Cloud 5.20.14

One of the first things that we do when we prepare job postings is to turn all listed skills into tags. It makes it easier to search for jobs, as well as track and look at patterns. What you’re seeing above is a word cloud generated from skill tags connected to all the NY tech jobs in our system that were created from January 1st, 2014 to May 20th, 2014 (755 jobs). In this case, we see the usual suspects – SQL (25%) and Java (23%) show up the most, with HTML (16%), Linux (14%), and JavaScript (13%) rounding out the top five.

We can also take this data and calculate what we call “skill correlation” – skill A is correlated to skill B by calculating the number of times skills A and B occur together in a job post, divided by the number of times skill B is tagged in a job post. Unfortunately this doesn’t make for a great graphic:

Skill Correl

Some of the high correlations are expected (HTML: CSS, JavaScript; Python: Java) and some give us insight into how the market is thinking (Node.JS: MongoDB, Python). Other skills are victims of word soup (e.g. GIT, Meteor) – these are companies that list 15+ skills in the job description, making it hard to determine what is relevant and what are buzzwords.

Though we only show a couple of key skill tags on the main search screen, all of the skill tags in the job descriptions are clickable and take you to all jobs with that skill – try it out and see the full range of jobs available in our system.

Career Management, Not Job Management

My father worked all his life for a large Fortune 500 company – he started right out of grad school and retired from the same company 43 years later. He worked in multiple departments and locations, and his resume covered a lot of different areas of expertise. He was able to do this because his company provided training and career guidance, which they did because at that time both employer and employee expected a long term commitment from each other.

Times have changed, for better or for worse, and most companies don’t have the time or the resources to provide that type of career option. On the employee side, this has led to greater flexibility (I have job options that were never available to my father) but makes it harder to chart a career path. There aren’t many companies that can provide “employment for life”, which means that switching jobs and moving to a new company every few years is the only way to move up. Job mobility is a natural feature of the job market, especially in the technology industry.

At Sherpa we think a lot about this – we don’t like to think of ourselves as a job board, but as a career management tool. In the next few months we plan to roll out functionality that will focus on career management, making it easier for candidates to map out and track their career goals. We can’t tell you where you should go, but we can provide examples of people who have “walked the same road”, allowing you to decide where you eventually want to end up. There are many options available to candidates, and we want to help guide you in the direction that works for you.

Management wants to know “Are you done yet?”

When I’m in a philosophical mood about the nature of business I like to ask myself the question “What is the point of project managers?” (see also Larry Page’s historical treatment of project managers here). I admit that I’m not the easiest person to work with, and I tend to be brusque with the stereotypical project manager that runs around asking “Are you done yet?”.

Having said that, I do see the point of project managers. My feeling is that the central responsibility of project managers is communication – making sure that they keep track of the promised deliverables, know who needs to be in the loop and when, and guaranteeing that resources are available as necessary. For me, the difference between a good and a bad project manager is understanding the difference between “closing the item” and “resolving the issue”. “Closing the item” means checking off an item on a to-do list. It’s a mechanical function that fulfills the requirements. “Resolving the issue” means determining the goals of the project and making sure that we’ve accomplished them. It’s a fine distinction that I think is critical to keep in mind when working on a project.