7 ms·

If I use Docker, I get to put "Docker" on my resume for the next job; if I use bash scripts I don't. If I use React, I get to put "React" on my resume; if I use

If I use Docker, I get to put "Docker" on my resume for the next job; if I use bash scripts I don't. If I use React, I get to put "React" on my resume; if I use vanilla JS I don't. If I use Kubernetes, I get to put "Kubernetes" on my resume. If I use AWS, I get to put that on my resume, if I just spin up a Linux instance using Linode or etc, I don't Of course, I would have to convince my boss to let me do all of these. But, he also wants to be able to put on his resume that he managed developers who used these things, so that's an easy task. Many of these made perfect sense for the FAANG company they were developed for, but they are used at companies with 0.01% of the number of servers of those companies, and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there. Again, there are valid use cases for all of these, but there are also valid use cases for semi tractor trailers. It doesn't mean I should use one to get my groceries.

k__ 7y ago
The problem is, as so often, the system. If HR goes as low-level in hiring as "React Developer" then people have to play this game. If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.
- pc86 7y ago
  HR having any role more substantial than confirming that an applicant can legally work in the US and isn't lying on their resume is the problem.
  - rossdavidh 7y ago
    In other words, only the parts that they are trained and qualified to do, yes. The parts that a developer team lead or team manager would not be good at. Makes sense.
- mywittyname 7y ago
  Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope. If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.
  - magduf 7y ago
    The solution seems pretty simple to me: get rid of the HR and recruiters, at least as having much power in deciding who to interview. That's the hiring manager's job. He knows what kind of person he's looking for, so let him make decisions. Why would you let some non-technical person decide who's qualified to be interviews? It makes no sense. At best, have the hiring manager give some very basic things to look for on resumes to the HR person, so they can screen out the people who are obvious wastes of time. >If we could find a better way, we'd be using it. It seems to me that the reason it's so bad is because, at many companies, HR people refuse to admit that they're incompetent at hiring technical people, and insist on inserting themselves into the process to a degree which is highly counterproductive. The only thing HR should be doing is helping hiring managers find the people they need, and otherwise staying out of the way. The bulk of the HR person's time should be on other tasks: personnel issues with existing employees, helping new employees get situated, maybe interpersonal issues, etc. The hiring manager can afford to spend an hour a day looking through resumes and giving good ones back to HR to recruit.
    - loopz 7y ago
      This is assuming technical hiring manager, which may often not be so. Also, a team often wants new hires with all the latest buzzword experience as they are too swamped themselves.
    - 7y ago
shadowgovt 7y ago
It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé. If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts). React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.
- busterarm 7y ago
  Do you actually think Kubernetes infrastructure is built without hair-pulling and rage? If so, I've got some stories for you.
  - nickthemagicman 7y ago
    Well it's contained the hair-pulling and rage to just the kubernetes administrators instead of the whole organization. :P
    - falcolas 7y ago
      No, the rage extends to the developers too. Writing all of the yaml for a full service requires a fair bit of understanding of what's going on in k8s. And helm templating.
  - shadowgovt 7y ago
    It's hair-pulling and rage that results in forward progress on a fungible toolchain (as opposed to hair-pulling and rage that results in a bespoke one-company ecosystem where you leave behind more than half the useful experience you gained when you transfer to a company based upon ecosystem fundamentals utterly different from the ones bought with the blood, sweat, and tears of solving the problem at the first place).
nick_ 7y ago
https://rdd.io/ https://rdd.io/
deleted 7y ago
[deleted]
djohnston 7y ago
> and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there. Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.
raghava 7y ago
>> resume building Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times. But why does it happen? May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased! If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume. Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes). Also, an old classic on these lines - http://www.bruceblinn.com/parable.html http://www.bruceblinn.com/parable.html - The parable of two programmers. "I don't want to seem like a hack, so I'll do enterprisey things, so that nobody can call me a dumb guy" is another thing running in the background.
vonseel 7y ago
I’m actually looking for a job and this has come up more than once. I agree with you for the most part. Docker isn’t all that difficult to use and I don’t even see why they bother asking. I just laugh and tell them, yeah, I know docker, along with being quite proficient in Linux in general and other deployment technologies. I don’t see the point of asking developers if they know docker. If you can learn to code, you can learn the basics of docker in 15 minutes. React and frameworks are more specific and I can see why asking about those for developer roles is more appropriate. AWS is so damn big at this point that I don’t know what they are really asking by just saying “AWS”. Sure, I know about the core AWS stuff, but I’m not proficient in really specific AWS CloudFormation templates or AWS IAM policies and stuff. And I’m not sure most developers outside of devops should be responsible for such a thing. For day-to-day software engineering, I shouldn’t need to touch the servers - that should be handled by a CI process and/or devops persons.

