14 ms·

> I can come up with a reasonably convincing story for every individual Job about why I quit that one. But taken together, there's no reasonable story that woul

> I can come up with a reasonably convincing story for every individual Job about why I quit that one. But taken together, there's no reasonable story that would convince a hiring manager. > It comes down to this: I hate being an employee. If the bottom line is that you hate being an employee, then it seems that being suspicious of your resume would be the correct call. > I want to work on my own projects on my own terms. This is the only way I can find work that is worth doing. This is something hiring managers try to screen for during the hiring process. Being part of a team and working together on the teams' terms is crucial. There isn't room for a "lone wolf" kind of programmer in most companies. This personality might work at small companies that can only afford to hire a single programmer who owns an entire domain from start to finish, but those jobs come with their own issues.

ditonal 4y ago
I'm trying to figure out which part of the post you're replying to suggests that they're looking to work for you but I can't find it. Yet your response presumes it and comes off as presumptuous. Candidates are wise to screen out hiring managers like that. They generally don't run teams worth working for, and if you're not smart enough to filter out managers like that, you might end up with too many short tenures.
- PragmaticPulp 4y ago
  > I'm trying to figure out which part of the post you're replying to suggests that they're looking to work for you but I can't find it. Yet your response presumes it and comes off as presumptuous. I wasn't trying to suggest the parent commenter was trying to work for me (nor would that even make logical sense, given that I'm replying to them...) The comment was a general observation on the hiring process, short tenures, and how hiring managers operate. I meant it in the general context of the article we're all commenting on. The bottom line is that hiring managers are looking for good employees. If someone outwardly identifies as a person who "hates being an employee" then it would seem the system is working if they're struggling to convince hiring managers otherwise.
  - avmich 4y ago
    > The bottom line is that hiring managers are looking for good employees. I think this looks closest to the problem of misunderstanding. Hiring managers should look for people who solve their problems, not for good employees (in the sense of this discussion). Hating being an employee should be understood correctly.
    - bruce511 4y ago
      The thing is, someone who's going to move on in say a year is going to cause more problems than they solve. Firstly it means the hiring manager has to redo this whole process again. So if nothing else a problem for him. Secondly everything the person worked on will have to be moved to someone else - an expensive cost of time. Thirdly there's typically a reason for them leaving, and they often pollute the workspace with that discontent on their way out. As an employer it's not hard to find people with sufficient skills. Despite what programmers think it's not tech chops that are unique. Being a "good employee" for lots of definitions of "good" is exactly what I'm looking for.
      - grogers 4y ago
        Honestly I think most managers would rather lose someone with 1 year tenure than 5 years. One year is plenty of time to make many meaningful contributions, especially if the employee is already experienced. You might not get the super deep knowledge to drive roadmaps and cross team projects. But it's definitely not going to be a net negative unless the employee is just bad (so not likely to make it to a year). Don't compare the right person staying only one year to the right person staying 3 years. Compre them to no hire, or to the wrong person being hired. Getting amazing people who want to stay with you forever is really rare.
    - Espressosaurus 4y ago
      For my domain and in my experience (deeply embedded firmware on custom mixed signal ASICs) ramp up time is around 6 months to break even, a year to be modestly productive, and 2 years to be actually productive (because you understand enough of the domain to contribute at a cross-functional, system level). Hiring managers need to look for good employees as well as people who solve their problems, and whoever joins the team is going to need months of training to be productive. Someone who jumps ship after a year is...not entirely useless, but was certainly a waste. Perhaps it's different in other domains.
