What are some red flags to look out for in the first few weeks of a new dev job?

Comments

[kirsten Jacks]

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.

[Sally]

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'.

[Joe Hobot]

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. 

[Donovan Taitt]

• Meetings that end with no resolution
• Consistent scope creep on tickets
• Team members aren't clear on what is being built towards
• Ideas are considered based on who they came from, not what they are
• No one else is excited on what's being worked on
• People are scared to voice ideas

[Russ Hammett]

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.

[Henry Williams]

• Your coworkers badmouth the company
• Everyone seems miserable and is trying to leave the company
• Lack of development process; who does what, documentation, etc.
• No code reviews
• No team meetings; everyone just does their own thing
• Lack of developer onboarding

[Pan Chasinga]

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).

• No well-actually’s
• No feigned surprise
• No backseat driving
• No subtle -isms

[dallgoot]

• slack channel for humor but not for help/exchange
• palpable tension during stand ups/meetings
• blaming culture
• "we've always done it that way"
• some Devs fixing bugs on production directly , read: "i don't care about GIT"

[lbonanomi]

"slack channel for humor but not for help/exchange"

Absolutely.

[Isaac Lyman]

Watch out for the unholy startup trifecta:

• open floor plan
• required hours in the office
• deadlines

The first two make it impossible to think. The last one makes it a job requirement.

[Robert Sweetman]

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

[fluffy]

• 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...)