k__ 7y ago

The problem is, as so often, the system. If HR goes as low-level in hiring as "React Developer" then people have to play this game. If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.

pc86 7y ago
HR having any role more substantial than confirming that an applicant can legally work in the US and isn't lying on their resume is the problem.
- rossdavidh 7y ago
  In other words, only the parts that they are trained and qualified to do, yes. The parts that a developer team lead or team manager would not be good at. Makes sense.
mywittyname 7y ago
Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope. If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.
- magduf 7y ago
  The solution seems pretty simple to me: get rid of the HR and recruiters, at least as having much power in deciding who to interview. That's the hiring manager's job. He knows what kind of person he's looking for, so let him make decisions. Why would you let some non-technical person decide who's qualified to be interviews? It makes no sense. At best, have the hiring manager give some very basic things to look for on resumes to the HR person, so they can screen out the people who are obvious wastes of time. >If we could find a better way, we'd be using it. It seems to me that the reason it's so bad is because, at many companies, HR people refuse to admit that they're incompetent at hiring technical people, and insist on inserting themselves into the process to a degree which is highly counterproductive. The only thing HR should be doing is helping hiring managers find the people they need, and otherwise staying out of the way. The bulk of the HR person's time should be on other tasks: personnel issues with existing employees, helping new employees get situated, maybe interpersonal issues, etc. The hiring manager can afford to spend an hour a day looking through resumes and giving good ones back to HR to recruit.
  - loopz 7y ago
    This is assuming technical hiring manager, which may often not be so. Also, a team often wants new hires with all the latest buzzword experience as they are too swamped themselves.
  - 7y ago

shadowgovt 7y ago

It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé. If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts). React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.

busterarm 7y ago
Do you actually think Kubernetes infrastructure is built without hair-pulling and rage? If so, I've got some stories for you.
- nickthemagicman 7y ago
  Well it's contained the hair-pulling and rage to just the kubernetes administrators instead of the whole organization. :P
  - falcolas 7y ago
    No, the rage extends to the developers too. Writing all of the yaml for a full service requires a fair bit of understanding of what's going on in k8s. And helm templating.
- shadowgovt 7y ago
  It's hair-pulling and rage that results in forward progress on a fungible toolchain (as opposed to hair-pulling and rage that results in a bespoke one-company ecosystem where you leave behind more than half the useful experience you gained when you transfer to a company based upon ecosystem fundamentals utterly different from the ones bought with the blood, sweat, and tears of solving the problem at the first place).

nick_ 7y ago

https://rdd.io/ https://rdd.io/

deleted 7y ago

[deleted]

djohnston 7y ago

> and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there. Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.

raghava 7y ago

>> resume building Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times. But why does it happen? May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased! If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume. Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes). Also, an old classic on these lines - http://www.bruceblinn.com/parable.html http://www.bruceblinn.com/parable.html - The parable of two programmers. "I don't want to seem like a hack, so I'll do enterprisey things, so that nobody can call me a dumb guy" is another thing running in the background.

vonseel 7y ago

I’m actually looking for a job and this has come up more than once. I agree with you for the most part. Docker isn’t all that difficult to use and I don’t even see why they bother asking. I just laugh and tell them, yeah, I know docker, along with being quite proficient in Linux in general and other deployment technologies. I don’t see the point of asking developers if they know docker. If you can learn to code, you can learn the basics of docker in 15 minutes. React and frameworks are more specific and I can see why asking about those for developer roles is more appropriate. AWS is so damn big at this point that I don’t know what they are really asking by just saying “AWS”. Sure, I know about the core AWS stuff, but I’m not proficient in really specific AWS CloudFormation templates or AWS IAM policies and stuff. And I’m not sure most developers outside of devops should be responsible for such a thing. For day-to-day software engineering, I shouldn’t need to touch the servers - that should be handled by a CI process and/or devops persons.