hsn915 4y ago
Just because I don't like to work on your product does not mean I don't like working in a team. Although for people like you, I think "team player" means "a guy who does what I tell him to do".
- lhorie 4y ago
  It seems like a pretty common trope for short tenure advocates to talk in terms of me-vs-them. In reality, the world is vast, companies and work arrangements vary a lot and and even if you're shortlisted as having "red flags" by some, others will still take you in. At least when I see candidates worried about how short stints will look on their resume, this much context suffices to be said. Where it gets weird is when you see people on r/cscareerquestions or whatever advocating for a series of short tenure stints as a "hack" to get into high pay positions quickly. The problem is that anyone that has success with this strategy is a living example of survivorship bias, and the seemingly "easy-ness" of the strategy gets a lot of mind space among young highly impressionable audiences, when in reality, if you want to be career-growth focused, you typically do need at least some long tenure stints to gain experience w/ longer term responsibilities and relationships. I.e. you don't see director-level people advocating for quick job hopping for a reason.
  - PragmaticPulp 4y ago
    > Where it gets weird is when you see people on r/cscareerquestions or whatever advocating for a series of short tenure stints as a "hack" to get into high pay positions quickly. The problem is that anyone that has success with this strategy is a living example of survivorship bias I also check /r/cscareerquestions from time to time. It has a strong "blind leading the blind" vibe lately, wherein inexperienced people are just echoing things back and forth to each other. A lot of the advice tends to be what people want to hear, not what actually mirrors reality. The hiring boom over the past few years has also severely skewed the results. A lot of the junior devs who recently entered the industry know nothing other than the crazy hiring boom times of 2020 to early 2022. They preach about how easy it is to find a job, but their only real data point was a single job search experience during a very anomalous time.
  - 4y ago
deleted 4y ago
[deleted]
izelnakri 4y ago
I think these should actually be written in the job ads because I wouldn’t want to work for a colleague who has your mentality. I worked with many bunch of sit-on-your-chair claim your paycheck at the end of the month types, another colleague another competition types, and this one is the most complex: overly-invested/$feelingLikeOwnerYetOwnNoShares types but yet I have no way to screen them during the interview process and a single mention in the job ad description could help me save some time: Companies should immediately tell if they would reject job-hoppers, or particularly screen for loyalist in tech(ones with delusion given commercial activity in IT), that is a company I can respect!
- PragmaticPulp 4y ago
  > Companies should immediately tell if they would reject job-hoppers Job-hopping isn't some arbitrary threshold that gets crossed. It's more of a pattern that gets identified while evaluating a person's resume. When I say "job hopper" I don't mean someone who has 10 years of experience across 3 or 4 different jobs. The "job hopper" resumes I see are some times as extreme as 12 jobs in 10 years, or occasionally people who have never reached the 1 year mark at any company. If someone can't last a full year as an FTE at any company, it's hard to argue that there isn't a problem. It's not a big deal for someone who is 1-2 years into their career. But when someone is 10 years into their career and they're not staying anywhere long enough to really make an impact, why would any hiring manager reasonably expect that to be different after hiring them again for job number 11 or whatever it ends up being? The most likely outcome is that the pattern continues.
  - izelnakri 4y ago
    Never reaching a year at 10 jobs is something to ask I think however: > why would any hiring manager reasonably expect that to be different after hiring them again for job 11 Thats is I think still the wrong approach, signals the wrong mentality in an IT company(a company thats greatest asset is its employees). Investing in employees can never be a saving center in a good IT business, considering all businesses are becoming IT businesses perhaps in every business in this context. If a candidate has the skills and took time to apply, if they are qualified you are responsible to hire them and keep them. If I was the manager of the hiring manager, I’d probably fire this hiring manager for keeping the organization dumber, and seeks his own interest/status-quo seeking behavior & protectionism with this behavior/approach/mentality. I do believe in moving mountains in 3-6 months, especially in badly managed projects or super fast growing companies.
