Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with Job Titles

blog.workshape.io

Post reply on HN
Print view View original

41–50 of 103 posts

Re: The Problem with Job Titles

#41

Post by genericuser »

arno_v wrote: post #29

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.

Re: The Problem with Job Titles

#42

Post by gambiting »

JustSomeNobody wrote: post #37
onion2k wrote: post #23

Earlier quoted context omitted.

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 bori…

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.

Re: The Problem with Job Titles

#43

Post by scrapcode »

GordyMD wrote: post #32
arno_v wrote: post #29

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.

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,…

I've got a problem. I've been coding for 12 years, yet have zero professional experience. How does your service rank me?

Re: The Problem with Job Titles

#44

Post by TheOtherHobbes »

GordyMD wrote: post #32
arno_v wrote: post #29

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.

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,…

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.

Re: The Problem with Job Titles

#45

Post by GordyMD »

scrapcode wrote: post #43
GordyMD wrote: post #32

Earlier quoted context omitted.

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,…

I've got a problem. I've been coding for 12 years, yet have zero professional experience. How does your service rank me?

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.

Re: The Problem with Job Titles

#46

Post by hunglee2 »

ukigumo wrote: post #40

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…

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

Re: The Problem with Job Titles

#47

Post by GordyMD »

jamesdelaneyie wrote: post #35

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! [0] http://codepen.io/jamesdelaneyie/pen/uIdie

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.

Re: The Problem with Job Titles

#48

Post by lmm »

onion2k wrote: post #23
dkyc wrote: post #2

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…

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 bori…

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.

Re: The Problem with Job Titles

#49

Post by jghn »

genericuser wrote: post #41
arno_v wrote: post #29

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).

Re: The Problem with Job Titles

#50

Post by jghn »

GordyMD wrote: post #32
arno_v wrote: post #29

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.

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,…

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

Post reply on HN