The Problem with Job Titles
91–100 of 103 posts
Re: The Problem with Job Titles
#92Fascinating 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.
Re: The Problem with Job Titles
#93Earlier 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
Re: The Problem with Job Titles
#94Yes, 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…
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
#95Earlier 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…
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
#96Re: The Problem with Job Titles
#97http://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.
Re: The Problem with Job Titles
#98Earlier 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…
Re: The Problem with Job Titles
#99Earlier 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
Thanks for the comment.
Re: The Problem with Job Titles
#100Earlier 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"