Jach 4y ago
I think most companies are pretty amenable (that is, a lot seem to fall into the trap) of having an employee who becomes rather irreplaceable. Maybe it's the guy who makes himself responsible for the build infrastructure for the rest of the thousands of engineers, or maybe it's the guy who hacked up hundreds of thousands of lines of code years ago when the company was still smallish and which still mostly work but is now mostly on architecture (days filled with meetings with varied teams) unless something tricky is wrong and you're really glad he can still code and debug his legacy mess. It is harder at larger companies, especially because those will tend to have a higher density of managers who actively look for bus-factor-1 problems to try and ameliorate, but still. I think it's funny how at the large companies there's an inversion to your "lone wolf" claim somewhere in the promotion pipeline where to get to the next level you're supposed to show leadership and ownership of some core feature domains, you'll be working on basically one bigger thing for months at a time. Sure, technically the "team" owns it, and a few other members may have implemented some of the simpler pieces, or done QE work on it, and you probably had to have meetings with other teams about aspects of it, but everyone knows whose baby it really is and who is best positioned to add new code or debug existing code. When your team is pretty stable for enough years (quite a nice experience) everyone on the team has at least one baby + eventually passable familiarity with everyone else's; not without good reason, it's a pretty powerful way of organizing devs who don't need constant hand holding. It's not as lone wolf as literally working by yourself on your own company, but it's not like you're drowning in collaboration. As people inevitably drop out, there's often an attempt to transfer knowledge formally, because of course there are things that the person leaving knows about their special areas that are not well understood by the rest of the team or company. Companies and teams where there really is a sense of full shared ownership and common almost equal understanding of things are pretty rare, and I would bet tend to be on the smaller side.
- BlargMcLarg 4y ago
  There is absolutely a perverse obsession with the opposite and the narrative of "lone wolves/mercenaries are bad" needs to die already. I've never seen a company that hasn't had severe problems getting someone else in the domain of a person who left. The problem isn't an asocial person in an important position. It is lack of documentation or at least a paper trail. Various reasons why this could be, but I find the people overly eager to communicate to be the worst offenders of this, not the asocial ones. Personality doesn't magically solve strategy and lack of litmus tests. And funnily enough, these problems form in domains that are considered solved, too. Everyone writes their own half-attempt without looking at what big corps are already doing. The domain itself is never the difficult part.
mxkopy 4y ago
> If the bottom line is that you hate being an employee, then it seems that being suspicious of your resume would be the correct call. The other day I was reading a post about what specialized tooling, if any, ADHD devs used. Someone replied that they had to accept the fact that they could only work contracts because they could work on them on their own schedule. There are plenty of reasons to hate being an employee. But someone who hates being an employee can nevertheless be a better employee than someone who doesn't. The conception of culture in the workplace needs to die; taken to the desert and shot. You go to work to get paid. You get paid because you do work. Whether or not you hate it or love it shouldn't matter as long as those conditions are met to the satisfaction of both parties.
- BlargMcLarg 4y ago
  The reality of the matter is this: almost all demands are flexible depending on the market. Today's 'red flag' is tomorrow's 'not the worst'. Almost none of the red flags have an academic or scientific basis. Almost all of it is rationality with a thousand caveats.
- tstrimple 4y ago
  > The conception of culture in the workplace needs to die Work culture exists whether you want to believe in it or not. If you don't, then you're letting the culture be dictated Lord of the Flies style. I've worked across a lot of domains and a lot of very large companies during my time working in technology and the most obvious differentiator between successful IT/dev orgs and unsuccessful ones is most often attributed to the work / dev culture. This is especially true when trying to change / influence organizations. The number one thing you have to overcome is culture. Why doesn't agile work? Why doesn't DevOps deliver like promised? Why can't the org successfully shift from a project based delivery to a product based delivery method? More often than not it's due to trying to implement changes without addressing team culture issues. Technology is mostly easy if you can get cross organizational alignment, but you can't do that without addressing culture.
  - mxkopy 4y ago
    Sure, if there's an issue that's actively harmful or prevents stuff getting done, it would make no sense to let it go unaddressed. But having managers trying to optimize culture leads to open plan desks and mandatory office parties - shit that might improve the cohesion of the team, sure, but if your 10x left because they don't like it, then it's not entirely focused on productivity. > If you don't, then you're letting the culture be dictated Lord of the Flies style. Moreover this is implying that you think of your team as a bunch of children stuck on an island. I'd have more faith in professional adults to do their job. Hopefully, nobody is under the illusion that money comes out of the office printer. Honestly, I'd want to hire someone who hates being an employee more than someone who doesn't. Then, I'd at least know that they're under no illusions, and smart enough to know that they'll have to work.
