Live data from Hacker News

The Problem with Job Titles

blog.workshape.io

91–100 of 103 posts

Re: The Problem with Job Titles

#91
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.

Re: The Problem with Job Titles

#92

Fascinating approach to the matching. "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.

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

Re: The Problem with Job Titles

#93
post #87
post #84

Earlier quoted context omitted.

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

An interesting idea - thanks! 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

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

Re: The Problem with Job Titles

#94
post #89
post #81

Yes, job titles an CVs/resumes are out of date. People talk about the future of work but for a lot of us it's already here. This is great, although I have a different approach, namely https://www.somewhere.com and specifically https://www.somewhere.com/what-is-somewhere

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

Yes, absolutely.

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.

Re: The Problem with Job Titles

#95
post #82

Earlier quoted context omitted.

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…

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

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.

Re: The Problem with Job Titles

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

Re: The Problem with Job Titles

#98
post #55

Earlier quoted context omitted.

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. Dependi…

> "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 maj…

In Canada it's not uncommon to see the seniority of Director and VP reversed (Director being the more senior)

Re: The Problem with Job Titles

#99
post #93
post #87

Earlier quoted context omitted.

An interesting idea - thanks! 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

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.

Thanks for the comment.

Re: The Problem with Job Titles

#100
post #58

Earlier quoted context omitted.

> Exactly. I have a lot of acquaintances who self-describe as data scientists. My understanding is that "data scientist" is a term meaning "statistics person who lives in San Francisco"

Alternatively, "Does statistics, but on a Macbook"

I know you're joking, but Wizard (http://www.wizardmac.com/) for OS X is a really nice place to start before delving into SPSS, Stata, and R.
Post reply on HN