That's why we call ourselves back-end/front-end/ui/embedded (software) engineers.
[deleted]
The Problem with Job Titles
61–70 of 103 posts
Re: The Problem with Job Titles
#62That's why we call ourselves back-end/front-end/ui/embedded (software) engineers.
One problem I have w/ the back-end/front-end distinction is that at least to me that implies one is working on a web or mobile application.
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"?
Re: The Problem with Job Titles
#63Earlier 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…
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"…
Yeah, I will agree that below manager level titles are pretty meaningless in general.
Re: The Problem with Job Titles
#64Earlier quoted context omitted.
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 do…
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.
Re: The Problem with Job Titles
#65Earlier quoted context omitted.
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 - particul…
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 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."
Re: The Problem with Job Titles
#66Earlier quoted context omitted.
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 scr…
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…
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.
Re: The Problem with Job Titles
#67Oh 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.
Glad to hear it! Best of luck lads :)
Re: The Problem with Job Titles
#68That's why we call ourselves back-end/front-end/ui/embedded (software) engineers.
One problem I have w/ the back-end/front-end distinction is that at least to me that implies one is working on a web or mobile application. 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"?
Your front-end is your 2 page report. It's not about size but separation of concerns, nothing to do specifically with web apps.
Re: The Problem with Job Titles
#69Earlier quoted context omitted.
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).
> 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"
Re: The Problem with Job Titles
#70Earlier quoted context omitted.
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 tes…
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.