danwee 4y ago
Nah, it's not incompatible. I do as well want to work on my own projects on my own terms and I couldn't care less about my employers' product. At the same time I know how to play well as part of a team and get paid for it. It's just two different hats I wear at different times of the day (e.g., 9-5 hat is "team player, let's be nice", 5-8 hat is "let's do something that actually makes sense not like that stupid project at work")

ditonal 4y ago

I'm trying to figure out which part of the post you're replying to suggests that they're looking to work for you but I can't find it. Yet your response presumes it and comes off as presumptuous. Candidates are wise to screen out hiring managers like that. They generally don't run teams worth working for, and if you're not smart enough to filter out managers like that, you might end up with too many short tenures.

PragmaticPulp 4y ago
> I'm trying to figure out which part of the post you're replying to suggests that they're looking to work for you but I can't find it. Yet your response presumes it and comes off as presumptuous. I wasn't trying to suggest the parent commenter was trying to work for me (nor would that even make logical sense, given that I'm replying to them...) The comment was a general observation on the hiring process, short tenures, and how hiring managers operate. I meant it in the general context of the article we're all commenting on. The bottom line is that hiring managers are looking for good employees. If someone outwardly identifies as a person who "hates being an employee" then it would seem the system is working if they're struggling to convince hiring managers otherwise.
- avmich 4y ago
  > The bottom line is that hiring managers are looking for good employees. I think this looks closest to the problem of misunderstanding. Hiring managers should look for people who solve their problems, not for good employees (in the sense of this discussion). Hating being an employee should be understood correctly.
  - bruce511 4y ago
    The thing is, someone who's going to move on in say a year is going to cause more problems than they solve. Firstly it means the hiring manager has to redo this whole process again. So if nothing else a problem for him. Secondly everything the person worked on will have to be moved to someone else - an expensive cost of time. Thirdly there's typically a reason for them leaving, and they often pollute the workspace with that discontent on their way out. As an employer it's not hard to find people with sufficient skills. Despite what programmers think it's not tech chops that are unique. Being a "good employee" for lots of definitions of "good" is exactly what I'm looking for.
    - grogers 4y ago
      Honestly I think most managers would rather lose someone with 1 year tenure than 5 years. One year is plenty of time to make many meaningful contributions, especially if the employee is already experienced. You might not get the super deep knowledge to drive roadmaps and cross team projects. But it's definitely not going to be a net negative unless the employee is just bad (so not likely to make it to a year). Don't compare the right person staying only one year to the right person staying 3 years. Compre them to no hire, or to the wrong person being hired. Getting amazing people who want to stay with you forever is really rare.
  - Espressosaurus 4y ago
    For my domain and in my experience (deeply embedded firmware on custom mixed signal ASICs) ramp up time is around 6 months to break even, a year to be modestly productive, and 2 years to be actually productive (because you understand enough of the domain to contribute at a cross-functional, system level). Hiring managers need to look for good employees as well as people who solve their problems, and whoever joins the team is going to need months of training to be productive. Someone who jumps ship after a year is...not entirely useless, but was certainly a waste. Perhaps it's different in other domains.

hsn915 4y ago

Just because I don't like to work on your product does not mean I don't like working in a team. Although for people like you, I think "team player" means "a guy who does what I tell him to do".

