Red Flags in Software Developer Job Descriptions
joecmarshall.com
joecmarshall.com
Two Month Contract
That's music to my ears. It signals two important things: First, it's a real contract and thus going to pay really well. Fake contracts present themselves as "contract to hire" or similar so that that they can convince you to agree to a rate of "half your salary, but paid hourly without benefits". But for two months? You're going to hear about my five figure per week rate.
And it's short. Two months and I'm out of there short. So no matter how toxic the environment and how terrible the codebase is, it makes no difference. A guy can stand anything for a couple months. Especially in combination with that first point, which means that this is possibly the only gig I'll need to take all year.
Cold Fusion
Oh yeah, bring it on. This translates as "You are possibly the only person on the planet who knows how to do this work. Charge us accordingly." If you find this in combination with one of the short gigs from above, your life is about to get really good. Your only real problem will be keeping a straight face when you quote the rate you're going to charge for this contract.
In the end, I think it comes down to what you're looking to get out of the job in question. If, like the author seems to be, you're looking for a long term career at a new company then no, you're right, run away from these places.
But if you fancy a bit of fun quick contracting, this article is mostly a list of bill rate multipliers.
Totally agree with your points here. I think it's also great to start with a short-term contract before deciding if you want to become a full-time employee. Just like how people usually date for a while before getting married. Becoming an employee is a big commitment, especially at early-stage startups.
(I'm currently looking for a 1-2 month contract if anyone is looking for a full-stack web/mobile developer. Experience with Rails, React, React Native, TypeScript, AWS.)
You can just quit during your trial period while on a long term contract...
I think it's better to start as an independent contractor (and work remotely.) Then there is the expectation that this is a short-term contract, unless everyone is happy and wants to continue working together.
Speaking and working with other consultant folk, my experience doesn't seem unusual. I haven't experienced first hand this concept of a new hire who is unable to contribute for an entire month. But I do see this sort of comment from time to time, so it must be a real thing somewhere.
I was once handed an insurance codebase and a list of open bugs after the maintainer left on short notice. I fixed a few bugs, which led to more bugs being opened from users in other states. WTF?
Turned out that the business rules naturally varied per state regulator but had never been implemented. Just wading into code would never have resolved that. It took months to compile the documentation before touching yhe code again.
You can't make meaningful contributions on Day One in any regulated industry. Especially as a contractor where the fines might be passed along...
So "fixing bugs" and "making meaningful contributions" is a lot easier if you only focus on syntax and not on what the software should achieve in the real world.
Others, like jQuery, might be in a much more precarious position. The point of the article is avoid these if you can.
The most crap but working technology might be in places which earn money.
They probably won't.
"Companies advertising outdated stacks open you up to the risk of building the wrong sorts of skills, which can have far-reaching effects on your career." (Emphasis mine.)
The wrong sort of skills? Like adaptability, strong diagnostic skills, pragmatism, self-awareness, and not being a massive diva all the time? Although it's true that these things can have a far-reaching effect on your career.
Every company that's been around for a while has legacy code and you need to lose the fear of working with it. You also need to develop enough humility to realise that the code you're writing today is tomorrow's legacy.
Yes, the wrong set of skills. If the market is looking for, say, React devs then you'd be a fool to accept a job where you are expected to work with, say, Delphi or AS400. Yes, maintenance jobs working on old established services are enough to make a living and even a profitable one, but let's not fool ourselves into believing that your odds of being the top candidate in today's or tomorrow's high-profile projects will be greater if you waste your time in outdated stacks.
May just be the business we're in but I feel going with the old limits your breadth (but maybe with a higher price tag? COBOL?)
All right, so maybe you feel bad now about not listening to the engineering team and maintaining a continuous migration of your business-critical code to modern platforms over the last 30 years. But that's all in the past and your million-dollar business will be shuttered by the tax authorities in three months if you don't get this sorted out right now.
Maybe we'll have a world one day where everyone knows the "obvious" fact of technology leadership that everything should be continuously migrated to the state of the art. But maybe we won't, and maybe this fact isn't obvious at all, or even correct. Who knows?
In the meantime, people with skills that have an extreme demand/supply factor can command the highest rates, even if they won't be hired at tomorrow's startup. That's not to say it's a bad idea to learn current skills (for diversification), and definitely say no to working with legacy tech for small money, but that's really an orthogonal point to the one oaiey was making.
I looked into this recently, because I wanted to see if it would be worth learning COBOL to help maintain old banking systems. Unfortunately the pay is nowhere near $20000 / week, and experienced COBOL programmers typically make around $100 per hour, or $70k per year at a full-time job. Right now you can make much more money with modern web and mobile development.
Here's some previous discussion about COBOL rates: https://news.ycombinator.com/item?id=14083214
I was surprised to hear it was only $100/hr, but some people say it might go up to $1000/hr, and one person was making "high six figures". So I don't know. Maybe it's worth getting into if you have some good connections.
Big brand contractors cost us around the same.
DBAs, Sys Admins, operators, a bit more.
Having 30y experience myself, from mobile and Java to Mainframe Assembler, I find the older guys - both on mobile (few) and COBOL (most) to be much more focus on engineering a system that lasts whatever you throw at them, while (most, not all) young coders are about speed and hashing something together that works (but needs overhaul after 3-4 years).
Just my own experience, not saying is the only perspective.
I've noticed that tendency in younger developers too and it's utterly infuriating. Do you do anything to discourage this and, if so, what?
I was fortunate to be a young developer with a desire to write things that could last, so I skipped a few steps and found myself doing the mentoring perhaps sooner than most, but instilling the notion that this thing needs to continue to function, and rejecting work that isn't in service of that goal, is doable.
Only if you expect to leave that company in the next few years like an SV-style webdev. Some of us like the stability of working for an organization where employment time is measured in decades.
I ask because I tend to find that we are generally incentivized both to stay on the leading edge and to, if not running a consultancy, to be regularly moving on to new positions. And it is rare, to the point of IMO barely worth considering as a possibility, to find a company that won't get rid of you given half a chance if it makes short-term numbers better.
I have little fear of being laid off at my company because they didn't even lay anyone off during the last recession. It isn't publicly traded, and has a very flat managerial structure, so the typical 80s-guy bullshit doesn't really fly here. We don't make software and get our revenue from selling ad space, we make real things for real people and we charge real money for them.
I've interviewed devs with over a decade of experience who clearly opted for a stress-free existence feeling like their work was actually helping people, and now here they are in their mid-40s looking for a job with an obsolete skillset and an obvious track record of not adapting to changes.
It's great that you lead a stress-free life in your 20s and 30s, but how do you expect to cope with the problem of being obsolete and useless and no better than a 20yo fresh out of college (and in some regards far worse) when you reach your 40s and 50s?
If you're offering 10%-a-year raises, etc., what you're saying makes sense to me, but otherwise people are going to leave because it's stupid and self-harming not to.
How do you square that circle?
I've never seen layoffs. A person who regularly moves on is quite undesirable, because they would leave before being useful. It typically takes a year before we can really put somebody to use, and two years isn't uncommon.
I left after 15 years.
And why do I care about being a candidate for a high-profile project? Pay? Yes, there can be good pay - along with lousy work-life balance. To steal a line from Agassiz, I cannot afford to waste all my time making money.
And why is an out-dated stack "wasting my time"? Do you have a utility function for my time? I deny the validity of it. I would say that chasing a high-profile project in React is almost certainly wasting my time.
Having code that's lasted long enough to need maintenance is a sign the company has at least some grounded-in-reality fundamentals. The projects that fell apart upon learning the business model was untenable or the technical or social problem insurmountable, generally don't need maintenance programmers.
Staying a little off the bleeding edge also lets you focus on quality execution, rather than chasing the trends. Sometimes the eventual best practices aren't even offered and understood if you're adopting a platform or framework too early. Nobody wants to hit a "drop everything and rewrite because there was a huge API shift" moment.
While high turnover is almost always bad, low turnover on legacy projects might mean that critical parts of the infrastructure have been locked up by ideologues. It's not automatically bad but you should very certainly ask some pointed questions in this area. A yellow flag, if you will.
No business owner or manager wants that. I know lots of programmers for whom any excuse to throw away everything and rewrite from scratch is basically Christmas. Some of the more unscrupulous ones might even try to engineer unnecessary excuses to do just that.
My point: You don't have to give a rational explanation of why you prefer maintenance. You can do so from your perspective, but it won't translate to those who, due to their personality, prefer other phases.
But if you want to say that projects that made it to maintenance should have money available to pay you, then yeah, you've got a point that transcends personality...
Tech stacks aren't that hard. Especially when it comes to web frameworks. To me, maintaining legacy stuff in legacy technologies requires primarily grit - the ability and patience to wade through unique and idiosyncratic mess with a debugger and come out alive on the other end. The fundamental skills of a developer, and even the fundamental technical challenges, don't change that much between frameworks or even programming languages.
The primary danger of being in legacy tech to me is having wrong keywords on your CV and getting auto-filtered when applying for a new job. I know businesses would love to immediately hire experts in their particular tech stack, but let's not kid ourselves - the stacks are trivial compared to learning the processes and code at a particular business. I don't see why a competent Angular developer wouldn't be able to pick up React in the inter-job period to the level comparable with what that person with "React" on their CV has.
Assuming what I wrote above is true, then note that hacking around outdated CV keywords is a much different problem than mitigating those "wrong sorts of skills" working with non-fad tech would hypothetically give you.
True. We're primarily a .NET/TypeScript/React/SQL Server shop but I'm happy to consider anyone with some experience of a C-like language, and some web development experience - it's also not necessary for these things to overlap. Beyond that, if you know what a database (of any sort) is I'm basically happy.
It's hard enough to find people who can program well in any language without making life even more difficult for yourself by adding requirements for N years experience in a given framework or technology.
I think programming language/tech stack is about 8th on my list of deciding on where to work, etc. (This just inspired me to do some writing on the subject, since I've delivered systems in most major tech stacks over the years.)
The former kind of project teaches you valuable lesson. The latter, however, teaches you skills of dubious value, such as NIH-driven development, playing political games to deflect bugs on other teams, and dealing with bugs in dubious ways (stuff I've seen: detecting corrupted writes to flash devices and correcting them by re-writing corrupted sections until all writes operations are successful).
Thing is, if you do this stuff for too long, your mastery of skills that you need to work in healthy organizations tend to decline.
When making hiring decisions many organisations put great emphasis on the specific skill sets detailed in the resume.
As such it can become dangerous if you end up with a resume dominated with legacy coding skills.
I think this is also a good area to contrast the two things listed: tons of places have jQuery, it’s still actively developed, and it’s relatively straightforward to replace incrementally whereas CF is proprietary orphan-ware prudent shops have been migrating away from since the late 90s, when it became apparent that they were only indifferently supporting it, so you’re one unpatched bug or Adobe management whim away from a messy forced migration.
That is just the reality of the web if you live in a high wage country. There is very little legacy work in web technology that is not outsourced.
Which ones, out of curiosity?
Relatedly, constantly jumping into new stuff can actually _hurt_ your progression because if you never master existing tech (find its limits, reading its source), you'll have more trouble seeing the relationships and trade-off's of the new stuff, and spend way too much time just learning API's without gaining any intuition.
Working for a short time on an outdated technology is not necessarily a red flag.
An experienced programmer with all the shiny keywords is rare.
I know of companies training COBOL developers to make sure they can maintain these legacy systems. Mostly they are also the mission critical systems.
The web applications at these financial institutions will be in more modern crappy frameworks. But rest assured the expert COBOL developer gets paid much more for doing a lot less :)
The new guys get removed first. Ones working on shiny less critical processes. Shiny and critical generally happens in startups.
When legacy is being replaced, old timers generally see the writing on the wall and move on as well as retrain.
You might have more job opportunities with the latest and hottest tech, but you will have far less competition with legacy ones. And you can have a long and successful career with them.
If anything I would consider a red flag to have proprietary or in-house stacks. Those could damage your career by employer lock-in, where your build expertise in tech only used in that company, thus reducing your marketability.
'Ton of responsibility, but no real authority'
He's now started a tongue-in-cheek certification program at conferences he attends.
Seriously, such a good idea. Esoteric languages are fun, but an esoteric language that gives you the practical ability to stick it to these ridiculous job ad descriptions? That's just legendary.
So far, he has behaved well. We got him using a normal computer keyboard. This is better for software development than the keyboard he had in the band.
If you want to hire me as a 10x programmer, and pay me 10x the regular programmer salary, I'm all for it :-)
Constantly recycled job openings - to spot this you need to be searching for a few months. But if you notice that the same posting is ALWAYS up for senior positions, and it's not a huge company, your resume has a huge chance of never being seen. From my experience, it's likely a company fishing for H1B applicants. Even if you're on a visa stay away.
No intern program - as a general rule, companies with best engineers scoop many straight out of school. I have never worked at a company with top notch engineering that didn't have an intern program. Sometimes this is hard to see since they focus on certain schools, you may be able to find out from recruiters or Glassdoor.
Heavy usage of third party recruiters - the best jobs are easy to advertise. Either the company is incompetent, the position is for legacy work, or the company is just unnapealing in other ways. If legacy work is your jam, go for it, otherwise be cautious. Note that this does not apply for specialized or very high level positions. Use of executive recruiters is normal since paying the cut is worthwhile.
Low or no bonus - we're in a tech boom nearing 90's levels. Your bonus should be 10-30% of your salary. If the company is public, you need stocks. This is the primary way companies keep apparent wages low. The golden eggs are hidden in bonuses, perks, generous vacation policies, and especially public company stock.
Old school practices - occasional work from home, somewhat flexible hours, casual work environment, free snacks. If they offer less than 3/4 you can find a better gig.
Non technical management - this should speak for itself. I've done it before to much regret.
Strange hiring practices - personality tests, panel interviews, minimum GPA rules, leetcode, asking about personal life (married? Kids? Political views?). If you like the idea of hanging out with people from MENSA, sitting in countless committee style meetings, or next to some frat bros or guys wearing MAGA hats maybe this is for you. But asking these things of you reflects the values of the organization. Birds of a feather flock together and humans are no different.
Find a place with engineers that seem to love what they're doing, eachother, and writing code. If they invite you to lunch and everyone is chatting like old friends you probably can't go wrong. Bonus if they're actually excited to talk to you about technology and what they work on.
There's much more but I'm sure the comment section will be flooded with it :)
Would be even more interesting to get a list of companies that avoid these (the good companies? :) )
If you see a small company with the same opening for a long time, it may also be that they just haven't found anyone yet. Recruiting is hard, and it may take a year to fill a position.
Of course, "small company" seems to be red flag for a lot of developers anyway...
Also offering a software service with lots of traveling until we can build The Product. If they are afraid of risk and play it safe today, the best product concept in the world won't change that.
Also superficial company culture, that looks incredible and thats all there is.
If the Company has a linear mindset in a exponential field.
Wouldn’t that cover a majority of companies in the Bay Area?
I wouldn't put this as a con, I've seen lots of engineers turn into terrible managers, because the skills are completely orthogonal, they also then lose touch with the tech - because that's what happens if you stop coding for even a few months.
Vice versa, I've worked with lots of good non technical managers, who respect and defer to you for technical decisions, planning etc
And of course the other way round, also seen good technical managers and bad non technical ones.
In summary, technical experience of a manager is not an indicator for me, what is are the human factors, do they micromanage? Are they happy to cede control and delegate? Do they give realistic deadlines instead of death marches?
Non technical here does not mean "does not have technical school". If that person took effort to learn, then he can be technical without degree etc obviously.
I would put that as another human/personal trait, the ability to openly acknowledge ones limitations and delegate/defer when someone else has more expertise than you. For example, when making a technical decision, deferring to the tech lead & individual contributors.
If anything, a technical manager whose tech skills are/have slipped away is more likely to be insecure than someone non technical.
However, he still have better ability in deciding who to defer/trust to, better sense on bullshit vs reality, better idea about nuances of decisions and knows words people use. That shows up in how meetings are moderated, people know it and also some will always try to game the manager. Non technical manager is reduced to parroting sentences and attitudes he does not understand fully. Knowing something is not a disadvantage, ever. Not knowing something is.
Every manager needs to make some decisions too. And in there, knowledge helps. Knowledge that slipped away is better then no knowledge and worst then relevant knowledge.
For better or worse, this alone eliminates over half the positions available.
Can you elaborate on that a bit?
I'm not in SV/US, but my impression is that most tech companies are intolerant of different political views and biased against conservatives, so likely you should be targeting companies companies that ask for your political views, if you don't like sitting next to MAGA hat wearing guys.
If they're asking questions like that, what they're really asking is how available you are to work tons of extra hours, nights, and weekends.
4 is caused by people wanting to learn things on the employer's dime.
If employers weren't so cheap with training budgets, employees wouldn't do learning projects that end up in Production... wanna see a dangerous company? Find a place that has 37 different technologies in their hiring ads.
If those 37 different technologies were all recent (or recently outdated) JS frameworks, or tools that are "hot" right now, I'd want to stay away. But if those 37 different technologies are a mix of tried-and-true pragmatic hacker's choice - say Bash, Perl, Python, R, etc. - covering a bunch of different problem domains, I'd think highly of the company that seems to be able to use the right tool for a job.
While 2 months is short, if you don't want short(ish) term contracts of six to twelve months, awesome. Leaves more for me.
I've got around 18 years experience in a variety of tech stacks, being a contractor/consultant is great. Come on board, either create a brand new piece for the client or help them with an existing problem, deliver, move on.
God save me from rotting away in a corner at some huge corporate for years, pretending to care about the company vision. I've done my time at that.
It helps me that here in the UK the market seems to be upside-down, compared to the US - Contractors are usually more highly skilled and almost always better paid than staff.
That all said, that two month estimate had better be a well understood problem domain, with well defined requirements and a realistic amount of work, because most contracts that small are not, and you'll end up two months down the line with the client wanting to extend a month at a time and all sorts of pressure.
jQuery versus MVC? What is this guy blabbing about. jQuery is a little DSL for accessing the DOM using paths and patterns, instead of verbose chains of accessors. If you just want to access some element nested in the DOM, there nothing wrong with using jQuery; and how does some MVC framework help?
* t-shirts, foosball tables, etc as perks
* overly specific job description (you will be building a table widget using knockout.js)
* buzzword salad
There's little more annoying than having a foosball table next to your desk while you have a job to do and are trying to concentrate. At one of my previous jobs, there was a foosball table that travelled between rooms - each 8-people open-plan room wanted really hard to be the ones to have it, but usually after a month or two of serving as company breakroom, they wanted really bad to get rid of it. The table kept making rounds between rooms until they finally freed a separate room to put it in.
Or anything mentioning alcohol. I don't have an issue with alcohol in general, I'll drink socially. But as an indicator of culture it's just the biggest cliche and eye roll for me.
Just some of the things I prioritize: 1) Engaged, smart teammates 2) Solving an interesting business problem. What's the reasoning behind the softer, I'd much rather work with some legacy technology if it means working with a company with a great mission, vs doing the latest trends for yet another ad-tech company. 3) convenient commute 4) Lifestyle (occasional work at home) 5) Corporate Culture Fit 6) Amount of unplanned work and changing directions all the time 7) Amount of Cognitive load of multiple projects at once 8) Location in town (not necessarily for commuting, but just having a nice place to walk to for coffee, out of office thinking time, etc.) 9) Co-workers passionate about their craft
So it's a good sign of other things, but it's not actually the thing I care about.
Which is code for:
> We know that if we display our salary range, we won't get any applications
A typo in the word “Employee” is another red flag. Attention to quality extends to all things around the office including proof reading job descriptions.
Ask if this is a new position or refilling and existing position. With some discovery, you'll find if the churn rate on the job offered is high. If so, run. Something is very wrong.
Also, the Coldbox platform/framework is pretty slick (currently maintained CF framework).
However there are certainly better tech stacks available. For one, the variable scoping was nightmare-inducing stuff.
Lucee and CF runtimes are still activily maintained.
I do still use Dreamweaver templates sometimes though! The awesome static site generator of the 90s. You can give the templates to marketing folks and they can use the GUI to make content updates.
(I know I should feel bad for not using some JS framework that nerfs their SEO and breaks the back button.)
I get an occasional cold call from a LinkedIn recruiter about once every two years for an open role requiring ColdFusion expertise.
a long list of tech, skills, requirements, "must have", etc. with a low salary
Come on, React wasn't even released 5 years ago from that moment.
Either they're so clueless they can't do math, or they're actively trying to hire liars and only liars.
I don't want to apply for a job that forces me to ignore the truth before I even get in the door. What else are they going to expect me to look the other way about?
And in general there is a lot of keyword stuffing in job descriptions.
I've even interviewed at some shops that were Rails-based, but since I had a lot of good OO programming experience, designed and built large-scale systems, had skills with other parts of their stack, I had a better overall skill set than some of their existing Ruby devs. And they accounted for this with part of their onboarding process to get me up to speed in their Ruby codebase....
They have at least touched Elixir code but most of your time will be spent maintaining and/or writing Ruby apps.
That sounds completely normal.
It’s not that odd to be good at two languages.
Back in the day we had client server architectures and it was exactly the same thing. Even more tiers would sometimes be added and there were frameworks for all of them. We didn't get source code. The frameworks were full of bugs. There was no stack overflow. Documentation usually consisted of a few trivial examples. You just had to hack, hack, hack and figure out how it worked. I remember when Swing came out and being very excited about being able to work on something that wasn't completely insane for client stuff (that's how bad it was ;-) ).
This is just the life of the computer programmer. If you like learning new things, it's never a dull moment!
I think a lot of the worry comes from developers that are relatively inexperienced. We put "senior" tags on positions filled with people with only a few years of experience. Sometimes I think it's hard for newer developers to imagine what it's going to be like 10 or 20 years down the line. Being good at 2 language (or frameworks or whatever) is almost laughable. If you don't have half a dozen hanging from your belt once you've got a quarter or a third the way through your career, I think it's a big problem that you should aim to fix. Picking up something new and being effective and efficient with it very quickly is an incredibly important skill -- one which no programmer that wants to work in the field long term should avoid.
Now, if you happen to have a very young team that realistically can't handle the challenge, then that's a completely different story. It's also very important to understand what your team is capable of.
I find knowing both backend and frontend to be hugely important in the design of both systems independently.
I've been involved in tech for 2 decades now. I currently follow frontend / backend JS, Docker/Kubernetes, native mobile as well as RN and Flutter, and general DevOps. In the past I've done Office add-ons in C#, game bots in Java, PHP pre 3.0, Visual Basic GUI wayyy back in the day, done API's in Python/Ruby, and used languages I don't even remember anymore due to preexisting codebases or the team choosing something that fits better.
Compare implementing back-end form validation in PHP and a completely different implementation front-end validation in JS vs using the exact same implementation on both sides. The former approach requires more work, creates a larger maintenance burden and a greater area for inconsistency and error because you need to maintain functional consistency between the two different implementations in the two different languages
Typescript/JavaScript front end.
Python, Java, .net on the back end.
Database written in C++
OS written in C.
There are certainly jack of all trades developers that can do that for you. You will get a jack of all trades solutions that may have oddities here and there. Which could be okay depending.
Naturally we are doing it full stack.
In the same vein, developing native apps with three tiers, while using stored procedures for most of the business logic.
Naturally also knowing about the technologies across all tiers.
I've been a full stack developer since my very first job creating a Java based web app for a startup where the only other coder was the CIO. The CIO didn't know Java and primarily worked on C/C++ embedded code for unrelated projects. Back at this time raw Java servlets were still "the thing" and javascript with jQuery was state of the art on the front end. With just these primitive tools I built a fairly modern even by today's standards reactive web app. Lots of stuff loaded dynamically based on user interaction without switching pages. It was a legit web app, not just a web page. Actually, I was more than a full stack developer. I was also the sysadmin, dba, and network engineer. I physically installed the hardware at the AT&T data center, created a DMZ with the firewalls, configured load balancers, installed the DB and set up a hot backup, literally everything that needs to get done to make a working web application. There was no one around to learn from, it was all web searches: how to secure Apache, how to set up certificates, how to create indexes on the database... everything.
I ultimately decided I prefer back-end development so that's where I spend most of my time these days. However, in recent years I've picked up Angular and Backbone because sometimes the front end team needs some extra bandwidth and being able to help out is really valuable. I'm not as good at that stuff as the dedicated front end guys. I certainly didn't do as good of a job setting up the network or eeking out max performance on the database at my first job as dedicated professionals would have. But I got the job done at a professional quality level. My first job was surely a rather unique experience, but everywhere I've worked multiple people on the team have been comfortable all the way up and down the coding stack, even if they might have specialized in just one area.