The Problem with Job Titles
blog.workshape.io
blog.workshape.io
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.
I was going to make the VP at a bank point but you already did for me :)
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."
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.
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.
My understanding is that "data scientist" is a term meaning "statistics person who lives in San Francisco"
- Each category majorly affects the reading of the category next to it, which isn't helpful in non-sequential categorizations
- The difference between two adjacent categories creates a unique angle and shape that is purely extraneous information
- The relative sizes are hard to read as the underlying quantities aren't proportional to the displayed areas
Although not the prettiest possibility, a grouped column chart (maybe groups for front-end, back-end, maintenance, culture, etc.) is a simple example that avoids many of these issues and has very good readability at a glance.
Appreciate the feedback.
As for the trends check out these links to see histograms showing related aspects according to different job titles:
https://www.workshape.io/infographic/frontendengineer https://www.workshape.io/infographic/backendengineer https://www.workshape.io/infographic/fullstackengineer
Thanks for the comment.
Unless everybody is forced to answer the same question the shapes are useless.
Basically being a 5 means you want to own that aspect, if necessary at the exclusion of everything else.
Why?
Someone has to do the testing, obviously, but why does it have to be you just because you want to write good quality software? Why can't you work with a brilliant QA[1] team who can generate an awesome set of processes and tests based on your specifications? You don't have to do the bit you find boring if there's someone else around who loves doing it and will do a better job of it because they don't find it boring.
Giving up parts of the development process is part of being in a team. A very important part.
Using the idea in the article along with good knowledge of what's needed in the particular problem domain, it should be possible to use 'workshapes' to put together a very suitable team of people for a project.
[1] Important note for the unfamiliar: Most QA teams are actually QC teams. QA (quality assurance) has to happen from the very first stages of a project, putting in processes that assure the right level of quality will be met. QC (quality checking) happens at the end where someone goes through a project and makes sure it's been done well. If your "QA" only happens at the end then it's QC, and it's probably not helping you build the best product you're capable of building.
The goal should be to produce SW that does not get rejected at QA.
Unfortunately some people take this approach for everything and never test their code - that's bad.
Better to slice vertically. Everyone takes responsibility for a small piece of functionality, end-to-end.
Carrot, you see, is so lazy that he exercises every day, because it is easier to accomplish things in a fit body than in one that is fat and weak.
Testing your own code is that sort of laziness. You write automated unit tests so that you will never have to look at or touch that particular bit of code ever again.
Having that sort of laziness will also make you an expert in design, because good design allows you to write concise, maintainable code, which makes your job easier.
Sure, testing can be extremely useful and important in some cases. I'm thinking of complex engines that power business flows and applications. Testing user interfaces and MVC controllers is hypercorrection and usually a waste of time.
If you have 5 minutes to cut down a tree, spend 3 minutes sharpening your axe.
If you are cluttering your code to make your testing easier, you are attempting to sharpen your axe by repeatedly striking it with the trunk of a tree.
If your tests fail when refactoring working code to working code, your problem is the manner in which you write your tests. I have seen testing done well, and testing done poorly. And in light of the latter, I can see why someone might dismiss developer testing. Having both as a basis of comparison, the shop that used TDD accomplished a task in two months with 3 people that the other shop could never have accomplished in 2 whole years with 15 people.
The bad shop mandated testing, of course, as a cargo cult ritual, but metaphorically, in order to test the shear strength of a single bolt, you had to launch the whole Space Shuttle. I often saw methods written with a boolean parameter called IsUnitTest. I am not making this up.
That was a clear difference between smart-lazy and stupid-lazy. One shop sharpened the axe before cutting, and it was felled on time. The other held several hour-long meetings, decided to cut down the tree with a rubber mallet, declared that it would take about 20 minutes, and assigned the task to me entirely without my input. When I suggested an axe would work better, I was told that the mallet was already decided, and if I used an axe instead, I would be fired. When it was later discovered that I used the mallet to strike a splitting wedge, I was deemed to be undermining the axeless mandate, and was fired.
This is metaphor, but there is no hyperbole. This was the shop that banned me from using lambda expressions in C#, because other developers on the team could not understand them. In 2014.
Be smart-lazy. Do the simplest thing that will get the job done. If automated tests do not make your job easier in the long run, don't do them. If some design pattern would needlessly clutter your code for no benefit, don't use it. These decisions are easy to make when they are not being made for you.
Realistically, one's experience isn't likely to match up with their ideal working environment.
Trying to pair an employer's requirements to an applicants ideal job would require an order of magnitude more users on both sides before you see realistic matches.
2) (Only kinda kidding) Where's emergency fire fighting? Escalated customer support?
One thing that is lacking however is perhaps an understanding of what job titles are today. I haven't formally been handed a job title in many years, so long in fact that I honestly can't recall which previous employer was the last to grant me a specific pigeon hole at the personnel level. (Yes, I deliberately use the antiquated term for HR to illustrate how long ago this may have been).
In this day and age job titles for me and my peers appear to be ultra concise summaries of what capacity people are most recently working in, as opposed to formally designated titles. Perhaps we're stretching the word title.
Regardless, the fact that these charts better represent the fluid nature of how interests and activities change, this would be a nicer solution. Two thumbs up.
P.S. I say this with no snarkiness, I wish people would proof read articles they publish.
As for experience / bio - we're probably pull in social data via an aggregator at some point.
Now for the rant: I am an IT architect. There are many architects working in IT but few of them do anything that is related to what I do. I see job postings for Enterprise Sharepoint Architect and I cry a little, others for CTO/Architect/senior developer and I question if they are maybe hiring for 3 positions and are just really bad at writing jobspecs. I often have VPs working under my direction and govern the work of Project Managers and yet people contact me and ask if I'm interested in a devops role.
Recruitment is broken and I hope companies like workshape.io are here to fix it.
Glad you like the service - keep an eye on us, there's a lot more to come
May I offer some advice though? Big corp also needs help finding talent (maybe more so than startups) so you may want to _also_ target that market segment going forward.
Good luck!
Or, I guess the graph itself could also be considered a resume differentiator / sales technique.
Edit: Oh, I see. They're heavy on the highly personalized matching angle.
Matching would then be a spatial questions: Have you been [here]? Where are you heading?
Stupid physical world.
This is great, although I have a different approach, namely https://www.somewhere.com and specifically https://www.somewhere.com/what-is-somewhere
Generally what I look for on a CV or whatever a potential applicant sends over:
- Where have they worked? For how long? And what did they do?
- What did they study?
That's it - I have about 5-15 seconds to find and read that information. If there's something there that I like, then I dive into the rest of what they've written. Am I still interested? Now I'll start digging through their portfolio, web presence etc.
What I am not interested in (until much later in the hiring process) is the random blurbs / thoughts that make them who they are which I think somewhere.com puts on the forefront. It is something I'd glance at to get a feel for who they are as a person, but it really doesn't solve the "CV" delima (if there is one).
Somewhere has a lot more of the between-the-lines information, and we're getting into some of the more linear data now (see https://www.somewhere.com/visualcv).
So that in that, finding people who fit your work style over matching specific skills and experiences. However, you're spot on as both approaches need to pass the glanceability test.
http://www.reddit.com/r/AskEngineers/comments/2w4q6j/worried...
This seems to echo what's been said here, for the most part, but the concern of getting through HR is very real.
Seriously, someone is looking for RabbitMQ-something? I mean, do they really look for someone who deeply understands RabbitMQ or do they look for someone who can administer it or do they look for someone who can use it's language bindings correctly after skimming through docs?
They could do with a little bit of narrative to explain that you're now free to converse with the potential employer, at the point where the conversation thread opens up.
5 thumbs up.
Its simply a case that no employer has seen the wisdom of designing a job opportunity that meets your interest! And its highly likely to be a question of scale i.e not enough companies on the platform.
In any case, we need to get better at that screen and are aiming to produce analytics to describe job distribution (geography, tech stack etc) so that users who see it will come away with better value.
Ping me if you have any more input!
I just wanted to say that this is a bigger problem than you think. The companies have some skills in mind when they want to hire and packing them into a job title with description or a radar chart doesn't change anything.
I think everyone is fully aware that these titles doesn't mean much. I have read so much different descriptions of one title, that I don't read the titles anymore.
"No CVs" sounds awesome, but I think companies would ask applicants for their CVs in the end anyway.
Love d3 animations on the landing page.
[Source: I'm Hung Lee, founder]
For instance, the product I work on daily has no UI (ok, it has a 2 page UI used by an ops group) - is that "back end" when there's no "front end"?
And apologies - this is a bit OT here and I'm not trying to be difficult nor argumentative, I've just often wondered if the majority of people view backend/frontend as specialized terms like I do or if it's really just a generic term for "works on visualization/UI" and "works on the other stuff"