So instead of the ambiguous text 'Software Engineer' we now have 10 ambiguous texts ranging from 'Analysis' to 'Data Science'. I don't really see how that solves a problem, since these underlying concepts are also quite hard to define consistently.
My understanding is that "data scientist" is a term meaning "statistics person who lives in San Francisco"
The guy who "pokes around with Excel" probably operates in a business context. He interacts with people who have no clue about data science, and is able to use the data to tell a convincing story. This can be dangerous if he doesn't know what he's doing, but 90% of things people want to use "data science" for are pretty trivial technically and probably can be done in Excel.
The guy designing a novel algorithm probably operates in a technical context. People like this tend to be very "in the weeds" and incapable of succinctly explaining their findings to people without the same context they have. This is a universal problem -- people who are extremely technically skilled often have trouble explaining their craft to, say, a marketing exec wanting to know how a certain characteristic is derived. In fact, the marketing exec will probably call in the Excel data scientist to translate.
Does this mean the guy designing the novel algorithm is somehow lesser? Absolutely not! But when you choose a deeply technical career path, you run the risk of losing the external context. This is why many companies have managers in engineering who aren't super technical -- they're technical enough to understand the jist of the concept, but their core skill is communication. If they're doing their job well, the engineers are left alone to do their job without senior business people sticking their noses in everything.
Coincidentally (or maybe not), I think the "soft skills" are sorely missing in this skills matrix. Every engineer will have to give a presentation or work with an external team at some point in their careers, and some are better at it than others. In my opinion, the guys with hardcore engineering skills are great, but someone with solid engineering skills who can communicate well is a rock star. You can replace a badass engineer, but you can't easily replace the cross-team relationships that a good communicator has built that can often short-circuit requirements problems before they get turned into code.
In the CS encryption is probably the best example of this where the basic algorithm can be identical between a system protected from the NSA and something trivial to break for the average researcher.
It might be a bit misleading that we use Github for sign up right now, this is mainly just to ensure only developers are signing up - as the service only exists for them currently. We do not use Github for any number crunching.
It also ignores corporate cultures.
Backend engineering for a web startup is very different to backend engineering for a Wall St HFT house. I wouldn't expect someone who worked in one to be expert in the other.
Even within the web startup world, fullstack with MEAN is very different to fullstack with PHP/Apache/MySQL - not just technically, but culturally.
So I think what you have is one of those toy models that management love so much.
I'd like to see some hard big-sample-size evidence that it really does improve hiring outcomes in practice.
* Within a single company titles usually are meaningful, so title changes while staying at the same company I'll take note of - particularly promotions
If someone goes from a manager to a director at a big company, that usually means something. Depending on the company, some titles can have negative connotations - "executive director" at many companies means "director who will never get promoted to VP".
Also, if they worked at a bank, "vice president" means nothing. Nearly everyone working at a bank is a vice president - government regulations restrict access to certain customer data and the ability to enact transactions on behalf of the bank to VP and above, so the solution is to just give everyone the title of VP.
It bothers me that that's considered a "normal" career path. The skills that make someone a good engineer/architect/etc do not necessarily make them a good manager or VP; even if they do end up doing well in a management role, they're then not actually using most of their technical skills. To me, it's a sign of a dysfunctional company if there's no technical advancement path.
Job titles tend to vary more in technical roles, but at least within the computing field, there's a normal career path that goes roughly engineer -> architect/lead/etc -> principal/distinguished engineer -> fellow. There are often several levels within each of those ("senior", etc), and smaller companies may omit the pre-fellow stage (the name of which tends to vary). For many companies, a quick search will turn up what set of titles they use for the top few tiers.
I would hope that isn't unique to software engineering, and that other fields have the concept of advancing within that field without becoming a manager.
That's somewhat obnoxious, because "executive director" has a fairly well-established general definition that is equivalent to "CEO".
> Also, if they worked at a bank, "vice president" means nothing. Nearly everyone working at a bank is a vice president
...and if they worked at a B2B software company for which banks are a major set of customers, almost the same thing happens, because the customers think "if you aren't at least a VP, you aren't anybody."
I was going to make the VP at a bank point but you already did for me :)