lhorie 4y ago
It seems like a pretty common trope for short tenure advocates to talk in terms of me-vs-them. In reality, the world is vast, companies and work arrangements vary a lot and and even if you're shortlisted as having "red flags" by some, others will still take you in. At least when I see candidates worried about how short stints will look on their resume, this much context suffices to be said. Where it gets weird is when you see people on r/cscareerquestions or whatever advocating for a series of short tenure stints as a "hack" to get into high pay positions quickly. The problem is that anyone that has success with this strategy is a living example of survivorship bias, and the seemingly "easy-ness" of the strategy gets a lot of mind space among young highly impressionable audiences, when in reality, if you want to be career-growth focused, you typically do need at least some long tenure stints to gain experience w/ longer term responsibilities and relationships. I.e. you don't see director-level people advocating for quick job hopping for a reason.
- PragmaticPulp 4y ago
  > Where it gets weird is when you see people on r/cscareerquestions or whatever advocating for a series of short tenure stints as a "hack" to get into high pay positions quickly. The problem is that anyone that has success with this strategy is a living example of survivorship bias I also check /r/cscareerquestions from time to time. It has a strong "blind leading the blind" vibe lately, wherein inexperienced people are just echoing things back and forth to each other. A lot of the advice tends to be what people want to hear, not what actually mirrors reality. The hiring boom over the past few years has also severely skewed the results. A lot of the junior devs who recently entered the industry know nothing other than the crazy hiring boom times of 2020 to early 2022. They preach about how easy it is to find a job, but their only real data point was a single job search experience during a very anomalous time.
- 4y ago

deleted 4y ago

[deleted]

izelnakri 4y ago

I think these should actually be written in the job ads because I wouldn’t want to work for a colleague who has your mentality. I worked with many bunch of sit-on-your-chair claim your paycheck at the end of the month types, another colleague another competition types, and this one is the most complex: overly-invested/$feelingLikeOwnerYetOwnNoShares types but yet I have no way to screen them during the interview process and a single mention in the job ad description could help me save some time: Companies should immediately tell if they would reject job-hoppers, or particularly screen for loyalist in tech(ones with delusion given commercial activity in IT), that is a company I can respect!

PragmaticPulp 4y ago
> Companies should immediately tell if they would reject job-hoppers Job-hopping isn't some arbitrary threshold that gets crossed. It's more of a pattern that gets identified while evaluating a person's resume. When I say "job hopper" I don't mean someone who has 10 years of experience across 3 or 4 different jobs. The "job hopper" resumes I see are some times as extreme as 12 jobs in 10 years, or occasionally people who have never reached the 1 year mark at any company. If someone can't last a full year as an FTE at any company, it's hard to argue that there isn't a problem. It's not a big deal for someone who is 1-2 years into their career. But when someone is 10 years into their career and they're not staying anywhere long enough to really make an impact, why would any hiring manager reasonably expect that to be different after hiring them again for job number 11 or whatever it ends up being? The most likely outcome is that the pattern continues.
- izelnakri 4y ago
  Never reaching a year at 10 jobs is something to ask I think however: > why would any hiring manager reasonably expect that to be different after hiring them again for job 11 Thats is I think still the wrong approach, signals the wrong mentality in an IT company(a company thats greatest asset is its employees). Investing in employees can never be a saving center in a good IT business, considering all businesses are becoming IT businesses perhaps in every business in this context. If a candidate has the skills and took time to apply, if they are qualified you are responsible to hire them and keep them. If I was the manager of the hiring manager, I’d probably fire this hiring manager for keeping the organization dumber, and seeks his own interest/status-quo seeking behavior & protectionism with this behavior/approach/mentality. I do believe in moving mountains in 3-6 months, especially in badly managed projects or super fast growing companies.

Jach 4y ago

I think most companies are pretty amenable (that is, a lot seem to fall into the trap) of having an employee who becomes rather irreplaceable. Maybe it's the guy who makes himself responsible for the build infrastructure for the rest of the thousands of engineers, or maybe it's the guy who hacked up hundreds of thousands of lines of code years ago when the company was still smallish and which still mostly work but is now mostly on architecture (days filled with meetings with varied teams) unless something tricky is wrong and you're really glad he can still code and debug his legacy mess. It is harder at larger companies, especially because those will tend to have a higher density of managers who actively look for bus-factor-1 problems to try and ameliorate, but still. I think it's funny how at the large companies there's an inversion to your "lone wolf" claim somewhere in the promotion pipeline where to get to the next level you're supposed to show leadership and ownership of some core feature domains, you'll be working on basically one bigger thing for months at a time. Sure, technically the "team" owns it, and a few other members may have implemented some of the simpler pieces, or done QE work on it, and you probably had to have meetings with other teams about aspects of it, but everyone knows whose baby it really is and who is best positioned to add new code or debug existing code. When your team is pretty stable for enough years (quite a nice experience) everyone on the team has at least one baby + eventually passable familiarity with everyone else's; not without good reason, it's a pretty powerful way of organizing devs who don't need constant hand holding. It's not as lone wolf as literally working by yourself on your own company, but it's not like you're drowning in collaboration. As people inevitably drop out, there's often an attempt to transfer knowledge formally, because of course there are things that the person leaving knows about their special areas that are not well understood by the rest of the team or company. Companies and teams where there really is a sense of full shared ownership and common almost equal understanding of things are pretty rare, and I would bet tend to be on the smaller side.

