As a hiring manager, I can say that we don't want to hire the mythical 'rock stars', the kind of know-it-alls that do-it-all. We want people who will be great team players and help build a collaborative culture. Not that 'rock stars' cannot be team players, but there is certainly that risk.
You don't have to act dumb (and you shouldn't). You just have to not act like a "rock star". The most brilliant devs I've ever met were people nobody would call "rock stars". They were collaborative team players.
This, exactly this. I know so many people who are "above average" developers that I would love to work with because they are nice, collaborative people that are a joy to work with. The biggest problems we've faced are with these so called "10x developers", who do get stuff done, but are a total pain in the a* to deal with!
A developer that knows how to treat other people in the team, knows how to be professional, works on what they agreed to during sprint planning, doesn't want to rewrite the project to a new technology and doesn't want to create their own cool project because they know the ultimate goal is to ship to users, doesn't react badly to criticism, is not unreasonably stubborn, has good hygiene, doesn't take code reviews personally and agrees that management has a necessarily different point of view from pure developers.
A brilliant dev is one who consistently produces solid and feasible solutions to difficult problems, in a timely way.
A more enlightening question is "what is a rock star" in my mind. A rock star is a dev who truly believes that they are the smartest person in the room, who looks down their nose at any work they didn't produce, who is only really interested in things that they think make themselves look better rather than things that will actually help produce the best end product possible, who insists on using the whatever latest shiny thing is in fashion over less shiny but more appropriate approaches, and so forth.
The Rock Star will say, “I will do these 10 things by next Friday.” And then next Friday rolls around and 8 of them are done. This repeats week after week, but I can never tell which 8 will get done. They’re boastful and proud that they got a lot done but the rest of the team can never count on them to get any specific thing done.
The other person will say “I will do these 5 things by next Friday.” And then next Friday all 5 are done. And they repeat this week after week after week.
I agree with your scenario, but I wouldn't consider someone who consistently under-delivers a "rock star."
This is why defining terms is important. For me, a rockstar is a developer who is just further along, who likes to program in their own time, who reads Hacker News, and builds projects on the weekends.
Within 5 years, that person will be much further ahead than the rest and will spot pitfalls, security, and performance issues simply because they have encountered them before. However, sharing that information could lead to that person being called a "rockstar" and problematic, hampering "progress".
There is a difference between acting dumb and being a know-it-all.
Someone recently left my team who was a rock star in his own mind. He claimed to know it all, and would go on and on about how everyone else should do their job. The reality was that he didn’t understand the complicities of the issues, any time a team was involved he would try to delegate everything away, anytime there was an issue he was the first to finger point, any time something was difficult he would quit while making excuses that it was not his fault, he only knew one language/framework and saw no reason why anything else would ever be needed/wanted… I could go on.
I’m sure he might sound great in an interview, as he loved to talk himself up and talk about how amazing he was and how stupid everyone else is. In the real world, he was a toxin within our team and no one was sad when he left.
I’m not sure how one would separate a true “rock star” from a delusional wannabe in an interview, other than having a well tuned BS meter.
There is a big difference between acting as if you know something and actually knowing it. You're describing one thing, while the comment you are replying to is describing something else.
Let's consider a developer who is interested in programming and has a lot of experience. If the team is going down a path that the developer knows will lead to issues, or if the developer tries to help because the team is not as strict and it's leading to outages, that developer may be perceived negatively.
However, the developer is able to find security issues and potential bugs during code review, objectively providing significant value to the team.
This developer could be labeled as having a "rock star" attitude, while in reality, they are trying their best to ensure there are no security, performance, or outage issues.
One of the things I always have to explain when applying for a new job is about the substantial number of years I've run my own software businesses.
The interviewer's fear is always the same: that if I take the position, I'll be leaving shortly in order to start another venture. I explain (and point out in my work history) that isn't the case. I don't take permanent positions with the idea that they're temporary. If I wanted a temporary position, I'd do contract work instead.
I don't know if this aspect of my work history has ever cost me a job, but if so, it doesn't matter. I land jobs anyway.
Hiring managers want reliable results. If a candidate does not have the look for months and months and months of consistent output (that's soft slang for years), it really doesn't matter how good they are.
Real programmers hiring more team members see side developments as a strength, they only want their work to get done.
When you're interviewing with companies, try and give them the impression that the thing you want to be doing now is the thing they're looking to have done.
Assuming you're like the rest of us and have material needs and bills to pay, it's not even a lie. :)
I always assumed this, What’s the point of applying for a job saying something you know the hiring manager won’t like? I mean, sure we all have principles and the like, but if you’re applying for a job is because you want that job. Another thing is to quit if you find that the job is not what you expected, that’s fine.
There's plenty of people going around applying saying that their mission matches with whatever the job description is, and they're willing to pay ChatGPT to convince you.
In my experience, companies won’t google you (hell, sometimes they barely will read your cv), so if you don’t explicitly say that you do indie dev, they won’t ever find out (what you do in your private time is not their business anyway)
Yes, some companies avoid hiring programmers who prefer indie work. They worry these programmers might not fully commit to their job or could develop competing products. Others fear they might prioritize their indie projects over company work.
If I hire someone who wants to be an indie dev, how much of their side projects are they going to do instead of the work I need them to do?
I have been on 2 teams where a member had a 'tech' side business. They spent each seemed to spend 4 to 8 hours a week on their side hustle, while supposedly working at their job.
I currently have a co-worker (we do not work on a team together), who has a side business with his family doing indie games, but I have never seen him work on it at work.
Many companies don't really have the luxury of picking.
A full time programmer, even one who sticks around for 8 months or so, is far better than a contractor. There's also the possibility they hang around for years.
Someone who's doing indie work on the side, well, they're upskilling themselves at least. And they're more likely to be incentivized by more time off or less work than they are by more money, so it's not always bad.
It's how I got my programming job with no school or employment background. I built popular software used in my prev community (flight sched and training). Now have a software job.
As a hiring manager, I can say that we don't want to hire the mythical 'rock stars', the kind of know-it-alls that do-it-all. We want people who will be great team players and help build a collaborative culture. Not that 'rock stars' cannot be team players, but there is certainly that risk.
See because of these kind of people you need to act dumb to get a job. These cases need people to take orders and don't need someone with brains.
Act stupid. Get that job. Be silent in meetings and pay attention to the words that circulate around.
These managers find its risk to hire someone who can figure out what bs These play with their boss.
You don't have to act dumb (and you shouldn't). You just have to not act like a "rock star". The most brilliant devs I've ever met were people nobody would call "rock stars". They were collaborative team players.
This, exactly this. I know so many people who are "above average" developers that I would love to work with because they are nice, collaborative people that are a joy to work with. The biggest problems we've faced are with these so called "10x developers", who do get stuff done, but are a total pain in the a* to deal with!
> The most brilliant devs I've ever met were people nobody would call "rock stars"
That sparks my interest. Could you elaborate on what constitutes a brilliant developer from your perspective?
A developer that knows how to treat other people in the team, knows how to be professional, works on what they agreed to during sprint planning, doesn't want to rewrite the project to a new technology and doesn't want to create their own cool project because they know the ultimate goal is to ship to users, doesn't react badly to criticism, is not unreasonably stubborn, has good hygiene, doesn't take code reviews personally and agrees that management has a necessarily different point of view from pure developers.
A brilliant dev is one who consistently produces solid and feasible solutions to difficult problems, in a timely way.
A more enlightening question is "what is a rock star" in my mind. A rock star is a dev who truly believes that they are the smartest person in the room, who looks down their nose at any work they didn't produce, who is only really interested in things that they think make themselves look better rather than things that will actually help produce the best end product possible, who insists on using the whatever latest shiny thing is in fashion over less shiny but more appropriate approaches, and so forth.
The Rock Star will say, “I will do these 10 things by next Friday.” And then next Friday rolls around and 8 of them are done. This repeats week after week, but I can never tell which 8 will get done. They’re boastful and proud that they got a lot done but the rest of the team can never count on them to get any specific thing done.
The other person will say “I will do these 5 things by next Friday.” And then next Friday all 5 are done. And they repeat this week after week after week.
Give me the second person every time.
I agree with your scenario, but I wouldn't consider someone who consistently under-delivers a "rock star."
This is why defining terms is important. For me, a rockstar is a developer who is just further along, who likes to program in their own time, who reads Hacker News, and builds projects on the weekends. Within 5 years, that person will be much further ahead than the rest and will spot pitfalls, security, and performance issues simply because they have encountered them before. However, sharing that information could lead to that person being called a "rockstar" and problematic, hampering "progress".
There is a difference between acting dumb and being a know-it-all.
Someone recently left my team who was a rock star in his own mind. He claimed to know it all, and would go on and on about how everyone else should do their job. The reality was that he didn’t understand the complicities of the issues, any time a team was involved he would try to delegate everything away, anytime there was an issue he was the first to finger point, any time something was difficult he would quit while making excuses that it was not his fault, he only knew one language/framework and saw no reason why anything else would ever be needed/wanted… I could go on.
I’m sure he might sound great in an interview, as he loved to talk himself up and talk about how amazing he was and how stupid everyone else is. In the real world, he was a toxin within our team and no one was sad when he left.
I’m not sure how one would separate a true “rock star” from a delusional wannabe in an interview, other than having a well tuned BS meter.
There is a big difference between acting as if you know something and actually knowing it. You're describing one thing, while the comment you are replying to is describing something else.
Let's consider a developer who is interested in programming and has a lot of experience. If the team is going down a path that the developer knows will lead to issues, or if the developer tries to help because the team is not as strict and it's leading to outages, that developer may be perceived negatively.
However, the developer is able to find security issues and potential bugs during code review, objectively providing significant value to the team.
This developer could be labeled as having a "rock star" attitude, while in reality, they are trying their best to ensure there are no security, performance, or outage issues.
What is the relationship between indie hackers / devs and rock stars in your view? Are you implying they are the same? Different?
One of the things I always have to explain when applying for a new job is about the substantial number of years I've run my own software businesses.
The interviewer's fear is always the same: that if I take the position, I'll be leaving shortly in order to start another venture. I explain (and point out in my work history) that isn't the case. I don't take permanent positions with the idea that they're temporary. If I wanted a temporary position, I'd do contract work instead.
I don't know if this aspect of my work history has ever cost me a job, but if so, it doesn't matter. I land jobs anyway.
Hiring managers want reliable results. If a candidate does not have the look for months and months and months of consistent output (that's soft slang for years), it really doesn't matter how good they are.
Real programmers hiring more team members see side developments as a strength, they only want their work to get done.
When you're interviewing with companies, try and give them the impression that the thing you want to be doing now is the thing they're looking to have done.
Assuming you're like the rest of us and have material needs and bills to pay, it's not even a lie. :)
I always assumed this, What’s the point of applying for a job saying something you know the hiring manager won’t like? I mean, sure we all have principles and the like, but if you’re applying for a job is because you want that job. Another thing is to quit if you find that the job is not what you expected, that’s fine.
There's plenty of people going around applying saying that their mission matches with whatever the job description is, and they're willing to pay ChatGPT to convince you.
In my experience, companies won’t google you (hell, sometimes they barely will read your cv), so if you don’t explicitly say that you do indie dev, they won’t ever find out (what you do in your private time is not their business anyway)
Yes, some companies avoid hiring programmers who prefer indie work. They worry these programmers might not fully commit to their job or could develop competing products. Others fear they might prioritize their indie projects over company work.
If I hire someone who wants to be an indie dev, how much of their side projects are they going to do instead of the work I need them to do?
I have been on 2 teams where a member had a 'tech' side business. They spent each seemed to spend 4 to 8 hours a week on their side hustle, while supposedly working at their job.
I currently have a co-worker (we do not work on a team together), who has a side business with his family doing indie games, but I have never seen him work on it at work.
Many companies don't really have the luxury of picking.
A full time programmer, even one who sticks around for 8 months or so, is far better than a contractor. There's also the possibility they hang around for years.
Someone who's doing indie work on the side, well, they're upskilling themselves at least. And they're more likely to be incentivized by more time off or less work than they are by more money, so it's not always bad.
Some people are afraid of (what they perceive as) mavericks. Some embrace us. Embrace yourself.
Don't tell. Just apply for job.
It's how I got my programming job with no school or employment background. I built popular software used in my prev community (flight sched and training). Now have a software job.
[dead]
[dead]