I was a contractor for years (i.e always living without insurance, paid well, hated by EVERYONE). I feel you here and I agree with all of your points relative to a contractor job. I mean it, I'm saying this twice because it's REALLY IMPORTANT that any of the bullet points you mention is a definite red flag for a contract job. I've bailed on $200/hr jobs for things lessor (not bragging, the clients were just that stupid -and maybe me too for leaving?).
With that said, no single item on your list is red flag for a specific (non-contract) job. I'd say that you can pick any 3 things from your list and, at that point, start looking elsewhere. If you are fortunate enough to be working in a company that is aware of these (any of these issues) there is hope.
In my experience, if there are any of the issues you mentioned in any company whereby a manager is not also a developer (i.e. smaller/midsize companies) then bail. They will eat you alive and they don't care for your well being.
However, if you are working for a company that humbly (i.e. smaller/midsize) acknowledges these issues and is "trying" to fix them, I'd say it might be worth it to help out, be a voice, etc. Make the company awesome!
This is my qualifying statement: I've worked for many companies big and small. As a contractor you have similar experience. To ANYONE reading this though, seriously follow your gut. If it feels like a 'bad deal' get the fuck out as soon as fucking possible.
[sorry language but I feel it was appropriate for emphasis]
I wouldn't say this was an issue. For most fixed price projects Waterfall is still the best methodology to use. Everyone trying to shoehorn the Agile methodology into everything they want to do nowadays instead of focusing on the basics is the reason why most companies get development so wrong.
I've worked on both waterfall and agile teams and have never found waterfall an enjoyable experience. Everyone has a preference. At least the teams I've worked on that implement waterfall the decision makers don't understand the negative impacts it has on software development. Agile IMHO reinforces teamwork but yes, it too can be misused.
If you have a scenario where a couple of devs are trying to make a decision about how a particular thing should work, and a manager comes in and shares their opinion and everyone basically just defaults to “okay, since the manager said to do it this way, let’s do it this way.”
I suppose it’s not an explicit ultimatum, but perhaps it’s a silent/implicit ultimatum.
I'm from Aguascalientes, Mexico! now based on New York. Most of my experience is related to code websites and applications, using JavaScript stack-based.
The team limits the face to face communication or any interaction.
The team avoid flexible communication (Slack, Skype, phone calls, etc), prefer pre-established policies.
The code has not tested code (sometimes related to a lot of tech debt and tight deliverables).
No one cares about the engineering side, preferring to keep architectural issues, trying to just release features.
Scope creep happens continuously.
Not on-boarded.
The promises made to bring you to the company does not match with the things you see.
Anyone can answer the question, because "everyone is busy".
Not technical people taking technical decisions.
The team limits the time to experiment with new workflows, architectural changes, technologies, performance enhancements, etc. keeping the project stranded.
No one cares about tech debt.
No one cares about project health.
No one cares about performance.
If someone has the bandwidth, prefer to keep use as a 'free time' instead of help other team members.
Managers saying 'yes' to everything and keeping the team burned out.
Dismiss PRs or enhancements because 'you are not familiar with something'.
The team takes decisions based on someone's opinion without debate.
The people are working after hours every time.
HR is more of a requirement instead of really working.
Even if you are an "expert", everyone wants you to be a code monkey.
No documentation.
No one takes the time to write the requirements properly.
External teams taking decisions in other teams forcing specific workflows, etc.
This is a very good list in my opinion, have been on a job (which was my first job as well) where I've experienced many of these. Thankfully these all felt like red flags to me & I ended up leaving the company!
Senior DevOps Engineer with 9+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
For my former job, 11 of these were true. I stayed almost 5 years because I was convinced I could change things and make all of it better. I was so motivated. Then I gave up. It couldn’t be done 😓
Reading through the comments on this, apparently almost every job I've had had lots of red flag 🤣
I don't know that all of these are necessarily "red flags" for me. Many of the points brought up are things that could be easily changed with some effort. I think the real red flag with some of these would be, mentioning them to your boss and them not realizing or caring about the need for them to change.
I’m quite an optimist at times, but it’s not easy to change corporate culture. It takes a lot of effort to change. Sometimes all it can take is one team changing things and demonstrating the benefit, then a VP takes notice and sends out an edict from on high “We’re all changing!”. If there is no one hands on to facilitate the change, then it will fail. Some teams will bulk at the change, it needs to come from within to really be effective.
Silly hats & being called something related to the company. Forced to ride their branded cycles.
Team lead: "Everyone say hi to our newest intern. All members are called Nootooters for 18mths. Put on your happy hat!"
Dev: "I'm 42 with a Phd do I have to?:
TL: "Oh :sad face: I'm sorry to see you hate us. Now hurry :happy face:"
TL: "That's sooooo much better. See? Do you think? I have to scoot-toot along. Starbucks is on floor 3, their 8x mega latte vente with caffeine spike is amazing!!! Don't forget compulsory yoga is at 4 in the unity center. Attendance is optional. See you there, Nootooter "
Thank you! I didn't want to come across as weird on the internet or anything.
That was how physics used to work before the internet but the telephone cables would fall down & injure intrepid reporters so we had to switch to flat earth with a truman dome. My connection has been perfect ever since.
On top of what others have said, I have a few more:
you were hired for a specific team, but you get there and no one on your new team interviewed you (imagine being in their position in 6 months/a year)
you get there and no one is sure what you should work on first (lack of planning)
you don't have a PR raised on day one (or at least have things set up and you're close to getting something small done)
no one takes the time to help you navigate your way through code on your first few tasks
your team uses a process (and I include agile/TDD/pair programming in this) "because it's good practice" without really thinking if it makes sense
lots of meetings are a good indication that people care more about the stuff around developing great things than actually doing it
people on your team don't dogfood (use the product you're working on)
you're only introduced to your team
your team should take you to lunch the first day, or at least take you with them. A great workplace will take you to the pub for lunch/one evening early on, your team will want to get to know you
you feel pressured to work weekends/evenings early on
you feel watched or you have to guard your words/hide what's on your screen (if that happens for any reason at all, get out that day)
there "isn't time" to learn about new tech/libraries/etc that you think could be useful later on
you have someone on your team who rewrites all your code/rips apart your PRs/makes you feel like your a bad developer
everyone on your team should own the code, if you have one person (even someone with a job title like "tech lead") who must review everyone else's code and makes final decisions (or won't stop arguing until they get their way), that's a worry
Maybe he means a situation where there's no clear idea who is in command. Everyone's pushing responsibilities and decision-making to each other, making it hard to figure out who is leading the team/project.
Front end job isn’t front end. Copy and paste master
Inner politics ruining codebase.
Managements thinks they are better than developers (people leave).
Gossiping about x and y.
Timesheets must be done at 4pm AND emailed a list of things what you have done that day with detailed breakdowns (I messed mine up on numerous times and got called into meetings because the hours didn’t add up, and I wasn’t doing my work)
Arguing with only appointed git merger in the company what you have done in the code and why.
This is becoming a new post for me to write about. I have seen things you people wouldn’t believe, code on fire!
People talk about how great the furniture/space/building is, regardless of how well it actually fits the requirements of the job/company
Razor scooters in the office
"Play space" area in general (unless you're working at a toy company)
Resistance to adding/changing process to try to improve the development life cycle
Idolization of people on the board of directors, especially if it's based on them having been involved in a large project that happened to be successful (regardless of their personal involvement in it)
A big deal made about on-site facilities, especially things that encourage you to never leave
Being told that there's plenty of funding runway when you're interviewing, but then suddenly learning that there's actually way less money after you start
Being recruited by someone who seems trustworthy, only to find they weren't actually at the company (or had left by the time you started)
Especially if the person above "parted amicably"
CEO who flaunts involvement with TED/TEDx/random thinktanks
Constant product pivoting, and/or a failure to actually say what the product is
"We hope to be acquired" as part of the business plan
Being suggested that you "part amicably" when all the above finally becomes too much
(These are all based on one particularly weird month of my life at a startup in San Francisco...)
Discussion between superiors and older team members, whatever you see happening to them will be you in 2-6 months when honeymoon phase is over.
Example: (B= Boss OE= Old Employee)
B: Dude why the f*** did you miss the standup?
OE: I had to talk to Brian who was having issues with some code that was urgent to fix for prod.
B: You know you can't miss the standup its our reputation on the line , don't f*** this up again!
OE: Ok
-------
4 weeks later
B: WTFFFFF why didn't you help Karen fix the code , they have prod issues!!!!!!!!!!
OE: I was at the standup at the time.
B: Who the F**** CARES ABOUT STANDUP! Don't F*** this up, oh and I had to report this incident to HR for careless decisions on your part, so its on file.
They tell you you will 'wear many hats' which you find out means they won't hire business analysts, testers or other QA staff, product managers, project managers, designers, Dev Ops or back-end developers.
'Wear many hats' === 'Do everything on the cheap'.
I'm afraid of this possibility, but how do you raise it in an interview setting? I feel like some managers may try to make it seem like it only happens once or twice a year then it ends up happening every week.
I am going to have to steal the phrase 'un-holy startup trifecta'
Also, from above, "We hope to be acquired" as part of the business plan with zero plan on how to get the business to a point where someone "might" like to acquire it...
Here are some key red flags to watch out for when hiring developers for software development company:
1. Lack of Problem-Solving Skills: Great developers are adept at breaking down complex problems into smaller, manageable pieces. If a candidate struggles to explain their approach to a technical challenge, it might indicate a lack of problem-solving abilities.
2. Inability to Explain Their Code: While concise code is desirable, a developer should be able to explain their thought process and the reasoning behind their coding choices. Difficulty explaining code can raise concerns about clarity and maintainability.
3. They Lack Accountability: Developers who don’t take responsibility for mistakes or miss deadlines can jeopardize your project. Accountability is key. Holding them accountable is critical.
**4. They Are Never Available: **If they are not available during the hours of operations you have asked them to perform on a dedicated basis. They may not be entirely committed to your product development. They may be moonlighting on another project or not being sincere to you.
This may or may not be all from the same job (a previous job)
Two machines, one for development, one for email (note this is not cleared work)
Development machine? it has no internet access
Wait... no internet access? how do you access package stores like npm, nuget, pypi? (hint, you don't)
So... no using other devs code? Nah, luckily we can use a thumbdrive to download stuff on "the internet computer" and put it onto "the development computer"
Lead dev gives you the TFS repo URL, says "get it compiling and I'll talk to you in a week"
Cramped cubicles
No tests
No abstraction
Integration with a third party that has ridiculous password guidelines like "must be exactly 8 characters", "only alphanumeric passwords", "passwords expire every 45 days"
I think that all was discovered mostly in the first week, that last one in the first month.
The manager walks in during morning scrum and announces everyone will need to stay late tonight. Typically due to an unplanned feature needing to go out to production.
What do you do if you see all the red flags after being at a new job? You've already left your old job and likely don't have sick days yet to go on interviews
Can you tell I’ve been a contractor? 👨💻
I was a contractor for years (i.e always living without insurance, paid well, hated by EVERYONE). I feel you here and I agree with all of your points relative to a contractor job. I mean it, I'm saying this twice because it's REALLY IMPORTANT that any of the bullet points you mention is a definite red flag for a contract job. I've bailed on $200/hr jobs for things lessor (not bragging, the clients were just that stupid -and maybe me too for leaving?).
With that said, no single item on your list is red flag for a specific (non-contract) job. I'd say that you can pick any 3 things from your list and, at that point, start looking elsewhere. If you are fortunate enough to be working in a company that is aware of these (any of these issues) there is hope.
In my experience, if there are any of the issues you mentioned in any company whereby a manager is not also a developer (i.e. smaller/midsize companies) then bail. They will eat you alive and they don't care for your well being.
However, if you are working for a company that humbly (i.e. smaller/midsize) acknowledges these issues and is "trying" to fix them, I'd say it might be worth it to help out, be a voice, etc. Make the company awesome!
This is my qualifying statement: I've worked for many companies big and small. As a contractor you have similar experience. To ANYONE reading this though, seriously follow your gut. If it feels like a 'bad deal' get the fuck out as soon as fucking possible.
[sorry language but I feel it was appropriate for emphasis]
Team process is Waterfall?
I wouldn't say this was an issue. For most fixed price projects Waterfall is still the best methodology to use. Everyone trying to shoehorn the Agile methodology into everything they want to do nowadays instead of focusing on the basics is the reason why most companies get development so wrong.
I've worked on both waterfall and agile teams and have never found waterfall an enjoyable experience. Everyone has a preference. At least the teams I've worked on that implement waterfall the decision makers don't understand the negative impacts it has on software development. Agile IMHO reinforces teamwork but yes, it too can be misused.
Nice ones!
Well that ticks most boxes at my current job
Huh now it makes sense. In my former job, 7 of these points were (and probably still are) true 🤔
Can you expand on this? I’m curious.
Sure!
If you have a scenario where a couple of devs are trying to make a decision about how a particular thing should work, and a manager comes in and shares their opinion and everyone basically just defaults to “okay, since the manager said to do it this way, let’s do it this way.”
I suppose it’s not an explicit ultimatum, but perhaps it’s a silent/implicit ultimatum.
That does sound brutal!
I have worked in a team, where the manager (oblivious of the technical complexity of the PR) just announces, "this should be 'done' by the EOD"
hey could you expand on this one? Harmless office gossip is a good way of social interaction, no?
If your teammates are talking poorly about other teammates, that’s harmful gossip.
If they are talking about celebrity relationships, that’s a totally different thing.
In this context, I mean if your teammates are gossiping about each other, leadership, or even customers - that could be a red flag.
Oh I see, the underground politics going on & people saying things about others that they can't say to their face is definitely a red flag!
This one sends chills down my spine 😆
This is a very good list in my opinion, have been on a job (which was my first job as well) where I've experienced many of these. Thankfully these all felt like red flags to me & I ended up leaving the company!
This is very succinctly put Marco! Copying this with due permission to use as a question bank for later use.
Additionally, I found The Joel Test to be helpful towards finding any red flags before joining a new organization.
For my former job, 11 of these were true. I stayed almost 5 years because I was convinced I could change things and make all of it better. I was so motivated. Then I gave up. It couldn’t be done 😓
Great list. All too common.
Reading through the comments on this, apparently almost every job I've had had lots of red flag 🤣
I don't know that all of these are necessarily "red flags" for me. Many of the points brought up are things that could be easily changed with some effort. I think the real red flag with some of these would be, mentioning them to your boss and them not realizing or caring about the need for them to change.
I’m quite an optimist at times, but it’s not easy to change corporate culture. It takes a lot of effort to change. Sometimes all it can take is one team changing things and demonstrating the benefit, then a VP takes notice and sends out an edict from on high “We’re all changing!”. If there is no one hands on to facilitate the change, then it will fail. Some teams will bulk at the change, it needs to come from within to really be effective.
This
Silly hats & being called something related to the company. Forced to ride their branded cycles.
Team lead: "Everyone say hi to our newest intern. All members are called Nootooters for 18mths. Put on your happy hat!"
Dev: "I'm 42 with a Phd do I have to?:
TL: "Oh :sad face: I'm sorry to see you hate us. Now hurry :happy face:"
TL: "That's sooooo much better. See? Do you think? I have to scoot-toot along. Starbucks is on floor 3, their 8x mega latte vente with caffeine spike is amazing!!! Don't forget compulsory yoga is at 4 in the unity center. Attendance is optional. See you there, Nootooter "
Yeah. Stay away from anything like that.
Ick. That reminds me of my Kindergarten teacher. I hated my Kindergarten teacher.
Lololol.
Wait until they try to take your toys away for not saying what they want to hear.
That's the only time I appear.
Thankfully you are the Lord of Time & can make things go backwards like that scene with the weird physics in that superman movie.
I hated your kindergarten teacher too & the brat that always handed them fruit.
👍
Thank you! I didn't want to come across as weird on the internet or anything.
That was how physics used to work before the internet but the telephone cables would fall down & injure intrepid reporters so we had to switch to flat earth with a truman dome. My connection has been perfect ever since.
Stay strong Blue Star Man. Unwinding in progress.
I think the tech angle is covered, so let me add some from the business side:
On top of what others have said, I have a few more:
you were hired for a specific team, but you get there and no one on your new team interviewed you (imagine being in their position in 6 months/a year)
you get there and no one is sure what you should work on first (lack of planning)
you don't have a PR raised on day one (or at least have things set up and you're close to getting something small done)
no one takes the time to help you navigate your way through code on your first few tasks
your team uses a process (and I include agile/TDD/pair programming in this) "because it's good practice" without really thinking if it makes sense
lots of meetings are a good indication that people care more about the stuff around developing great things than actually doing it
people on your team don't dogfood (use the product you're working on)
you're only introduced to your team
your team should take you to lunch the first day, or at least take you with them. A great workplace will take you to the pub for lunch/one evening early on, your team will want to get to know you
you feel pressured to work weekends/evenings early on
you feel watched or you have to guard your words/hide what's on your screen (if that happens for any reason at all, get out that day)
there "isn't time" to learn about new tech/libraries/etc that you think could be useful later on
you have someone on your team who rewrites all your code/rips apart your PRs/makes you feel like your a bad developer
everyone on your team should own the code, if you have one person (even someone with a job title like "tech lead") who must review everyone else's code and makes final decisions (or won't stop arguing until they get their way), that's a worry
(May have more later)
I've never heard of shadow command? Could you elaborate more on that?
Maybe he means a situation where there's no clear idea who is in command. Everyone's pushing responsibilities and decision-making to each other, making it hard to figure out who is leading the team/project.
This is becoming a new post for me to write about. I have seen things you people wouldn’t believe, code on fire!
(These are all based on one particularly weird month of my life at a startup in San Francisco...)
Discussion between superiors and older team members, whatever you see happening to them will be you in 2-6 months when honeymoon phase is over.
Example: (B= Boss OE= Old Employee)
When I was at the Recurse Center, we had this simple set of social rules that I abide by to these days (and look for everywhere I go).
Having a change of manager from the one you interviewed with to one that you will "actually" be working with.
They tell you you will 'wear many hats' which you find out means they won't hire business analysts, testers or other QA staff, product managers, project managers, designers, Dev Ops or back-end developers.
'Wear many hats' === 'Do everything on the cheap'.
"slack channel for humor but not for help/exchange"
Absolutely.
I'm afraid of this possibility, but how do you raise it in an interview setting? I feel like some managers may try to make it seem like it only happens once or twice a year then it ends up happening every week.
In an interview it is impossible unless you now people inside the company.
Remember the question is "in the first weeks of a new dev job"
Watch out for the unholy startup trifecta:
The first two make it impossible to think. The last one makes it a job requirement.
I am going to have to steal the phrase 'un-holy startup trifecta'
Also, from above, "We hope to be acquired" as part of the business plan with zero plan on how to get the business to a point where someone "might" like to acquire it...
facepalm
Here are some key red flags to watch out for when hiring developers for software development company:
1. Lack of Problem-Solving Skills: Great developers are adept at breaking down complex problems into smaller, manageable pieces. If a candidate struggles to explain their approach to a technical challenge, it might indicate a lack of problem-solving abilities.
2. Inability to Explain Their Code: While concise code is desirable, a developer should be able to explain their thought process and the reasoning behind their coding choices. Difficulty explaining code can raise concerns about clarity and maintainability.
3. They Lack Accountability: Developers who don’t take responsibility for mistakes or miss deadlines can jeopardize your project. Accountability is key. Holding them accountable is critical.
**4. They Are Never Available: **If they are not available during the hours of operations you have asked them to perform on a dedicated basis. They may not be entirely committed to your product development. They may be moonlighting on another project or not being sincere to you.
This may or may not be all from the same job (a previous job)
I think that all was discovered mostly in the first week, that last one in the first month.
The manager walks in during morning scrum and announces everyone will need to stay late tonight. Typically due to an unplanned feature needing to go out to production.
What do you do if you see all the red flags after being at a new job? You've already left your old job and likely don't have sick days yet to go on interviews
If you left your previous job in good terms it might be an option to check with them if they would take you back.