BlargMcLarg 4y ago
There is absolutely a perverse obsession with the opposite and the narrative of "lone wolves/mercenaries are bad" needs to die already. I've never seen a company that hasn't had severe problems getting someone else in the domain of a person who left. The problem isn't an asocial person in an important position. It is lack of documentation or at least a paper trail. Various reasons why this could be, but I find the people overly eager to communicate to be the worst offenders of this, not the asocial ones. Personality doesn't magically solve strategy and lack of litmus tests. And funnily enough, these problems form in domains that are considered solved, too. Everyone writes their own half-attempt without looking at what big corps are already doing. The domain itself is never the difficult part.

mxkopy 4y ago

> If the bottom line is that you hate being an employee, then it seems that being suspicious of your resume would be the correct call. The other day I was reading a post about what specialized tooling, if any, ADHD devs used. Someone replied that they had to accept the fact that they could only work contracts because they could work on them on their own schedule. There are plenty of reasons to hate being an employee. But someone who hates being an employee can nevertheless be a better employee than someone who doesn't. The conception of culture in the workplace needs to die; taken to the desert and shot. You go to work to get paid. You get paid because you do work. Whether or not you hate it or love it shouldn't matter as long as those conditions are met to the satisfaction of both parties.

BlargMcLarg 4y ago
The reality of the matter is this: almost all demands are flexible depending on the market. Today's 'red flag' is tomorrow's 'not the worst'. Almost none of the red flags have an academic or scientific basis. Almost all of it is rationality with a thousand caveats.
tstrimple 4y ago
> The conception of culture in the workplace needs to die Work culture exists whether you want to believe in it or not. If you don't, then you're letting the culture be dictated Lord of the Flies style. I've worked across a lot of domains and a lot of very large companies during my time working in technology and the most obvious differentiator between successful IT/dev orgs and unsuccessful ones is most often attributed to the work / dev culture. This is especially true when trying to change / influence organizations. The number one thing you have to overcome is culture. Why doesn't agile work? Why doesn't DevOps deliver like promised? Why can't the org successfully shift from a project based delivery to a product based delivery method? More often than not it's due to trying to implement changes without addressing team culture issues. Technology is mostly easy if you can get cross organizational alignment, but you can't do that without addressing culture.
- mxkopy 4y ago
  Sure, if there's an issue that's actively harmful or prevents stuff getting done, it would make no sense to let it go unaddressed. But having managers trying to optimize culture leads to open plan desks and mandatory office parties - shit that might improve the cohesion of the team, sure, but if your 10x left because they don't like it, then it's not entirely focused on productivity. > If you don't, then you're letting the culture be dictated Lord of the Flies style. Moreover this is implying that you think of your team as a bunch of children stuck on an island. I'd have more faith in professional adults to do their job. Hopefully, nobody is under the illusion that money comes out of the office printer. Honestly, I'd want to hire someone who hates being an employee more than someone who doesn't. Then, I'd at least know that they're under no illusions, and smart enough to know that they'll have to work.

danwee 4y ago

Nah, it's not incompatible. I do as well want to work on my own projects on my own terms and I couldn't care less about my employers' product. At the same time I know how to play well as part of a team and get paid for it. It's just two different hats I wear at different times of the day (e.g., 9-5 hat is "team player, let's be nice", 5-8 hat is "let's do something that actually makes sense not like that stupid project at work")