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.
Is it just me or isn't Data Science used in an even more vague manner than Software Engineer is used. I mean on a daily basis I encounter people that call themselves Data Scientists who would never be able to use the title Software Engineer or even programmer as they wouldn't be able to write a single line of code if asked.
Exactly. I have a lot of acquaintances who self-describe as data scientists. They really run the range all the way from "they poke around with Excel" (ie not only could I do that in my sleep, but you couldn't pay me enough to do soemthing that dull) all the way to "novel algorithm design at the frontier of the field" (ie I could take classes, train, be mentored, etc and never be able to do what they do).
You're looking at this through a purely technical lens.
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.
Many things are simply complex and there is no way to 'dumb it down'. QM is probably the best example where the 'every man' description has almost nothing to do with the underlying theory.
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.
Yeah, but your code is ultimately achieving some business requirement or it wouldn't be there. Being able to articulate that is an invaluable skill. Requirements are generally poorly written, so if something needs to be done a certain way (e.g. so the numbers in the reports across multiple products are consistent) then the business sometimes needs to know the algorithm.
I'm not implying one is inherently better than the other (well, maybe my inner tech bias is showing, but in objective terms I agree - they all have their purpose) but the point was that "data scientist" as a job title is effectively meaningless. If you tell me that yor'e a data scientist it means absolutely nothing to me because the range it gets used is so broad
Thanks for your comments. Whilst we cannot remove ambiguity completely from our solution - we can minimise it. The ambiguity of text really comes into play in CVs and job descriptions. We attempt to minimise the ambiguity by asking software engineers/anyone involved in software development to describe their work in a uniform way and not relying up the traditional artefacts. So whilst the terms have ambiguity to them, companies and people are answering the same question and we are using those answers to match people so that they can begin a conversation.
We don't do any ranking per se we just present how you want to spend your time. So it does not factor it in. It is up to you to decide what level of seniority the type of position you would consider going for.
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.
I find it interesting that your graph leaves out any mention of innovation or invention.
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.
(1) Surely culture and technology stack are reasonably independent of the dimensions considered here
(2) Wouldn't you agree that this asks an important question which is currently absent from the hiring conversation?
(3) Even if the spider plot is an imperfect representation, isn't it a helpful starting point for a conversation between a potential employer and employee?
(4) I'm not sure what your concern is about toy models and management. All models are toy models, the only thing which matters is whether they lead you to ask the right questions.
I like the concept but personally when I look at a resume I never* look at job titles anyways - they're effectively meaningless when compared between companies. Instead I read what they self-describe themselves to be doing, which is basically what you're doing albeit in visual form.
* Within a single company titles usually are meaningful, so title changes while staying at the same company I'll take note of - particularly promotions
Once you get to a certain size of company, you have the normal career path of (entry level functional job) > manager > director > vice president. Depending on the size of the company, there may be sub-levels such as junior/assistant > senior > executive/general. The levels usually mean the same thing across companies.
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.
> Once you get to a certain size of company, you have the normal career path of (entry level functional job) > manager > director > vice president.
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.
> "executive director" at many companies means "director who will never get promoted to VP".
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'm thinking more in the realm of things software developers (as that's what TFA is focused on) are often referred to as. For instance, an anecdote I like to give here is that I've worked at companies where "senior software engineer" meant "we didn't hire you fresh out of college and you're not a manager" (i.e. nearly everyone) and I've worked at places where SSE meant "you're nearly a manager in terms of seniority"
I was going to make the VP at a bank point but you already did for me :)
Ok, if you are indeed asking the same questions that helps. I would add some information per item with some explanation or definition, so it is as clear as possible what is meant by the different terms.
It is available right now if you hover over the labels on the chart. It is definitely not immediately obvious though so we shall have to work on that - thanks!
Great underlying data, but sad to see it visualized as radar charts.
- 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.
Good point, but I could imagine certain shapes becoming very recognisable after a while. Ensuring the ordering is such that a 5-1-5-1-5...pattern is unlikely, since these spiky shapes will all look the same. And yes the angles don't carry any extra information, but they are a helpful guide to the eye. I can see where you're coming from, but thinking about these plots a bit more carefully I think you are too dismissive.
This is a fair point and something we are actively pursuing. Right now the radar plot represents a trade off between an effective interactive form of visual input that is also compelling and provides an easy mechanism for visual comparison (with the shapes overlapped).
Yeah, if you can come up with a way to give the viewer a "sense" of the person at a glance it would go a long way. Maybe add colors? Or maybe consider that some metrics are pretty related and could be represented separately. Frontend / backend could be represented as a continuum by itself. UI/UX are sort of tied with front-end, so coming up with a way to link those together might be nice. Perhaps you could use the data you have to see what tends to be linked together and come up with 2-3 representations that communicate what you're going for quickly.
really cool data in those distributions, definitely spent way too much time flipping back and forth from one tab to another. Maybe unsurprisingly, javascript is every groups' most reported skill and full-stack engineers tend to be more senior. It'll be exciting to watch as your data set grows
We will continue to share our data set and insights. When we have more resources we will undoubtedly spend more time on analytics and infographics so that we can share back with the community on our findings.
I think the results have to do with your questioning. For example, I don't want to spend my time testing, but I have to do it if I want to write high quality software. So some people give testing a 0, because it's not something you actively want to do. And others give testing a 5, because they know that whatever job they'll take, they probably have to test their code. I don't really see much difference to the classic self-made bullet-point-list of skills.
For example, I don't want to spend my time testing, but I have to do it if I want to write high quality software.
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.
When you start dividing responsibilities horizontally like this, IME you end up producing worse software. Being responsible for testing drives you to good design. Being responsible for deployment raises considerations you might otherwise miss. When development and QA are separate it's all too common for only one to have an understanding of the actual customer requirements.
Better to slice vertically. Everyone takes responsibility for a small piece of functionality, end-to-end.
If you have ever read about Carrot in Pratchett's Discworld series, you may have a new understanding of laziness.
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.
Except that you'll pollute your code with all sorts of design decision and syntactic clutter that make sense only in the light of testing. Except that it will take you so much time to test trivial functionalities, you won't have time to write or just think about them better. Except that your tests won't actually capture all failure cases, but only those you could think of at the moment of writing them. Except that you'll spend a good percentage of your time maintaining tests that break for the wrong reasons - that is, perfectly working changes to your code.
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.
A quote from a Presbyterian sermon published in 1856 eventually evolved into a quote fraudulently attributed to Abraham Lincoln in a 1960 advertisement.
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.
Before the code even gets to QA it needs to be functional and as bug free as possible. As a developer, I _hate_ it when my fellow developers send crap to QA because they could not be bothered to make it not crap. It is unprofessional.
The goal should be to produce SW that does not get rejected at QA.
Yeah, I agree on principle. But sometimes you look bad in front of QA because you ask them to do their job. To give you an example - I was implementing an achievement for a console game. The achievement took roughly 3-4 hours to test fully. I was specifically told by my manager to do my best to make sure that it works,but not to spend time testing it myself,because it would be a waste of my time - it's QAs job to test things like this. So obviously, when the achievement didn't trigger after 4 hours of testing, I looked like a dick to QA,who just spent 4 hours testing this thing.
Unfortunately some people take this approach for everything and never test their code - that's bad.
Seems like you should have been able to give QA a game state that was close to the achievement. Even having QA burn 4 hours of time is wasteful when a game is nothing other than state that can be loaded to any arbitrary point.
Yeah,but the achievement consisted of 44 individual triggers, and for the test they had to trigger all 44. You couldn't give them a state with 43 already triggered. Not to mention that if you change the achievement triggers you have to wipe the save data in make the new triggers work, so they had to start from scratch every time. But fortunately it only had to be done twice in the entire project.
Like that you have picked on the team aspect. We have a very exciting new feature in the works which focuses on presenting the team that you would be joining and how you will compliment each other in terms of how you collectively want to spend time.
I would interpret a testing of 0 as willing to write the minimal number of tests needed to get their code working and 5 as willing to spend all their time developing the company wide testing framework and testing policy and making sure it's continually updated and being followed, as well as being the last person in the chain to sign off on the fact that any software leaving the shop as passed all the tests.
Basically being a 5 means you want to own that aspect, if necessary at the exclusion of everything else.
Your interpretation seems like a reasonable scale - however, it is a very vague definition of "0". I'm sure some people want a 0 to mean an actual 0, like a blind developer asked to do UI development.
Yeah, sounds like a joke. But I worked at a company where the tech writer was legally blind, the marketing guy was shy and the spokesperson (CEO) stuttered. Weird place.
I'm not a fan of the WorkShape matching algorithm. The form isn't in regards to proficiencies but rather what your ideal job function would be spanning all proficiencies.
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.
1) Are people good at evaluating what they want? Its a liberal arts truism that they aren't. Enormous piles of literature about non-technical topics "love" "lifestyle" etc. I'd be shocked if humans are truly excellent at self evaluation uniquely for technical topics.
Interesting and thought provoking article. I wonder if this could take off as a concept and change the way we define ourselves? I like the concept.
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.
P.P.S. I'd love to see the ability to add myself as a remote worker. I had to choose my closest major city, which doesn't accurately reflect how I work.
We're in the process of considering a number of new input fields for both organisations and users. This is one that we intend to add in the next few days.
A pretty good way to find people that you want to hire. Perhaps if we can add some experience graphs along with these, we can get a good platform up that actually makes head hunting really easy for small companies who do not have the time or the money to do this properly.
thanks sparaker - its Hung, CEO of Workshape - thanks for your comment. Time / money is what we want companies to save, not only at point-of-hire but also in terms of hiring the right person for the opportunity. Its a blind match on both sides, so we think both parties are able to trust the match more than they would in traditional job discovery platforms.
As for experience / bio - we're probably pull in social data via an aggregator at some point.
So, first things first: Love the software and the concept of visualizing your activity spread in a radar plot. Well done!
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.
Good point, people and function managers get called all sorts of job titles, VP, Head of, Team Lead, Manager, etc and its funny to see how multinational (specifically EU/US) companies deal with this since there is a bit of a "dick measuring" competition for nicest sounding titles among peers.
ukigumo, your experience is the reason why Gordon and I started Workshape.io - all the information out there is historical - what you have done in the past - and nothing at all on what you want to do in the immediate future.
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.
Yeah we definitely want to provide the service to any organisation that is struggling with hiring / workforce issues. Our focus is startup for now - its the market we know - but we'll get to enterprise and beyond, sooner rather than later.
So, let's plug these shapes into a regressor / ranker / classifier, along with some possible target variables (career path, survival rates, yearly office peer ratings, salary after 5 years,) for as many balanced samples as possible, and see what predictive power these might have!
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.
Yes, that would be interesting data. Most companies would output reports from their HRIS systems in wildly different formats, and you'd have to adjust for industry, geo/currency, year, gender/ethnicity/language, and all sorts of things. But just getting that data and the sensitivity that goes with it would be near-impossible unless you were a salary survey company. And then, they get job-level data and not per employee. They charge serious money for the services of analyzing this data and do not make their data available.
It sucks that we are so three-dimensional in our thinking. This "Workshape" is really a 10-dimensional world where we "wander" in our careers by spending time/energy along some axis. Sometimes we actively pursue a direction, "developing my back-end-skills/archictecture" and sometimes we are more/less forced in a direction "this needs testing/documentation". The result is a traveled path which is "my experience", and a direction which is my "desired trajectory forward".
Matching would then be a spatial questions: Have you been [here]? Where are you heading?
Just checked them out - but on a first glance I have trouble getting any meaningful data from the first few user profiles I clicked.
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.
Very good idea, and nice front end implementation. However, for the masses to chew it, it has to be properly advertised. Otherwise you shall have to physically wait until all 30-somethings HR managers and recruiting agents will die and take their prejudice to their graves. (This is how process of dissemination of new views on old things usually take place in science).
It really was only a matter of time before Hung Lee created something like this. He's one of a very small group of people that truly 'gets' hiring in todays environment and I'm really not surprised to see workshape gaining traction. We're still relatively new users but we have already arranged a handful of interviews via the platform.
Thanks Peroni - appreciate your comment. We don't forget your early and continuous support was critical to Workshape.io. Love to see how we can help further - time for us to meet up?
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?
Oh now this is cool. I tried to do something similar for designers a while back[0] but this is a much nicer system! Would love if you added a designer version!
Like it! We are definitely looking to roll the service out to other verticals. Designers will most likely be next considering the complimentary nature of what you guys do! Thanks for the feedback.
This immediately identified a very good match for me. It's brilliantly built, I'm very impressed.
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.
And yet, all the variety within the given categories will only cover a bunch of web developers. I cannot relate to any of the categories in the article, but yet I think I'm a software engineer.
I actually need to update my CV, glad I came across this. Think I'll add one for work experience and another for current perception of 'How do you want to spend your time'.
I like their ideas, but the only thing that changed for me with the shapes is, that I have a profile that doesn't match any job offering. So no win for me, lol
Hey k_3, its Hung, CEO of Workshape.io here. Thanks for signing up and for your comment. We know that the 'no match' screen feels like failure, even when its anything but!
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.
Oh, don't get me wrong, I don't take this personally.
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.
We aren't completely transfixed by job titles, this was just the blog post headline and one component of current recruitment practices we dislike. Unfortunately recruiters may not be so aware of job titles not meaning much - it is still common practice to perform key word search on other platforms to identify candidates. This is a behaviour we are looking to disrupt.
We think so too, and that's ok. Workshape.io is an attempt to bring the 'sentiment match' to the beginning of the hiring process. We think if both parties know that there's compatibility in terms of interest, then they should be good to go further conversation. Its a de-risking tool, I think
True that, but it wouldn't be part of the sourcing process, at least. The problem is CVs just became too fundamental in the selection process, and they're only looked at for something like 5 seconds...
Right, although to me "back end" implies "feeding the front end" which isn't the case here, rather that 2 page report is more of a side channel and the consumer is another data processing engine.
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"
thanks Coogle! Our entire thing is that job descriptions actually don't do a great job of the describing. Text is not the best way to describe human work - its too ambiguous, too hard to make / read and entirely reliant on subtext / context. We think the radar plot is a better way. Glad you like the product - stay with us, a lot more to come from us