Ask HN: How to attract perm Snr Engs when the contract market is so lucrative?
As above - what strategies have people got for attracting senior engineers to join a company full-time, when it's pretty much impossible to match day rates pro-rata in the contract market for anyone other than the FAANG's? I know this doesn't directly answer your question, but here is why the company I work for currently is able to keep me. 1. Interesting work [0]. My day to day is not a slog. I find it challenging and stimulating. 2. I get to the freedom to make decisions. My manager tells me, "I know you have this, so just do it." If I fail (we all do occasionally. Some things just don't work), they don't let the bus hit me. We figure out a solution and then we present that together. 3. A good team. I highly respect every single member of my team. We all know each others strengths, weaknesses and areas of interest. I'm never embarrassed to ask any of them for help and I'm often asked for help/advice/opinion. 4. I have the freedom to learn about projects other teams are working on so I can understand how those projects might affect the project I work on. I can also go work on those teams for a while if I choose to. Those teams are made up of good people who don't mind sharing information. 5. Raises that matter. Not some 1 or 2 pct insult. There's no excuse for that. None. Does the company have warts. Yup. But the above makes those warts tolerable. [0] I'll take interesting work over tech stack any day. I don't give a rat's ass about language wars. Pick something suitable and let's get to making something great. A big one I have to add is time off. I've rejected a lot of companies that tell me, "All new employees start with two weeks off per year." Yea, I'm sure the new CFO starts with 2 weeks vacation, too. I've been doing this for 25 years, and if you offer me two weeks, we're done. > Yea, I'm sure the new CFO starts with 2 weeks vacation, too. LOL I would add that if the company has "unlimited vacation time" it's really important to press and find out how much time people actually take. I like to ask for averages or how much time <executive not doing the interview> has taken off in the last few years. That'll tell you what the limits really are. "unlimited vacation time" is just really an accounting hack. It allows the employer not to have to track that stuff and on your way out, owe you nothing for vacation time. It also allows them to say, well, it's unlimited, take it when you want; then the only option to take time off is around federal holidays. It's basically a scheme to rip you off.... I've had unlimited PTO at 4 companies and 3/4 were truly unlimited. I've taken an international trip for 14 days every year + 5-6 days off for 3 days weekends + any fat hoidays like taking off Christmas eve. I'm sure there are shit companies but it seems like most companies respect it. I feel like the onus is on the employee to ask off. Most people are just too afraid or too much of a workaholic to take off. Uhhhhh... so you took under a month off? That's not a strong argument. If unlimited is actually unlimited then I would be taking 2 months a year at least. I have no need for more than that though. I could take off more if I wanted but I'd just be bored. lol Yes, we have about 8 weeks off in France by law. I feel it could be 12 or 15 and it would be great (what children have at school, at least) Yeah I was thinking to myself, people in Europe get 5+ weeks off per year so if my employer is saying unlimited then I would be crazy to not take at least that much time off. Then again maybe this guy just loves working but I definitely prefer being paid to not work. That's a very important point. My company has always had unlimited time. We just had an announcement from our HR head that managers are going to start making sure you take at least 2 weeks a year, ideally in a big block. I've never had trouble taking my vacation, but I'm really pleased that we're going to be enforcing a minimum, to help folks who are more hesitant to take theirs. The legal minimum in the EU (and many countries) is 20 days. I've seen this enforced once, and everyone was amazed that our colleague hadn't used the minimum 20 days. (We had 30 days according to our contract, but the requirement was for him to take 20. The other 10 were up to him.) Yeah, I think the average European probably takes more time off than even Americans that think they take a lot of time off. We get 32 days + public holidays, so you could take something like 7 weeks off with careful planning. Most people do. Because most people do, it isn't looked down upon at all. A friend at a US firm said they told him if someone could take 3 weeks off then clearly the company didn't need them and there wouldn't be a job to come back to. Here it wouldn't be anything unusual at all. i remember years ago my wife's friend (we're in US, she was in the UK) commented about how crappy US 'vacation' policies were. She'd been at a place for ... several years, and now had seniority for... at the time it was 11 paid weeks off. It seemed a bit excessive, because it didn't include some national holidays as well, so... basically she had > 3 months 'off' every year. The biggest problem she/they had was trying to figure out stuff to 'do' during that time (visited us in the US for a bit). I think another issue was trying to coordinate her 'time off' with her husband (IIRC he 'only' got 8 weeks paid vacation). This is good for the company, too. It's a form of fraud detection. When employees take two weeks away in a block, the company can more easily detect ongoing fraud or other funny business going on. That's how a French rogue trader was finally caught: https://www.wsj.com/articles/SB10000872396390444914904577615... Yeah, my mom works at a bank in the US and within her department they have to take off at least 2 weeks consecutively and only that one person in the department can be off during that time for just this reason. They use it as a yearly check to make sure there is no fraud going on. We have unlimited vacation time I have taken 4 days holiday and 6 days sick leave in the past 12 months (4 days because i was on my ass with the COVID vaccine doses). I would have normally taken at least 20 days holiday but it seems pointless to take time off to sit at home and do nothing. This year i have 2 weeks in July and 2 in October and a week for thanksgiving and a week for Christmas. Take a break! I took 26 days leave last year (4 pre-Covid), and carried over a few extra. Even with Covid, there were opportunities to take trips locally, or just have a day out of the house with no obligations. I used a few days to work on hobbies when friends were working. When it's use-it-or-lose it (or, in my case, use-it-or-be-forced-to-use-it-in-crap-weather-December), why work? Uber had/has unlimited vacation time. When I worked there I took no less than 6 weeks a year and one year took 8 weeks. The formula is one week every quarter and then 2 weeks at Christmas. That already brings you to 6 weeks. Yup I have interviewed at a lot of companies with unlimited time off, every single one of them seems to have taken less than 4 weeks off. This is what I get at my current company with no unlimited vacation. And at our company, sick time and mental health days are separate and not counted against your regular PTO. In California at least, if you have X days of vacation time and you don't use it in the year when you leave, they have to pay you for these days. If it's "unlimited" time, you get bupkis. thats the rub, the companies dont need to pay you on exit and they can manage against the average they would have granted in the first place and prune employees taking more. net win. Also, unlimited vacations[0] are a trap. People end up taking less than market norms (US - 2 weeks) or informally/tribally decided what is the normal amount of time to take off. It also means people work while traveling. [0] - if you're an employer and offer unlimited vacations be honest about it: set guidelines about how many days people typically take, if people are expected to be responsive / working while on vacation, etc. I counter-act the unlimited vacation thing during onboarding (if not interviewing) by setting expectations: "I consider a reasonable amount of vacation to be X(=3) weeks, does that sound reasonable to you?". Then I track it myself and make sure I take every day. (A very good sign, and really the only way to ethically do unlimited, is when a company sets a minimum amount of time off.) Isn’t 2 weeks the standard within the US? If you’d like longer vacations then Europe is your best bet It's a pretty standard thing (US) to start with for entry level jobs. What the GP is claiming that is that policies that: "everyone starts here with 2 weeks, you get a 3rd week after N years, a 4th after M" are kind of bs for senior employees. They have a point; this rarely applies to senior management, for example - and effectively you are asking people to take a major quality-of-life hit when changing jobs. This can lead to conversations like: "You've asked for N weeks vacation but policy is strict everyone starts here with 2 weeks". "I can probably live with that for an extra X k/year." ... "We can do N weeks". I think in tech 2 week is becoming rare though. More likely either longer, or so-called "unlimited" (which itself is nonsense). The more weird thing I find in US corporate culture is a tendency to not take the vacation you are allotted. In some countries this is legally at least problematic, in the US it's sometimes a badge of honor. Three weeks is becoming pretty normal. A lot of places like to combine that with holidays and say 25 days (standard US is 10 holidays). At most small places where HR is flexible, the PTO package is highly negotiable and I usually leave that to last and tack on an extra week, as they know they want me by that point and it doesn't cost them anything extra. The conversation does go like you describe at some places, but others are absolutely rigid. One place where I actually accepted an offer, they increased everyone's vacation after my negotiations (small company). That has to be the most goodwill I've had when joining a team of people I didn't know. But you're right, I never say now. I price it all accordingly, so they can say no. In a discussion of "it's so hard to attract employees", you probably should consider doing things that are better than "standard". Standard for many companies? Probably. For tech? I don't think so. We start at 10 days the company picks (the typical ones) plus 19 days that "you pick"* and add 1 day per year of tenure for the first 5 years and that feels "competitive but not exceptional" for tech to me. We also offer an additional 4 weeks (contiguous) once every 5 years, which is not standard for tech and is an enjoyable perq. * - plus sick time which you aren’t paid out if you’re fortunate enough to not need to use, plus parental leave My impression is that allowed vacation days has increased a lot in US tech companies over the past 10-15 years. Salaries and bonuses too. Not in tech. We aren't anything special and we start with ~30 days holiday + vacation on day 1, up to 49 after a decade. 20 days is standard in the UK but most companies will give you 25. Some also give you the option to buy more. > I'll take interesting work over tech stack any day. I don't give a rat's ass about language wars For me, having a Windows (Server) environment is enough to kill my interest. I know several shops in my area (mostly medical field adjacent tech) that are entirely Windows. That's probably more because of my extensive *nix background than anything.
Language doesn't matter, but platform can/does to some Yeah, my preferences for tech stack are less "I must have X, Y, Z" and more "I refuse to work with X, Y, Z" I'm kinda the same, except one further: I don't think I ever want to use Visual Studio again. I cut my teeth on Emacs and find VSCode a decent compromise but Visual Studio is just such a clunky editor. Extremely limited UI customization and code highlighting options and such. I don't like it at all VSCode is fine IMO. I'm a vim guy and I'd take vim without plugins in PowerShell before I even go through the install process for VisualStudio again. > Language doesn't matter, but platform can/does to some Very much this. I can put up even with FORTRAN - hell one of the most interesting challenges I had recently was figuring out how to call C++ from FORTRAN. But I've been living in Emacs for almost two decades, and longer than that in Linux. I have to insist that my personal development seat is Emacs on Linux. Yes, I can target Windows and probably anything else from Linux (iOS is a challenge, but I'm looking into it), so I don't see the "need" to develop natively. Yeah, after developing on linux for the last 17 years or so I would never go back. I also prefer non-Win environments but generally my higher concern is whether the hardware specs and configurations are sufficient for the loads that are placed on them. 18 years experience here. I have recently converted to startup employee (again), giving up a lot of money in the contract market exclusively because I am motivated by the business case and have a deep respect for one of the founders, who is an actual domain expert and proven leader from the industry our customers are in. What I find the most difficult, by far, is "coaching up". Coaching down and motivating junior and intermediate developers comes easy by leveraging the inherent mutual respect that craftspeople have for expert colleagues who are fair and supportive. But coaching up is really hard. Because it often requires convincing superiors with less technical understanding and experience in building teams. In contract world, it is easier to be accountable for the Whole Project™ because that's how liability works and we have full power to get it done. As an employee who might have to report to nascent technical and product managers, that initiative can be perceived as stepping on toes, and can invite being thrown under the bus for their mistakes. I don't have a solution, but any company that can solve this issue and is good on the other material benefits should have no problem retaining talent IMHO. This is my pain at the moment. My co-founder is new to startup but seems to think that because I can code, I should just focus on that. I've been working in startups for >10 years now, have run Startup Weekends, and have a bloody MBA. Trying to coach him on what should be happening with the marketing funnel is proving impossible. If I was contracting I would be counting the money while watching them mess it up with a wry grin on my face. Why are you putting up with it then? This is a very good question, that I keep asking myself. Mostly because loyalty and friendship, and the continual hope that it'll turn a corner soon. But I've put a date on my willingness to tolerate this. If it doesn't turn a corner by July, I'm out. > 5. Raises that matter. Not some 1 or 2 pct insult. There's no excuse for that. None. Is a big one. I am very unsure why companies seem so reluctant to do this when the cost of hiring and training a replacement are non-negligible. I think a big reason is because that "1% to 2% base pay raise" gets hidden behind bonuses that (usually, but not always) seem bigger, plus stock-based pay that tends to be bigger every year (until it isn't). For me, it's not as gigantic of a deal because as long as my raises cover the rising cost of rent--which it might not this year due to where I live becoming even more massively popular in the wake of COVID--then I am fine with this trade because I hate interviewing and I hate change even more. I used to spend the bulk of my annual bonus and stock grants and saving a little; in recent years, I've flipped that. If I was seeing a consistent 10% YoY gain in my total compensation, you're right--I probably wouldn't care much about the 1-2% base increase. But that wasn't the case, at least for me. Because it works? With those 1 or 2 percent raises being a norm almost everywhere, it's hardly a reason to actually leave the company. And saving for not doing 5 to 10 percent on everyone every year are much bigger than an occasional hiring and training costs. >With those 1 or 2 percent raises being a norm almost everywhere, it's hardly a reason to actually leave the company. But it is a reason to leave the company because you can easily get 10% or more switching jobs. >occasional hiring and training costs. Hiring and training costs are enormous, and they aren't occasional when you're talking about software companies with very high turnover. If you're incentivizing job hopping every few years, the average programmer at your company could be spending 25% or more of their tenure ramping up to full capacity. >But it is a reason to leave the company because you can easily get 10% or more switching jobs. Depends on the company. Mine is 100% remote since COVID, has generous benefits, a strict 9-5 M-F culture, and plenty of interesting work to do as much (or as little) as I have an appetite for. I make maybe 10% under market rate, but it would take at least a 50% raise to get me to leave. That's never happening, as it would be well over what anyone short of FAANG would pay for a senior dev, so there are definitely intangibles about a work environment that are worth more to me than another $15-$20k a year. Right but there's an assumption of all else being equal when making a comparison like that. Obviously you can get away with paying below market rates if you provide some other benefits to make up for it. What if there are identical "intangibles" at the place offering you a 10% raise? Unless you know someone inside the company I'd guess that's pretty hard to judge from the outside or through a few interviews. Seconding this. I was in my previous position at a little under 5 years, with in fact substantive raises (8-10%) each. But still I jumped 15% immediately in base salary by joining to another company. > Because it works? Only if you have people who crave stability more than they need/want more compensation or who are invested in the work with you (i.e. they find it _really_ interesting). Otherwise it just creates churn, as people need to leave to get much of a bump up and leave the next place next time they want a bump up too. So it only works overall if most people are in the "wanting stability" group. This is probably part of the driver towards contract work rather than perm: if you need to switch jobs regularly to keep improving your conditions, then why not have the extra flexibility and/or extra compensation of working contract? It becomes a reason over time. The raises are less than inflation, so over time the external jobs are more appealing since those postings have to stay competitive. That's why people jump from company to company every 2 years for the pay bump. > 5. Raises that matter. Not some 1 or 2 pct insult. IMO, pay or raises don't matter much (as long as it's enough to live without worries). If the company culture is bad then yes, it's all about money. Pay me top of the market or I'm looking to move. But if the job is a pleasure and I'm respected, I don't much care for the pay. What does it take to make job a pleasure? In a summary: respect expertise. I wouldn't dream of telling our legal or accounting departments how to do their job, they're the experts in their fields. But for some reason engineering no longer commands any respect (pay != respect) so has lost all autonomy. (I say no longer because it wasn't always that way, in the 90s engineering expertise was highly valued.) Here are three sure fire ways to make me leave ASAP: "Agile". If you treat everyone as a replaceable cog kept under the daily whip of constant status reports then don't expect me to stay very long. Lack of autonomy. If engineering decisions are being made by a product manager with a BA in Arts instead of principal engineers, you can bet I'm interviewing behind your back. (Sadly this is most silicon valley companies these days.) "Unlimited vacation", aka might get 2-3 days per year. Instead, align compay interests with mine, accumulate vacation days and I can take everything I've accumulated. No less than 20 days per year + holidays. Yeah, this is pretty much it. Be a place I want to work. That means interesting work, good people, sane management, and good pay. (You don't have to pay more than contracting, but you have to pay well. I might take somewhat less money to work at a place I like, but if you're pay is lousy, I won't like it no matter how nice the people are.) This. I was going to write out my own list, but you covered everything I wanted to say. I would counter that most companies can't attract or retain talent because they don't really want it. Most of the work that needs to be done in the world doesn't require the top 5 percent of the pool. This is a difficult thing for companies and people to accept, but it's very true. Maybe we should rephrase OP's question as "How to attract perm Snr Engs when there are so many companies where there is:
1. Interesting work. The day to day is not a slog. ..." You get the idea :-) > 5. Raises that matter. Not some 1 or 2 pct insult. There's no excuse for that. None. This x100. I don't understand why companies see this as acceptable, especially when market rates might be so much higher. The top 3-5% of software engineers do not work at startups. They work via their own S Corporation... Why? To copy the same way most doctors and high end professions get paid... 1. solo 401k - hit maximum contribution limit (57k-63.5k) 2. cash balance/defined benefit plan - your solo pension plan up to 3 million
For year 2021, the maximum compensation is $290,000 to contribute to your defined benefit plan... As governments grant corporations better preference in tax treatment, you really got to ask yourself why anyone would want to be a W-2 employee anymore... (w-2 employee of your solo S-corp is the exception) Nothing stopping any company from giving you options as well... Some extra rules and costs arise with defined benefit plans but well worth it. SV wants capitalism and free markets but when forced to do so with workers the hesitation comes up... but but but you gotta come a play foozeball at work on the weekends... and we gotta share a beer and tell me about your dev friends.. https://www.manning-napier.com/insights/blogs/research-libra... https://saberpension.com/defined-benefit-plans-self-employed Are they hiring? :) Relatively few engineers actually want to do contract work. The day rates look high, but they have to pay self-employment taxes and health insurance, as well as charge more to cover inevitable gaps between contracts. It seems unlikely that the existence of contract work is preventing senior engineers from joining your company. To be blunt, it’s more likely that you’re simply not paying enough to be competitive or you’re not an attractive place to work. Without knowing more details about your specific situation, the obvious change would be to simply offer more compensation. Higher compensation can make an unattractive job more attractive. > Relatively few engineers actually want to do contract work. The better contractors I've worked with all do, here in the UK. The day rates are high. The taxes are the same or lower, health insurance is optional. There's some company insurances you need and you have to get an accountant, but all-in that should be covered by less than a week of work each year. Gaps between contracts are desirable! Having a whole summer off to live on your accumulated war chest and chill out, it's amazing. Plus jumping on to a new project every few months keeps the work interesting, rather than stagnating at the same desk for years on end. I mean, it’s not surprising that people who are doing well in the contract market like the contract market. For my part, I literally left the UK in part because the industry there was so geared towards contract work or boutique contract houses as the only viable career path for senior developers. It’s just not for everyone. I like staying with a product team and building and owning stuff; I like companies that build their technology in-house rather than outsourcing; I like being able to shape what the technology team contributes to the business rather than respond to already-baked RFPs. I like stock-based comp. The UK tech job market is very well suited to certain kinds of developers and certain kinds of relationships between businesses (and frequently government organizations) and their technology providers. It’s not the only way though. I certainly agree that the UK market for senior tech people is very poor, you're right that past a certain point the only way to keep advancing in your career and keep raising your income is to strike out on your own this way. I think it's incredibly short-sighted, but a lot of British businesses treat their software staff as equivalent to generic office inhabitants, rather than highly skilled software practitioners. They also seem to treat their tech staff like children. Ah yes, the "highly skilled engineer paid at great expense but not allowed to have an extra pen" problem. Sounds ridiculous until you go and need to almost beg to get a pen. Oh this triggered some memories! Yes, I've worked for companies that made you return the old pen to get a new one. Definitely for me. Having to sign for pens snd pencils was a thing at one place. They later went broke. My contract ended two years before they did, I wonder if it was the stationery budget or the bad will it caused? There's a potential research paper in this somewhere: "Subtle consequences of mildly antagonistic workplace practices and their effect on annoying the crap out of people to the extent of later bankrupting a company due to the snowball effect." Been a long day. > I think it's incredibly short-sighted, but a lot of British businesses treat their software staff as equivalent to generic office inhabitants, rather than highly skilled software practitioners. They also seem to treat their tech staff like children. This is not just true for British businesses... it's common worldwide across everything that's not a tech startup. The older the people in management are, the less likely they are to even understand what the younger staff is talking about. German Mittelstand is infamous for this - they're roadblocked on one side by the government bending over backwards to impede proper buildout of real broadband across the country and not just in cities, and on the other side by 80+ aged patriarchs who still are dictating business communication in an audio recorder for their secretaries to type down. These pre-Boomer fossils are only focused on micromanagement and keeping control until the day they literally die, and the Boomer generation isn't much more modern either. The result? Humble startups led by young people of a diverse background are eating their lunch left and right, and the Boomer+older generation are standing still, scratching their heads and wondering what's going on. What do software staff have to do with laying rural fibre infrastructure? What do octogenarians have to do with software managers who these days are usually younger than the engineers, either because they went straight into management having negligible interest in tech, or because they soon found out they weren't any good at implementation? Wanna live in a nice place with a garden for reasonable prices in your own house? Rural Germany is for you. Remote work from there? Yeah, not on 36k modem speeds you're not! > What do software staff have to do with laying rural fibre infrastructure? The rural fibre point was only to illustrate how German Mittelstand is blocked on not just the treatment of their tech staff. > What do octogenarians have to do with software managers who these days are usually younger than the engineers Micromanaging octogenarians are who are calling the shots in way too many Mittelstand companies, often against the express demands of their younger staff and management level. That why I can’t stand contracting. If you treat your team like children they are gonna behave like it. Also: no accountability of decision. Fire a few people and keep pushing harder. Never smarter. This does not convey to quality product. It convey to pass arbitrary deadlines with half the team gone and the other ready to switch project. Terrible knowledge management, too. I’ve had a similar impression, I think. What kinds of developers, and relationships, if you don’t mind elaborating on your reply?... Thanks Curious, where are you located right now and did the market there cater to your expectations of less contract work? I’m in the US, in the Boston area, and yes: I have been successful in growing my career within tech companies. We build software businesses here. The UK should try it some time. > Gaps between contracts are desirable! Having a whole summer off to live on your accumulated war chest and chill out, it's amazing. If you can do that, that's amazing. Unfortunately many contractors fall into the "if I don't work I'm losing money" mentality and never stop. Then they start converting everything to how many days it cost them to earn and try to never spend money. I've seen it so many times and it's so unhealthy. Strangely it seems to mostly affect people who do get stupid-high rates. The most absurd case was a contractor guy in a big corp at lunch with employees from the same team - he was pulling 3x our employee rate equivalent and complaining how he can't afford to take any days off or he'd be "losing" his daily rate. This happens with everyone I know who is self employed. Lawyers, auto shop owners, repair shops. If you bill hourly, or by the job, it is very easy to calculate how much you lose by not working right now. It's true, and you do get into "If I take the week off I'm losing £X!" headspace sometimes. But it's important to remember that if you don't take that week off, you're more likely to burn out. And it's also important to remember why you got into it in the first place - being able to take significant amounts of time between contracts was a big part of it for me. I intend to take three months downtime a little later this year. > Plus jumping on to a new project every few months keeps the work interesting But contractors are usually hired for their existing skilsets where they can jump in and start contributing immediately. So you end up doing similar projects. eg: If you are a backend programmer, no one will hire you to work on as a machine learning engineer on day rates. This is a big myth that contractors are working on something new and exciting every few months. Most of contracting work is short term grunt work. > rather than stagnating at the same desk for years on end. No its the opposite. Companies invest in training and take a chance on you doing something new inside in the company. I've been contracting for 16 years, had a few perm jobs before that. While it's true that you get paid to do what you're already good at that's the case for everyone. The difference is, as a contractor you can afford to take a few months off and become good at something else - then you'll get a job doing that instead. You can also pick and choose your projects more freely and there's usually nothing stopping you having long term projects as well as short term gigs, often working for multiple clients at once. In the US or elsewhere where health insurance is a thing I would probably go perm. > Companies invest in training and take a chance on you doing something new inside in the company. I literally LOL'd at this... If you're great at what you're doing, they're keeping you where you are - and "invest in training" could easily mean a 3 day workshop where you find you already know more than the instructor. No thanks. In answer to the original question, offer more money than you think you can offer and set it up as a 3 month contract-to-perm situation (don't write that down anywhere if you're in the UK - they'll immediately be inside IR35) so you know it's a good match. Alternatively, skin in the game in the form of shares or whatever - but they'd have to be confident in the business, I've rejected that offer in the past. > become good at something else - then you'll get a job doing that instead. I don't understand this. How can someone trust you that you picked up some new skill if you have no experience in it. Do you put it on your resume anyways? How can somone even pickup software sales ( for example) on their own free time. > I literally LOL'd at this... If you're great at what you're doing, they're keeping you where they are - and "invest in training" could easily mean a 3 day workshop where you find you already know more than the instructor. No thanks. No didn't mean that kind of investment lol. I meant more like taking a chance on you. I was able to convince my manager to let me work on product marketing and sales even though i was regular backend dev. It was one of the best career moments for me. This would've never happened if i was contractor. > I don't understand this. How can someone trust you that you picked up some new skill if you have no experience in it. Do you put it on your resume anyways? How can somone even pickup software sales ( for example) on their own free time. Well, for anything which produces tangible output you can show off (I'm obviously thinking of programming) it's fairly straightforward to prove you can do it. Software sales? Yeah, no, I couldn't learn that in my spare time - good point. Personally a jump to marketing and sales sounds roughly as enticing as the time I was offered either redundancy or a new role as a Lotus Notes dev, but I'm happy it floats your boat. > it's fairly straightforward to prove you can do it. How? What do you put on your resume ? I am genuinely curious. Forget about sales, how do you prove that you can now implement their machine learning projects. Contractors can be let go immediately with almost no repercussions, so the bar for engaging them is much lower than the bar for hiring a full-time employee. When I was contracting, companies would generally contract me for a week or 2 based on nothing but me telling them I could do something. If I delivered on that initial result, they'd come back for more. How do you get into that market? > In the US or elsewhere where health insurance is a thing I would probably go perm. The difference in compensation more than offsets the cost for insurance, in most cases. All I have to say to that is "You'd be surprised", particularly when you get a reputation for picking up new things quickly. > Companies invest in training Literally never happened for me in 12 years of perm work, for large and small companies. Discounting trivial/patronising things like security training. I've self trained or picked things up as I go along a few times as a contractor, just as I did when perm. The time you use to self train is an investment by the company that you are expected to carry out. The trappings of instruction are not what makes training educational. > The time you use to self train is an investment by the company that you are expected to carry out. Then contracting has been no different to perm work in that respect, for me. :shrug: > I've self trained or picked things up as I go along a few times as a contractor Why would i hire a self trained machine learning engineer with no experience on high day rates when I can hire someone with experience. Ppl hiring contractors don't have time or patience for you to experiment with self training on their dime, I would hire a fulltimer if i have all the time and money for ppl to learn on the job. Again, all I can really say is "You'd be surprised". I think ML is probably different, in that it's not something that can be just 'picked up' that easily (AFAICT). But it's honestly surprised me over the years how often my clients have said "Hey, I know it's not your main area of competence, but do you reckon you could have a go at this?" Wouldn’t we all just rather have someone competent work at our issues? It is not like most orgs can simply hire some perfectly knowledgeable superstar for their next problem. They can just spin the wheel of fortune and get someone who has the correct experience on paper. I‘d go with the person who solved my last 5 problems competently as well. > "Hey, I know it's not your main area of competence, but do you reckon you could have a go at this?" If you're already working in their systems and domain, you probably have a decent idea of how you can address it, even if it's outside your main area of expertise. This happens to me, and... if I'm completely unqualified, I just say "I can't do that, here's someone else who can" and make a referral/connection to someone in my network. That's often the harder part - finding someone in my network who is both competent and available. The most important thing is probably having that network in the first place, not just to offer referrals but to get good gigs yourself. I know a few very experienced people who have looked into contracting or freelancing over the past year either for the first time or for the first round in many years. They have good skills and the aptitude to pick up whatever else they need, but without the broad network that comes with years of doing short term gigs, they've found the market very tough to break into. I doubt they would recognise the talk of a seller's market and ever-increasing rates that we see on sites like HN! If you don't have that network and people actively seeking you out, you get stuck with looking via agencies (= ghosted often if you don't already have exactly the right buzzwords) or the online marketplaces (= low rates, poor quality clients and high risk of problems with the marketplace itself). And even if you do, I've seen more than one person whose whole network basically all fell apart around the same time because whole industries were hit by COVID. Today even more than usual, it is about who you know as much as what you know. companies investing in training is real. Be it pushing for certification, mooc, internal training credit. All of that was part of my review for instance.
It does work. Ugh, reviews, another part of employee life I haven't missed! That stuff re: training was not something that was part of my life as a perm worker, in the UK or Australia. The companies certainly liked to pay lip-service to employee development, but I didn't see much evidence of it actually happening. One of the things I enjoy about contracting is that instead of watching all the videos on harassment and whatever, I usually just have to sign a code of conduct. Those corporate videos are soul crushing. I guess the exception was one quiz about bribery I had to take at IBM. It asked me what I would do if I were offered a cook to go with my lodgings where I was staying during an engagement. This woke me up to the possibilities of bribery I didn't know people were getting. I'm not exactly looking for bribes, but my the hypotheticals had me thinking way too small. Actually you raise a good point - I also did a short bribery and corruption self-driven training thing at IBM, and that one was at least interesting. The “Active Shooter” one at JPMC was somewhat sobering. I would accept a cook, btw, if anyone out there is bribing :) I received quality training on framework, language and protocols by coworker of that company. Those people spend a good 20% of their time doing that for clients anyway, so they are both comfortable doing it and I thougt it was decent dive ( modules span 20-30 hours ) I was not referring to conplicance trainings. Those, of course you won’t learn a thing. Same. Heard much discussion about it at every job, but in terms of actual time or dollars -- nah. > But contractors are usually hired for their existing skilsets where they can jump in and start contributing immediately. So you end up doing similar projects. That's not been the case with our best contractors. Yes, in some cases, they were hired for skillsets they already had. But a couple of them we work with, we were happy to let them learn elixir on company time because they demonstrated solid polyglot skills. And that's paid off in spades. I've had the same experience with my personal consulting agreements. People sometimes hire you for your experience, and know you'll still bring your judgement, experience, and problem solving mindset to the technology du jour and not start from scratch. > But a couple of them we work with, we were happy to let them learn elixir on company time Yes thats what i am saying. Hiring rails devs and letting them learn elixir is no big deal and kind of makes sense. But that not really exciting stuff for senior engineers. Senior engineers want to learn new domains like sales, learn leadership skills, have a say in product direction ect. That to me is exciting stuff, not learning another web framework. > Senior engineers want to learn new domains like sales, learn leadership skills, have a say in product direction ect. Not all senior folks are interested in that stuff though. Some are more interested in picking up new tech and delivering good quality technical work than they are in going outside of tech to other parts of a business, or getting into management. > That to me is exciting stuff Sounds to me like you're less interested in the software creation aspects these days, which is also fine :) I think the key there is the new domain/language. One of the contractors was a rails dev, the other one was actually just a polyglot, although we had hired him for Ember.js help. But the project is also a high impact, high stress, and challenging project (COVID vaccination software) so yes the domain, level of challenge, and impact helps tremendously to stand out. As a tech exec and senior engineer myself, I find it highly appealing to do contract work mainly because there are many options/opportunities, and the ability to take a gap wherever you want. That's why I've had my own company for roughly 12 years. I do think it'll remain that way for the foreseeable future. Many of the smartest people I know are happy to remain contractors because of the flexibility. I will say though, that I would never do this without Obamacare (in the US). If not for that, I would be "stuck" in a W-2 job just so I could insure my family. (honestly not trying to pass judgment on people who have 9-5 jobs, I'm just not wired for climbing the corporate ladder, etc) Which is why I always say, supporting Medicare for All is (ironically) one of the most pro-business moves we could make. It will unleash entrepreneurial spirit unlike anything we've ever seen in the US. The number of 1-2 person businesses will explode. All the talent that's stuck at large employers so they can get those health benefits for their families (even though, thanks to Obamacare, you really don't need to anymore) will get liberated. As a contractor training is my own responsibility. I pay for own Pluralsight and O'Reilly subscriptions and conferences all tax dedcutible. I take at least 2 certification exams each year as the motivation to stay current. This has allowed me to improve my resume year after year. Asking a contractor if they like doing contract work is a bit like asking someone at McDonald's if they like hamburgers. The answer is pretty likely to be "yes". No argument here! I'm just taking (minor) issue with the assertion that relatively few engineers want to do contract work. If that were the case you'd expect some contractors to wish they were perm. I think the benefits I outlined are such that quite a few do want to. I've also run into quite a number of perm folk over the years who want to do it but don't quite have the confidence in their own skills to make that leap. I was one of them! you can start by working in consulting The same in Australia. I doubled my income from going to contract work without even using a business/company structure. Long timers use a company structure for even better gains. As someone that is employed full-time in the UK I must say you (and others in this thread) have piqued my interest. I am still quite early in my career but the ability to choose contracts (and possibly even the tech stack) sounds like a dream. Do you or anyone else have advice on how to get started with becoming a contractors? I would recommend doing your own research on this one. Contractor UK forums are worth reading - http://contractoruk.com Contracting in the UK used to be pretty good. These days things have changed a lot with further IR35 crackdowns. I've investigated this a few times personally over the years and am a permanent employee still. Admittedly a few rungs up the corporate ladder these days, but contracting isn't the gravy train it used to be. Contract is a instant no for me. I've done the math and haven't found them to be competitive long term after what the above commenter mentioned (and that's before all the headaches of actually getting paid). Most of my peers feel the same way. I contracted for 10 years, then switched to a full-time job at a unicorn. Salary-wise, I calculated my yearly netto for the last contracting year, and submitted it to the HR as the netto salary I want to have. They approved in a blink of an eye. The main problem with contracting is lack of career path and random, not very interesting projects where the contractor has little say. The downside of employee life is non-technical meetings, personality trainings and yearly reviews. They make me feel like a kid. I also miss the luxury of buying VAT-free tax-deducible gadgets. > I also miss the luxury of buying VAT-free tax-deducible gadgets. Like what kind of gadgets ? What is personality training? We had a dumbed down MBTI offspring. And a security training. And the bias/unconscious bias/unknown bias training. And a few more that I can not remember. Been contracting for decades. Wouldn't do it any other way. The critical thing is to get a pipeline of folks you know that send work your way. So rarely idle. That was done by working 15 years in the field in a variety of companies. I keep in contact with many old colleagues and remind them I've got bandwidth. I never made more money than I do contracting now. I've never had to 'chase down money' - never had a bad check, never been stiffed. Had some late checks for sure. Probably due to the quality of my contacts. What kind of day rate do you manage to pull? It depends. Some midwestern companies want to pay < $100/hr. Californians will pay up to $145/hr for special skills. New York is accustomed to outrageous fees. I feel bad about taking advantage them so I only go up to $165/hr or so. And of course for assurances about hours and duration of the project, discounts. You cannot put a price on career-long isolation from office politics This is one of my favorite parts about contracting... you still have to deal with a little bit of office politics and drama but you're mostly shielded from it. I love dropping in once a week or so, greasing the relationship wheels, and getting the heck outta there. Instead you have politics at the companies hiring you. Which country? Funny - I’m the opposite. I’d much rather make my great rate doing indie work and helping lots of people versus being stuck in one role with a fixed salary and limited mobility. > To be blunt, it’s more likely that you’re simply not paying enough to be competitive I get a lot of cold emails from recruiters and the jobs always seem to pay the same rate, which is no better than what I make. > The day rates look high, but they have to pay self-employment taxes and health insurance Most SWEs doing 'contract work' aren't actually 1099 contractors, what it means is they work for an intermediary and then 'contracted out' to a big company with a recognizable name (Google/BofA/Verizon/IBM). These jobs are W2 so you don't pay self-employment tax, they usually have mediocre insurance options, and you lose your job as soon as the work dries up. It's simply a way for a company to staff up quickly without going through as strict of hiring committee and having any obligation to keep said staff around if plans change. It's often easier for a department to get a req for a senior/staff contractor (and make salary exceptions) than a FTE, so what happens is departments will offer 200, 250 an hour for temp work but only able to hire engineers for 150k a year because their 'employee' req is slotted lower. I'm with you. As a QlikSense developer, almost all jobs I see are Contract-To-Hire. The rates look good, but they aren't good enough to justify me having to get my own health insurance, nor do I want to risk 6-months of nothing happening for a full-time position I may not want in the end. yes exactly. I did contracting when i was single and young. Contracting requires you to tolerate random loss of income, paying health insurance yourself ( in usa), traveling, unpredictable work schedules. Its impossible to afford health insurance for the family, traveling ect when you have kids. This is currently me. There's no shortage of work and the pay is good but I think I'll need to shift gears to start a family. I don't travel much so that helps but you're spot on about healthcare and the unpredictable nature of this work. > ect It's "etc". Short for "et cetera". https://en.wikipedia.org/wiki/Et_cetera I'm a senior eng out of work for a year (per my own choice) slowly looking to get back into the market. These points are my own: - My managers have always been a point of friction. If you hire an expert, stop telling them what they do and don't know. I'm afraid of full time work because of incompetent managers or tech leads. - I don't care if your company is a unicorn. I care that I'm going to be happy doing the work that I do. - Agile is a time stuck and time waster. Proudly advertising it as your Modus Operandi is a sure way to get your cold-email dumped in the trash. - If you're approaching me claiming you've seen my work, you better not mention a technology I haven't used in a decade. I don't care, personally, if you've done your research on me, but don't act like you have if you haven't. - My #1 priority at this point in my career is being comfortable - in work and out of work. Showing that the company cares about that - work life balance, good pat, etc. - is a little thing but helps a lot in recruiting people like me. - I'm probably not with your product or service's target demographic (yes, even if it's some fancy SaaS). Don't knock me if I'm not. Most senior engineers I know of don't like SaaS products and tend to keep things fairly vanilla to retain control over the system. We're probably not going to use your service in our personal lives, and that's okay. - Working remotely, especially these days, is almost a must. I want to be with family, especially now that we're making some life altering changes to catch up after the pandemic (moving, new jobs, getting married, etc.) - Stop drowning us in processes. The more we have to play around with your gold-plated project management system, the less we're interested in writing code for you. Remember that a lot of us get by with GitHub issues and nothing else. - A lot of us are tired of the industry. Going to be real. If you can figure out that problem, you'll be fighting us off with bats. > incompetent managers or tech leads. This is one of the things that ruined my last gig. I have 3 decades of experience. Managers and tech leads are unlikely to have a fraction of that, so let me do my job. > Agile is a time stuck and time waster This was the other thing. We fell into the hands of Agile cultists (really no other way to portray them) and wound up getting buried in process, useless meetings, etc. > I'm probably not with your product or service's target demographic Same! I've never worked on anything that I would have an interest in using personally. I don't have anything against the products, and they served their target audience well, but that's not me. > Stop drowning us in processes. See above. The so called "Agile" stuff they brought in basically crushed our development staff. It was used as a bludgeon. Describing agile as a cult is spot-on. Regardless of its intent, I've never seen nor heard of it being implemented in a way that promotes iterative R&D on a development team. Agile is more suited toward software maintenance IMO, not building new software. Rarely are senior engineers looking for the former. > Agile is more suited toward software maintenance IMO, not building new software. One other learning that I've taken from big-A Agile is that it is only suited for teams where everybody is a "generalist" within the team. By "generalist" I mean that any developer on the team can work on any issue within that team's purview. If your team is responsible for any component where only a subset of the team has the specialization to work on it, team-wide sprint planning actually hinders progress. In the "agile" environments I've seen, devs are expected to be the ultimate generalist. We have to do planning, documentation, testing, qa, ops, and still write the code. Personally I don't see that as a bad thing. I care more about ownership, I'd much rather be responsible for a project instead of just tickets. That philosophy preaches that any person can fulfill any task equally well, which isn't true. QA and ops are distinct skill sets, very different from what's needed to be a good developer. If I'm doing all that other stuff, when does the code get written? By who? > This was the other thing. We fell into the hands of Agile cultists (really no other way to portray them) and wound up getting buried in process, useless meetings, etc. That's curious since "agile", as the name suggests, should be very lean on the process. There is nothing agile about a lot of process details! Sure, people get too invested and miss the boat, but in general it's not too hard to remind them what "agile" is about (hey, it's in the name!), and in my experience, they usually relent. You've been lucky. I've seen first hand, heard from my peers in other companies, and read throughout the industry, that Agile is probably the most poorly named thing out there. Just because they put it in the name, doesn't make it a lean, lightweight, easy to use process. So in my experience, "Agile" is not in the least bit agile. You’re shooting yourself in the foot by ignoring companies that take pride in offering an agile development environment. There are, sure, places that have control-through-forced-scrum as their management philosophy who will call themselves ‘agile’; but there are also places that practice exactly what you’re looking for: getting out of the way of tech practitioners, giving them direct access to stakeholders to decide how and what to work on, trusting teams to self-organize; and those companies are going to say they are agile too. Consider the alternative: a company whose ad says “we don’t follow any agile practices” - what would you interpret that to mean? That they just let you get on with things your way, or that they are stuck in their requirement-gathering change-control-document waterfall ways? You can choose to interpret anything a job ad says cynically. Just like any company’s claim in a job ad it needs to be evaluated. From my personal experience across multiple jobs: For every company that tries to embody the old Agile Manifesto there are a dozen who've simply plugged The Latest Trendy Management Practice into that module slot and are continuing business as usual. No, thanks. Right, and for every company who advertises ‘competitive compensation’ and means it there are a dozen whose idea of competitive comp is that they’ll match an offer to retain you later. You do need to filter through some BSers to find a good job but that doesn’t mean any company that claims anything good about themselves is lying. Unfortunately it’s become a high-confidence signal that shenanigans will be ongoing. I use this as a signal of avoidance: not interested in your varied way to try and manipulate SWE labor and squeeze another once of productivity out or pass off your debt in the form of my time at the cost of my sanity. I know many others that do the very same. Perhaps it's my loss, it's a risk I'm willing to take due to the number of bad apples associated with such practices. I'm not sure what this kind of cynicism actually gets for you. If you approach any job ad with the assumption that whenever they try to put a positive spin on the working environment they offer, they really mean they'll manipulate your labor to squeeze out productivity at the cost of your sanity... ... why would you work for anyone? You're assuming that agile is a "positive spin on the working environment". In 11 years of professional work, it's only ever been used as a weapon against the development team. Spot on. Often it feels like a cult, but even more often is used as a micromanagement tool. This has nothing to do with agile practices. Micromanagement is micromanagement. The people you are apparently working for and with will micro manage regardless of any process. I also suspect that you do not actually work in a team. You probably work with other people that are loosely grouped together. I doubt you are actually working together on a common goal though, if you do not see value in standups for example. If there's no value in knowing what your team members are working on, you are not working closely together,you aren't helping each other etc. I suspect you have a product owner that sees standup as a progress report to them and that tries to exert their micromanaging power through it. I also suspect that you don't have a Scrum master that protects the team from this rogue product owner. I would take such a PO to the side and explain to him that if he doesn't stop this practice they will soon be disallowed from being in standup and that they have one chance to stay in standup and at least listen. Meaning unless asked a question by a team member they better keep their mouth shut. Am I at least somewhat close? > I doubt you are actually working together on a common goal though, if you do not see value in standups for example. It sounds like you're assuming the only way to sync up with folks is a stand up, which is just ridiculous. I'd even make the argument that if you think you need a stand up so that team members actually communicate with each other then you're not working on an actual team, you're working with other people that are loosely grouped together. Any good team I've ever worked on, people just organically collaborate as needed. You don't have to wait for some arbitrary sync-up time to let each other know what's going on. In general, I'm not necessarily against stand-ups, as long as they're quick and don't turn into status meetings. In my mind, a perfectly reasonable stand up could be "does everyone know what they're doing? Does anyone need help?" and if the answers to those are "yes" and "no" respectively, then we can be on our way. But more often these things turn into minor status report meetings, where everyone starts saying "this is what I did yesterday; this is what I'm doing today..." and often those details are not relevant for everyone on the team and could just as easily be communicated elsewhere in an async fashion. I feel like a lot of things like stand-ups exist for the lowest common denominator teams. Bad teams don't organically communicate, people slack off if you don't micromanage them, etc., and so for those teams you NEED a stand-up. But then it gets forced on everyone and is a drag for high-performing teams, and good people end up leaving because they just don't want to deal with all the BS. So you end up with a self-fulfilling prophecy where what you're mostly left with is bad teams and so it feels like stand-up is necessary or is working. It's kind of maddening. They're putting it in their job ad. It's fair to conclude they think it's a perk. Because you have to? Your other options are to be born wealthy, start an independent business (which also usually requires up front capital), or live out in the wilderness. As the alternative, you try to find positions that don't look like they have a pile of spin buried in them that seem to be hiding something. You look for red flags and then interview the set of employers that is also interested in interviewing you. You can reduce the filter and wait for the interview processes to reduce false positives but from my experience, being cynical is a good filter to save me time from working in toxic positions at toxic companies. After interviewing and working in business environments, you learn more and more of the spin techniques everyone seems to use. It's interesring how being critical of business ads is viewed negatively, yet it's perfectly fine for businesses to have full day interview processes, background checks, resume filters, skill tests, etc. Hiring businesses obviously don't trust you and your advertising, why is it assumed you should trust them? Trust is a two way street and has to be built and business relationships are growing increasing transactional and shorter term which doesn't exactly instill a sense of trust between people. > I'm not sure what this kind of cynicism actually gets for you. Not OP, but cynicism against agile get me (somewhat) avoidance of the most toxic workplaces, which is what agile is. Sure, just as for every company that actually offers competitive payrates there are a dozen who just say they do. But it's not like not caring about management practices magically makes a company good at them either. You wrote almost exactly the same thing as the other person who replied. I have to ask (both you and jameshart): What makes you so defensive of Agile? What benefit have you seen it bring? Truly curious, not trying to bait anybody here. My experience with Agile—except when another engineer and I basically stealthed rapid development into a company with 12-month release cycles in the mid-2000s—has been overwhelmingly negative. 45-minute “standups,” major projects given 3 points, every negative stereotype bandied about on HN is something I’ve experienced. Why do I 'defend' agile? I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed their relationship with business stakeholders by getting the business to buy the underlying truth: building software is a learning exercise; the requirements can and will change. And the frameworks you have to put in place to make that kind of relationship work, to replace the arbitrary deadlines and deathmarches? Turns out 'agile practice' has a bunch of useful ideas for those. Teams have limited capacity for 'work in progress'. The upcoming work can be prioritized on a backlog. Loose sizing estimates can help us make decisions about trading off time and features. You can only have one top priority at a time. It helps to let teams understand what problem they are trying to solve, not just tell them to implement a piece of a solution. That's what I value when I talk about 'agile'. A bunch of useful ideas stolen from scrum and kanban and lean and so on that actually help put developers in a position to solve the right problems in the right way, and get 'management' off their back. I'm also a fan of daily planning meetings to facilitate collaboration inside teams. I like retrospectives as a way to identify ways for teams to improve how they work. I like short fixed-duration iterations which deliver working code. I like pairing on problems. I like continuous integration and deployment and automated tests written alongside the code. Those are good practices that we, as a small team of developers, can use to help one another do good work, and ship working software. And those ideas are all also stolen from things like scrum and XP and TDD and devops, which are also all 'agile' practices. If someone tells me they don't like agile I am confused because... I don't know why you wouldn't want to work on teams that follow those kinds of practices. I do get that plenty of people have been subjected to environments that use things with the same names as these things in ways that aren't remotely agile. But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them is like saying you never want to use a programming language that has strings because PHP's string coercion sucks. I find these practices helpful, and better than not following them. I've been lucky to get to enjoy working in environments that use them, rather than have them badly forced upon me. Thanks for the detailed reply! I have to say, everything you wrote sounds great. We'd probably agree on more than we'd disagree. That said... > But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them It's not that I've been subject to "a bad implementation." It's been multiple, across a decade, ever since Scrum became a thing, really. Disaster after disaster. I'd also add that most of the effective engineering I've seen (aside from the occasional uber-productive solo code artist) had clear priorities, effective intra- and inter-team communication, and certainly a disciplined retrospective process, all without Agile or Scrum. In the best cases it was self-organized, because we wanted to do good things for the sake of doing good things, and management understood we were trying to do the right thing, and got out of our way when we were being effective. When we weren't, it was a conversation, not school-time lockdown. I don't think that environment can be replicated by process or fiat, which is what the formalized Agile/Scrum of today seems to try (leaving aside the more cynical cases). So let me put it this way: Most businesses do not know how to manage software projects. That's not entirely special to software - most businesses don't really know how to manage anything. Agile tools offer a framework for technical teams for fighting off and thwarting crappy management that doesn't understand how to make software. But some crappy management organizations are really, really hard to thwart. Worse, some crappy management organizations have figured out how to neutralize agile tools, by co-opting them and trying to use them to continue crappily managing the software project. Sometimes they do this pre-emptively, neutering one of the only tools a technology organization has to fight back. I would love to know what else people have had success with as a way to fix crappy management other than setting up a properly agile 'safe space' for tech to happen in. This makes sense and puts it in a slightly new light for me—as a way of salvaging some productivity, when run by the developers, Agile/Scrum would certainly be better than many alternatives. I guess that’s what we did in my earlier reference, about 16 years ago. I wish it hadn’t become so coopted by the usual suspects. This reads exactly like someone who's never been on the development-end of an agile team. You could have said you copied this from some promotional material for an Agile consultant and I'd believe it. Really your only argument is "those companies didn't do it right", but the problem is that if agile is so hard to do correctly then doesn't that mean there's a problem with it? Weird, because it was written by someone who's been a working software developer for 20 years and who has so far successfully resisted getting shoved into a hands-off-keyboard management role... Then you've been lucky. Good for you! We’re hiring Contact info? I am a Scrum Master, because I decided that if I can't avoid Agile, at least I might learn to do it properly. So I got some training and read some books. And I was confused, because "this sounds nice, but is totally unlike any Agile I have actually seen as a developer". Then I took my role, and tried to implement the first thing they taught us at the training... but the management said "no". So I tried a different thing... but the management said "no" again. I asked what's the point of sending me to an Agile training if they override all my decisions, and the answer was, more or less, "we are doing Agile this way". My options were limited to do "Agile" their way, or to quit my role and be replaced by someone who will do "Agile" their way. So now we are doing Agile the way everyone hates and everyone does, with me in the role of the bad guy. Except our standups are 5 minutes long, because... that's the only part that remained firmly under my control. Otherwise, everything is the opposite of what the Agile trainings and books said. The management made a big announcement where they congratulated themselves for successfully transforming the company to Agile. From my perspective, this answers the question why "true Agile has never been tried". The people who make the decisions, they want the buzzwords and some of the rituals. They do not really want to give up any of their managing power. To try the Agile as intended... you would probably have to start a cooperative. Or be a very enlightened founder who can resist the temptation to use their power. I've seen Agile be hugely effective when actually done. It results in a much better product that's also more suited to what the customer needs, and therefore much more fulfilling to work on. It cuts through many of the most frustrating and wasteful parts of other kinds of software development at a stroke (e.g. endless architectural arguments). I genuinely think it's the best thing that's happened to my career. So it's frustrating to hear people attack it and especially frustrating when it gets attacked for the opposite of what it actually is. I don't know how to make people stop lying about what they're actually doing (I wish I did), but I don't think it's reasonable to expect any kind of process to work when you do the opposite of what that process actually tells you to do. (And I'm quite prepared to entertain the possibility that an organisation that actually committed to following RUP or Six Sigma or whatever and followed through on it might be better than half-assed non-Agile "Agile". But I haven't found the HN-endorsed "lol no process" to be effective in practice either) Wow, I would love to work somewhere with waterfall requirements-gathering processes and change-control documents. Across several employers, I've seen a lot of misdirected work that just makes future work harder. Now of course the response is, why would I want to put up with that bureaucracy - won't it backfire on me? But it shouldn't be bureaucracy, it should be something driven by the engineers with the goal of shipping better products. Which is the problem with advertising agile. When a company says they follow agile, what they often mean is that there are people whose job it is to make sure the agile process is followed, effectively making their own agile bureaucracy. That's what scares people. I want to know that the company is going to get out of the way of practitioners and let us do big-design-up-front if we in our judgment as practitioners determine that a specific situation calls for it. > You’re shooting yourself in the foot by ignoring companies that take pride in offering an agile development environment. Fine by me. Everything I've seen and heard of Agile (both in the last company I worked at and from others) is that's it's a dumpster fire. It wasn't created by developers to improve development, it was created by consultants to sell consulting. DevOps is dumb, too. > Consider the alternative: a company whose ad says “we don’t follow any agile practices” - what would you interpret that to mean? That they haven't fallen for the hype and do what works for them. As a counter-point, i've seen engineer-led Scrum and other agile varients work very well. Low stress, high productivity, high predictability. YMMV, and sadly the norm tends to be bad practice, but it isn't all like that. Companies with good engineering culture do engineering well. Companies with a poor culture do most things poorly. > Companies with good engineering culture do engineering well. Companies with a poor culture do most things poorly. Very true, but the "good" companies will be good regardless of what methodology they use. And it's rarely a one-size-fits-all approach. They recognize what works and what doesn't, without slavishly adhering to a single doctrine in the face of all evidence. So... when you're looking at a job ad, what words are you looking for that tell you a place has good engineering culture? I'm getting that 'agile' is not one of those words, but what words are? An ad is pretty much useless for that, other than "negative" words (to me) like "scrum", "agile", etc. I'd be looking at the tech stack for things I'm proficient in, or things I'd be interested in learning. Also, WFH is now a critical for me, so it has to be 100% full-time remote work. I'm indifferent to seeing "agile" in a job ad. Getting a job or client is like dating ... you find out what they mean by their bio over a few dates. If I ever accept a client or job, there's always a grace period. I'm so confused by this thread. It's like I've wandered into a conversation where people are saying, "You know, my boss tried to give me cake the other day."
"Cake? Everywhere seems to be doing it nowadays. What I would give to find a place to work where the boss doesn't make you eat cake all day."
"Yeah, cake cake cake, all the time." And I'm like, "Er... cake? The yummy thing that's really nice? Your boss gave you cake? And you didn't like it?" And everybody replies: "No, you idiot, cake! Smelly, hard, poisonous cake, with glass shards in it as usual." I'm standing here, with my slice of yummy cake, thinking... are you the crazy ones, or am I? "You know, cake's meant to be like this: soft, sweet, really tasty?" "Yeah, that's what consultants want you to think, but cake is actually made of burnt tires and crushed up bottles." "Your boss gives you burnt tires and crushed bottles and tells you that's cake?" "Yes, that's what cake IS." And I can point to all the recipe books for cakes, and show you the cake I'm eating right now, and you'll all still tell me: "Well every cake I've ever been given smelled of burning rubber and made my mouth bleed, so I don't want to work anywhere that advertises that they give employees cake any more."
"You sound just like the last guy who gave me cake." I mean, I get why that kind of experience might make you cynical, but I don't understand this desire to wallow in the belief that anyone who tells you it doesn't have to be like that must be lying or selling something. "And chocolate's awful too." Really? The same asshole who has gaslit you about what cake is has lied to you about chocolate too? I'm so sorry for you. Please. Let someone help. Have some cake. > I don't understand this desire to wallow in the belief that anyone who tells you it doesn't have to be like that must be lying or selling something. Because literally every time we've encountered cake it's a painful and disgusting experience. It's more like you've been given something that's been called cake, but is actually not cake. Whoever baked it realized that the recipe for cake could never work, so they changed it into something that would, and told you that was "real" cake. Yes, I believe you have been subjected to that abuse. But... the point of my metaphor is: cake does exist. It's real. You can make your own! The recipes are available! They do work! The fact that people have convinced you that cake doesn't exist is a reflection on them, not on me. You are trying to convince me - a person who is eating a cake right now - that cake is a lie. And for some reason you seem really angry with me about it. Angry? That's an odd assessment. I'm angry at the people that make and sell LieCake, and how they've deluded you into thinking that cake is a sweet, tasty treat. The key point for you to take away, is that it's remarkably hard to make an edible cake. It should be clear that you're in the minority (in this thread) of having received something edible when many others have been given burnt tires and glass. It could also mean that they fall under the other extreme of perpetually outdated over-documentation. IMO the only thing worse than no docs are wrong docs. Would you say that, perhaps, you value working software over comprehensive documentation? I can always read source code. Any programmer worth a damn can. Docs are out of sync with the code the second the code changes in any non-trivial way. However, code always documents how it works (sometimes poorly, of course). The code I write is going to be used for 20-30 years, and then when the platform is replaced I assume someone will read the code to see what they have to do to get the system working on the new platform. I have documentation for end-users and documentation for maintenance / troubleshooters and zoomed out documentation that explains the problems and approaches taken, and sometimes justifying any tradeoffs. If code is temporary then it might not be worth the effort to document, but my documentation is what everybody except one person 20 years from now sees along with the user interface, so for my application the code doesn’t matter and the documentation matters quite a bit! I was more referring to how the code works and development practices/codebase layout/etc, not end-user documentation. I'll take that as a yes. So I wonder how you feel about: Individuals and interactions VS processes and tools Customer collaboration VS contract negotiation Responding to change VS following a plan They're all important. I don't really see the point in chosing one or the other. You have to pick one or the other when choosing your development strategy. If you focus on customer collaboration, you could end up giving away too many freebee features that should have been feature requests and billed. If you have a design iteration plan, how do you respond to a showstopper that makes the plan infeasible if you are on a strictly waterfall design plan? Each has it's trade offs so you can't always pick one or the other willy-nilly or else you don't have a design strategy at all I get a lot less grief from the people who pay the bills this way. You're hired! I disagree. The only shooting-myself-in-the-foot I've done is to accept positions at companies with agile. It just doesn't work. "self-organize" - oh, sooner or later you're in for a treat. Agile coach: "Everybody go to the meeting room, you're going to self-organize. This is how you're going to do it...". I've not yet met an agile coach with the intelligence to parse what they're regurgitating. The only time I've seen agile work was pre-Agile when it had nothing to do with Agile. Then you've been with the wrong ones. Here's what my favourite agile coach does first thing in his courses. I've seen him consistently do this over many many times I've seen/participated in his courses: He runs a self organization exercise! You laugh now because you imagine it the way you described it. Well actually the first thing he does is to appoint someone as 'the worst micro manager in the world' and asks them to sort participant's by number of years of experience with agile development. He times this with a stop watch. When that's done he simply states that he wants participants to self organize standing next to each other sorted from one end to the other by number of years of experience in software development now. He then stands somewhere in the middle of the room himself and just starts repeating over and over "21 years, 21 years, 21 years,..." Usually it takes a little while for people to 'get' what he's doing but he stoically just repeats his 2 words. This is timed too of course. It's interesting how much less organized the second round seems when you are in the room watching this. But it's so much faster and gets the point across brilliantly if you ask me. If they're really interested in talking about how agile they are, the signal to me is that this is a management-run company, not an engineer-run company. Plenty of engineer-run shops are lowercase a agile, but it's not something they bring up constantly. > getting out of the way of tech practitioners Agile is the literal exact opposite of "getting out of the way of tech practitioners". I once worked at a place on the opposite side of the "process" spectrum: No source control No bug tracker No formal QA No versioning or release process. When a customer needed a build they just took whatever happened to be on the lead developer's PC at the time. No roadmap planning process. The CEO would walk into your office and spout off about some idea for the product, and that's what you'd be working on next. And I can assure you the did not do agile or scrum. Wasn't a really great place to work. Very chaotic and everything was a fire to put out. Lots of turnover and burnout too. Would not recommend. There's a sweet spot in the middle of the 'process' spectrum. I interned in the software process group for a defense company building sattelites. It had the other extreme of the process spectrum- true waterfall/CMMI processes in place, but they were so painful that people just did work and then figured out how to claim they followed the process afterwards.
They actually had a couple good processes that I walked away with (different levels of formality for code reviews, structured and a risk based QA processes), but overall it was about frustration and a molasses like movement. I was glad to end up on consumer software for a while after college. > Stop drowning us in processes. The more we have to play around with your gold-plated project management system, the less we're interested in writing code for you. Remember that a lot of us get by with GitHub issues and nothing else. OTOH, there are groups that don't have their shit together. I fought tooth and nail to try to get continuous integration up and running at the last project I worked on, and it was just so fucking frustrating trying to get people to change. They recognized the need and the benefit, but wouldn't take any action to actually implement it. And now they're actually looking to abandon Gitlab "because it corrupted one of the repositories." They're going to go to a direct git repo and someone proposed building their own CI from scratch out of cronjobs and such. > Agile is a time stuck and time waster How do you prefer to organize larger software development efforts that have to be coordinated with other business processes? Anything that treats software development as an iterative research and development process, lets engineers self-organize, respects their time, and respects that time estimate certainty is asymptotic with respect to the time horizon. I’m sure I read something similar in some sort of manifesto... And many companies filled with employees with "Agile" in their job title have probably never read it. Sure, but the top-level comment’s stated point wasn’t that, but rather that Agile is a waste of time, period. So I’m curious what other ways of working handle these kinds of projects better. Edit: This is a genuine question, I'd be very keen to hear concrete ideas on how to work better. Identify the problems first. Everyone is searching for a solution when half the time they don't even know what the problems are. Sure, releases might be slow. Why, though? Is it because you're not letting your engineers fix broken windows? How long does it take for PRs to get reviewed? If a long time, why? Do your engineers even know how to make proper commits? Are your PRs more than about 100 changes on average? Are you building your product from a prototype a non-programmer made? etc. There is no silver bullet, period. Searching for one indicates you're looking for workarounds to fundamental issues on your team. I wonder if this is just a matter of having a very different frame of reference. Before agile became widespread, when someone said "We have a problem with slow releases" they meant "we schedule each release 18 months out and yet it always ships 6 to 12 months late." Now that agile practices are widespread in the industry, when someone says "we have a problem with slow releases" they often mean something like "sometimes the time from code change to it being in live in prod is more than a couple of days," or maybe "the CD job sometimes takes more than 20 minutes to push things to production." The problems you are describing above are problems that can only exist because of agile adoption. (kids today, get off my lawn, etc. etc.) Your biggest problem is that you have to wait a couple of days to get your PR reviewed? Before agile, replace that with
'you have to wait two weeks for your change to get integrated into the build then another week to get an incomplete bug report from the QA team'. And what's more, agile introduced the industry to tools for systematically, continuously identifying problems like 'the releases are slow' and letting the development teams themselves change the way they work to eliminate issues like 'we're not getting time to fix broken windows' or 'it takes us too long to review PRs'. My understanding of 'we're agile' is precisely 'we give teams space to change the way they work to eliminate things that cause them problems'. If someone tells me they reject agility, I would interpret that as them saying 'we don't let you change the way you do things', and 'you will be dependent on other teams who don't share your goals which will slow you down'. I think we're in violent agreement about what good software development practice looks like. I just can't believe how badly the word 'agile' has been warped to the point where people actively think it creates the very situations it set out to resolve. > asymptotic with respect to the time horizon. I don't get what you're trying to say here. If I understood correctly, if I estimate something will take 5 minutes, and I'm doing it now, it'll probably take 5 minutes. If my estimate is 18 months and we don't start for another year, my estimate is worthless. Ah, makes perfect sense. My brain was glitching a bit trying to make sense of it as "Anything that [...] is asymptotic with respect to the time horizon" If Agile doesn’t achieve those things, which it explicitly is meant to do, are you familiar with any other methodology or set of guidelines that does? Big-A Agile and Scrum don't do such a great job, but the principles of agility do. There's a book called Accelerate that describes and prescribes proven values and techniques that promote agility. Also, Don Reinertsen is awesome - check out his books on running a software organization based on lean principles. There are great companies out there who not only are remote first but also works distributed and async, like github and gitlab. Per your point about managers there is also the concept of "Manager of one" for being own manager in these companies. I don't know your context, but here are some thoughts on what I've seen/experienced: Allow remote work -- European rates are much lower than Silicon Valley rates even now, and I imagine the same might be true for other parts of the world. Flexible working hours -- as a parent with kids, my current contracting arrangement for about 25 hours per week works quite well, and it's unattractive to me to return to a regular 40-hours (let alone 50-60 hours). Paid time off -- I believe in the US it is still common for people to only get like 2-3 weeks off, or get "unlimited time off" deals that, apparently, often come down to the same thing because of social pressure. For comparison, here in the Netherlands, 5 weeks is table stakes, and I take at least 6. Interesting tech stack -- in the Rust world that I participate in, there is a lot of discussion about the lack of jobs (especially outside the blockchain industry), so if you can offer something that is more novel, that might help. All of this assumes that you can't easily change your organization's mission or product, which of course might be another way to attract folks. Denmark: less than 5 weeks holiday per year is simply not legal. Doesn't matter if you're just been hired. Doesn't matter if you work part time. > Interesting tech stack -- in the Rust world that I participate in, there is a lot of discussion about the lack of jobs (especially outside the blockchain industry), so if you can offer something that is more novel, that might help. I've been trying to escape the C++ world, despite my mastery, and get into Common Lisp. I would honestly take a pay cut to work on only Common Lisp code. companies in the US want people to be "local", that is why people from europe still move to the US. I switched from consulting to a company. In short contracting is a headache if what you care about is doing good tech work. Rates in the contract world represent a lot of overhead and headaches you experience there: 1. Payment risk: chances someone doesn’t pay you is surprisingly high. A lot of time is just spent chasing down your money. 2. Poor payment terms: being able to bill after 30 days of work is actually seen as generous. More and more you see 45, 60 or even 90 day terms. And clients are always playing dumb cash flow games 3. Invoicing and tracking time is not fun: There’s a lot of overhead following some clients invoicing rules and time tracking. Then you can get questioned non stop about why you spent hours on this or that. 4. Employer tax: in the US if you’re self employed you pay the employers share of Medicare and social security. 5. Health insurance: in the US you need to purchase your own private health care. This can be quite a lot if you have a family. I know outside the US, in some places, private health insurance can also be needed for other reasons. 6. Sales and marketing overhead: the work to attract clients and close deals is pretty substantial and out of your pocket. 7. Relationship work: you are always paranoid about the relationship with the client. You’re first to go if money gets tight for them. And often clients don’t communicate their grievances with vendors, they just fire them. The trust building to get good feedback is very substantial. 8. Project management: in my experience clients aren’t good at managing contractors work. You have to take a bunch of this work on yourself to help organize the work and show transparently what’s getting done. If you have any subcontractors or work on a larger team, this gets substantial and clients don’t always understand why you bill for it (though we always did). I put 'payment due on receipt of invoice' right on the invoice. That's worked for me even at large companies with policies of net-30, net-60 or even net-90. I submit; the payment shows up in a week or so. Another way: give a 2% discount for payment within 30 days. Haven't met an accountant that passes up a discount. I think this works for a small company, but large companies, that outsource their payment team, they probably don't care... They usually don't want to deal with anything weird from a vendor, or if they do, they'll screw something up with payment. Sometimes they really don't care. My favourite is a corp which always pays on the last possible date - they managed to miscalculate holidays one day and get one of their large office buildings disconnected from the grid for non-payment - possibly offsetting all the money they gained on delays with that lost productivity. Big companies too. Its all down to whomever enters the invoice in their payment system. That's one person, never mind the size of the company. In my experience, there are a couple of scenarios where there is payment risk. With very small clients, sometimes they will decide to pivot and not want to pay for work that they're not going to use, or the project is completed and they decide that they can save money by not paying the last couple of invoices. With larger clients, you start to deal with the finance department and these guys have no stake in keeping contractors happy and just want to keep a big balance in their bank account for as long as possible. The larger the organization, the less influence the person who hired you has over the finance department, and the more disconnected the finance department becomes from the negative consequences of paying late. A few tips that have helped me: (In about 20 years of contracting/consulting, I haven't had to write off an invoice so far. I have given a discount to get paid once, and had to chase down payment a few times) 1. Maintain a good relationship with the person at the company responsible for the contract. If they like you personally and you've done good work for them, they can work the problem from inside the company and will be motivated to do so. 2. Include an IP clause in your contract where you retain IP to the work product and it automatically transfers upon full payment. If they aren't paying and are using unpaid IP that you developed, there are often some big sticks you can hit them with or threaten to hit them with if they aren't paying. 3. Make your opening offer on terms be 15 days, but be willing to give 30. If they insist on longer terms and won't budge, this is a red flag for problems later. Insist on an appropriately sized retainer based on anticipated billing to limit your exposure to 30 days after invoice. For example, if they insist on 60 days, get a retainer of 30 days anticipated billing. Often when you demand this, the contract people will circle back with the finance people and give you 30 day terms. 4. If you have subcontractors, pay them within 1-2 days of receiving their invoice. With interest rates at near zero, the value you get from delaying payment is minuscule, but paying early generates huge goodwill. How on earth do they justify anything except next-day payment? If they can't pay a few thousand dollars what is going on with their cashflow? They have their own lame, internal excuses. Often you're dealing with payment from a completely different procurement dept than the group you're delivering services to. So you often have to work your relationships in the project team to nag a completely different part of a company to get you paid. It's a nightmare at large companies. I had one large client that decided "we aren't going to pay bills in Dec". I'm pretty sure it had to do with the CFO playing cashflow games at the end of the year so their numbers looked good. So all vendors got dicked over... Of course if you're a giant firm, you can ride the cashflow waves. Or if you play golf with the CEO, you can put pressure to get payment. But if you're a small firm or a freelancer, the project team you work with can't really change much about what's happening. Also, net-60+ clients have a pretty "bad smell" because you know they set that up so they can play cashflow games to make their books look good. Once a company hires a certain kind of financial specialist, they delay payments just because that’s one of the few levers they have to change how the company performs and they feel they need to do something beyond keeping things working smoothly. Just like some HR specialists make rules just because they can, or some designers compulsively adjust the brand. It’s hard for people to competently maintain status quo and feel comfortable in their jobs. In case it needs to be said, yes, there are times when cashflow is dire, employee policies are a mess and the logo looks bad. It's not justified; it's just something they want. If somebody offered me a 0% interest no-strings-attached loan for a couple months I'd probably take it too. Cash flow games can allow a growing business to take a loss on every transaction indefinitely. It's a powerful tool -- ideally to build a legitimate business that requires at least some economies of scale. They have their routines for paying bills and services, it would be very inconvenient to pay ad hoc. And I’ve never even heard of next day payment, except maybe for manual labour. > They have their routines for paying bills and services, it would be very inconvenient to pay ad hoc. But why? A bank transfer is fast and trivial to do. Where's the inconvenience? I presume the actual administration work of checking they had money in a budget to pay for the work happened when the work was contracted not at the end. >But why? Two reasons. The most important reason is if you keep the money for 30/60/90 days, it's like a interest-free loan for the company. The stronger your position is, the longer you can hold on to the money (see walmart). It's how virtually everyone does it. Second reason, "A bank transfer is fast and trivial to do" - I'm guessing you've never done work for or been around a large enterprise or you would not be saying that. Usually it's something like "The spending committee has to approve, then Richard in accounts receivable is the only one who can sign off on the check and he's on vacation til June/" No, it’s more about efficiency. If they would pay bills ad hoc they would have to do it every day, instead of settling everything once a month. Just like most people don’t go to the grocery store for individual items, they go once a week or so. I work at a big 4 (not tech, consulting/accounting) company as a contractor. They recently offered me a FTE role. $40k less pay for 10-20 hours more a week; meaning they expect their FTEs to work 50-60 hours a week for 4/5 of what they'd pay contractors to only work 40. The work is interesting, I love my team and such, but cannot and will not give up 10-20 more hours to what amounts to just another job. There's no incentive to convert, no justification to work 2500 hours a year for some lousy bonus. Atleast I get to keep my contract, keep billing my rate and only work about 1960 hours this next year. I'd say until companies get realastic about hours, expectations and salary it's going to be difficult for them to convert people. I mean, your company makes lets say $100,000,000 in profit this year with what a 50% margin; probably higher with software. You can pay the contractor $200-$250 k this year, but only your staff $160k, or $190k once benefits and all that get factored in. Really? You can only pay $160k for perm and $200k for contractor? ?!? You're a team of like 30, making like $100m ... So if you'd like a Snr Eng here's what I'd do: 1. Work life balance. Make it so I can do my job in 40 or less 2. Don't take advantage of me 3. Don't make false promises 4. Pay me really well 5. Give me generous time off and benefits 6. Let me work when and where I want 7. Don't ask me to believe in the culture, or give a shit about the mission. I'm not here for the mission. I'm here to do my 40, make a lot of money and enjoy my time outside of my job. An employee at 160k costs a lot more than 190k - you can multiply by 2-3 to get the actual cost. BTW at bleeding edge R&D labs the OH rate can be 500 -600% Where on earth do you get the 2x-3x? Industry average mark up for recruiting companies is 30% to cover employee costs with w2 contractors. Who ? you mean the ghastly rip off body shops? I think you may have misunderstood what we are talking about real self-employed contractors vs FTE's The 2-3x salary is the actual cost to an employer of a FTE (full time employee). Where do you get 2x-3x? 3x sounds about right for France, but that's an outlier.
The multiplicative factor in the US is more like 1.25x AFAIK. I wish this was the top comment. 1000% love this post, totally agree ...
what did you tell them when they made you the FTE offer? Well, I knew there was a reorg, asked for the conversion and they made the offer. After talking to a fair number of people, I realized that they want 20-50% more time in trade for less money but they say you can only get fired twice a year.... Welp, I told them that the hours were insane and with my clinical depression; I'm going to hate my life if I work that much. So they were pretty understanding after that. Got it. So it seems they really could not afford to let you go as a contractor, even if you had said "not interested in becoming a FTE" ? As someone who spent years contracting, realize that for the most part you're not competing on price. You're competing on value. Day rates aren't usually higher than the fully loaded cost of an employee - but they are higher than the salaried cost. The flip side is that many people (myself included) frankly were tired of the abuse of full time, and not valuing our time. Contracting eliminated all of that - it was pay to play. You'd be shocked how the second you become a contractor (in the right org) you're actually doing significantly more of the work you were hired to do - whether that's coding, architecture, or stitching. But these come to mind immediately. 1. Provide interesting problems that need solving. Be specific about them. 2. Ship; one thing I've noticed repeatedly is that many organizations are "allergic to shipping". 3. Go global. There's a massive talent pool, and many people are more than happy to work 'perm' from not your location. Don't make the mistake in thinking that a permanent employee is more engaged than a contractor. A professional is a professional regardless of contract type. >Provide interesting problems that need solving. Be specific about them. Something I am starting to realize is that frequently I am pitched some hot project during interviews or quickly after joining, but the projects _never_ pan out. Not that the projects get tried out then killed. The projects just never materialize. I was at one place and they had promised me essentially principal engineer, help us overhaul our stuff, we're fucked kind of role. After a year, I was on a once a month QA rotation and when I wasn't, I was writing Cypress tests and never shipping anything due to the enormous tech debt leadership had no interest in fixing. Full time work just doesn’t offer a competitive amount of holiday. I can contract 2/3 to 3/4 of the year and take the rest off to travel, work on my own projects, meet friends etc. The money works out about the same but 25 days leave (or whatever the standard amount is) just doesn’t cut it for me. The older I get, the more I value time over money. This is, by far, my biggest motivator. Being able to plan financially for adequate time off. Also the flexibility of doing so: if I need to take tomorrow off, I'll just let the client know I'll be unavailable for the day, and not charge for it. If they really need my work to be done that day, I can offer a substitute, charge the client, and pay the substitute. > The older I get, the more I value time over money. This! When I have enough money to take a year (or more!) leave without pay, but you say "sorry, you've used up your annual leave", the only option I'm left with is quit. And when it comes time again to get another job, that company that wouldn't give me more time off is not going to be my first choice. Exactly. However generous the holiday allowance, it's never enough, because it's on the company's terms. Everyone is well aware that any promise of company loyalty isn't worth the time it takes to say it. To attract in-demand employees, you have to make every week count for them so if there is an acquisition or yet another useless management shuffle, they can walk away without regretting the time they invested. The easiest way to achieve this is to offer some amount of equity and/or the exact weekly schedule and vacation time they are looking for. The most excited I have seen engineers get is when I tell them my primary goal is to keep them out of meetings, away from process rabbit holes, and focused on programming and documentation. We have one weekly 30 minute meeting limited to the product team, and ad-hoc stand-ups if we are picking a long term path that affects the whole team. The acronym KPI is never mentioned. Our only measure of success is deployed features. The toughest part here is usually dealing with management who think you can't get anything done in 25-30 hours, or that having "face time" is worth sucking 10 hours out of someone's life every week with a commute. Or even worse, they have mandatory "all hands" meetings or "team building exercises" as if their employees are children. (To anyone offended by that, try building a team of adults through hard work instead of the equivalent of circle time.) They cannot comprehend that a focused 5-6 hours a day is much more productive than trying to enforce 8x40x50 and pretending that every hour is similarly productive. "Everyone is well aware that any promise of company loyalty isn't worth the time it takes to say it." 100% I was hired by a company that said they don't outsource, they don't lay off employees, and that the pay structure was good (3 10% promotions and a 4th larger one if going into management, plus a $25k-ish profit sharing bonus). Within 2-3 years, they started outsourcing, the promotions turned into 7% raises with the need to get 5 of them to be making near the same amount when considering the change to profit sharing. The chance to go into management and get that money was greatly reduced, requiring you to work both as a PM and a manager with pay being about the same as the PM role. Within 6 years they started laying people/groups off. This is a company that has a high reputation for doing the right thing, marketed themselves as different, etc. Yet I have seen the erosion of pay and benefits, violation of their own policies, and all while trying to sell it to you as some great benefit. PART-TIME and REMOTE are the keywords you are looking for. Also, stay away from Agile/SCRUM bullshit. I personally stay away from companies who have "Agile Coaches" or "SCRUM Masters". From what I've seen there are about four kinds of approaches to Agile, in the wild: 1) "We love agile! We have coaches and everything!" (terrible) 2) "We're agile-ish." (we have performative, hellish standups that are mostly about micromanagement, in which we all get to nervously try to justify our continued employment every day by acting out little one-man plays about how hard yesterday was while going into way too much detail) 3) A range of noncommittal responses that may look a lot like 2 in some cases (often really good, but it's hard to distinguish from #2) 4) "We love agile!" (they actually do, and they actually do adjust processes and add/remove/modify "ceremonies" pretty quickly when the team asks for it; this can be good) The trouble is it's really hard to tell which you're dealing with (aside from maybe #1, though that can be hard to distinguish from #4 unless they really do start laying out all the dedicated "agile roles" they have, then you can tell it's probably #1). At this point I'd probably insist on sitting in for a couple "agile ceremonies" before I said yes to a place that "does agile". It's bad more often than not, but can be anywhere from OK to good. When it's bad, though, it's really bad. I'm not sure how to tell which it is without observing what they actually do. YES. Part-time jobs are getting more popular. Some people are looking for works that give them more free time. Look at GumRoad which offers part-time jobs with competitive salary ($100 - $150 per hour). Wow that is good Technical recruiter here. For okay-paid fulltime roles, you won't never attract people who are after the money.
These people will always prefer juicy contracting rates to your small company salary. You have to try to find people who care less about money and more about other perks like remote work, interesting tasks, a strong technical team, meaningful mission etc. In Switzerland, which is my market, freelancers aren't liked at all. Someone who freelanced for too long will have a hard time getting a full-time job; people think former freelancers won't ever be loyal and leave once there is a better opportunity. (As with every prejudice, there is some truth to that.) > people think former freelancers won't ever be loyal and leave once there is a better opportunity. I think that's ironic. The entire software development industry in the US is based around retaining full-time employees for stints of 18-24 months. I remember being lectured that no one wants to hire me because "I'm just waiting for retirement," and "won't be loyal." Yet they don't have an issue with hiring someone that plans to use their gig as a stepping stone, and will leave behind a steaming pile of spaghetti code that they never had any intentions of maintaining. There's a real good chance that offering senior developers stability and consistency will be valuable. I ran a C++ shop, staffed by pretty high-functioning senior developers, for a long time. When we finally rolled up the department, the engineer with the least seniority had a decade. >>people think former freelancers won't ever be loyal and leave once there is a better opportunity That is just common sense, surely? Companies don't hesitate to get rid of people they don't need. Why shouldn't employees leave for better roles? As they say in boxing, if you want loyalty, get a dog. employees can leave any time they want as well.
as a recruiter, don't try to convince people to join the company based on "cool tech" or "culture".
just pay people really well, it's as simple as that. In Germany, I've heard if you stay on the same job for more than a couple of years, people think you're not good enough to chase for next/better opportunities :) maybe in Berlin Try not to compete with FAANG. Don't make the interview process stressful. Allow people to work from anywhere. Allow flexible work and fully remote working. 4 day work weeks. Lots of things that can be done to entice the right people. Upvote for mentioning a 4 day week - couldn't agree more It amazes me more companies don't offer this benefit (even for 20% salary cut) so much so that I just launched this: https://4dayweek.io/ Offer a 4 day week. I've been searching for a role which fits this description since I left Uni and I finally found one It amazes me that more companies don't offer this benefit (even for a 20% cut in salary!) when the demand is so high It annoyed me so much I decided to make a website listing Software jobs with a better work / life balance: your site doesn't load in firefox on debian buster Damn, thanks for letting me know... will look into it. Any error message? I just see the home page briefly and then it refreshes and i see just white space. Maybe some javascript / redirect crap? Ah that sucks. I just downloaded Firefox for mac and it loads ok, must be a Debian issue, will need to try and get a Debian boot to fix, damn version is 68.7.0esr (64-bit) - firefox quantum Totally unrelated but why are you 20 versions behind? Is there some specific use case or just can’t upgrade for whatever reason? FF 88.0 64bit Manjaro here, loads fine. Just as another Linux datapoint. Full time remote work. It shouldn't be required but it should be allowed. I don't have sympathy for companies who cant find good help because they want to limit themselves to developers in a 50 mile radius. Better conditions. - 100% remote so you can hire people of areas with lower life cost - part-time, maybe you cannot match the FAANG's salaries for full time but you can pay better for part-time - exciting product/tech The 100% remote part is questionable. IMHO people should be given offices to come when they want to, especially senior engineers. Everyone is different. Senior engineers tend not to be young and usually have families and want to live in cheaper areas/countries. Of course it's subjective, but I'd wager more senior engineers would want remote work. Senior here. I prefer remote, but comp has to be enough for me to rent a bigger place isolated from kids, or straight up a nearby office. One reason for a senior engineer to move to consulting is that they are tired of being forced to prove that they know how to program every time they switch jobs. Companies are far too risk averse when hiring, and the amount of hoops you have to jump through is getting more onerous every year. I'm currently a full-time employee, but I've consulted for about a decade in total. Convincing someone to pay you 2 weeks up front for a contract is significantly less hassle than convincing someone to hire you full-time at a software company. Yeah I really don't get this. I know, depending on the country the barrier for hiring is higher, still, you do have an experience period where you can assess the abilities of the candidate. Maybe that's the real advantage of contracting, not having to do a dog-and-pony show every time? Not sure this is true: "Companies are far too risk averse when hiring". The cost of hiring the wrong person is pretty high, doubly so in countries where it's hard to let them go later. The cost of hiring the wrong person and letting them go because they can’t program in the US is very low compared to the price of running a SV style hiring pipeline. And in other countries where it’s harder to fire people, there is a almost always a probationary period were most protections don’t apply. I started a contract job three months ago, with the mutual intention that it will convert to a full-time job. I stayed at my previous job for nine years. In general, I prefer to stay in a job a long time, 5+ years. We (my employer and I) chose to contract for risk management. I demanded a generous salary, and they wanted to test drive me. I was also very nervous about situations that lead to poor working conditions. Specifically, what kept me in my old job so long was that, when there was a problem with working conditions, we usually resolved it. It wasn't perfect, but it was "good enough." When we had a tech stack that was difficult to work with, we refactored. Troublesome co-workers were given severance. Poor managers were shuffled out. Pay eventually got high. Poor processes were improved. (See last paragraph.) When my manager tried to push me to become a manager, we realized that I was better as a lead engineer. In my current job, I was afraid that I'd show up and the stack would be impossible to work with. (Turns out that is true, the stack is impossible to work with.) But what's going to make me stay is that I'm allowed to refactor the stack to make it workable. (I also have the freedom to fix the 4000 compiler warnings.) I'll probably convert to a permanent employee. (Note regarding processes:) Good processes are what make or break a company. When people complain about process; either they are unable to fix their processes, or they just don't want to do their job. The biggest factor in my eventual success in my old job was, ironically, getting a manager who backed good process. Initially, we had a lot of problems with poorly-written bugs and support tickets. It required a good manager to push back on the organization to make sure that, once bugs and support escalations made it to me, the tickets were in a state where I could take them. (IE, we didn't tolerate the "duuuhhh, there's a bug" tickets without steps to reproduce, or the "duuuuh, the customer has a problem, what do I do" tickets without preliminary research.) I've been exclusively contract my entire (15 year+) career. Contractors tend to be money oriented. The simple answer is, pay more. As a Senior/Lead software engineer, I get paid more contract, for the same work and there's no shortage of it. That's the market reality (in the UK at least). If a perm position matched what I was making as a contractor, I'd consider it. The hit to the wallet is too great to consider anything else. If I went perm i'd be looking at a 50% pay decrease after taxes in real-terms. In Canada, there's a large gap between full-time and contract rates but it's nothing new - it's been that way for at least 15 years. Companies here address the gap through other forms of compensation like discretionary bonuses, more annual leave, employee stock purchase programs, RRSP contribution matching etc. “Pay them more” is the answer to solving any job market shortage ever. There. You’re welcome. Offer some form of training and development, which has often been woeful at some places I've worked and the opportunity to progress within the organisation. This would appeal to the kind of people that seek permanent employment. Offer good holiday allowance and flexible working hours and location. I've recently moved from contract to perm (UK). I accepted because with the holiday, pension and better job security I gained I could take a small loss in salary. There are many things, but start with the basics: 1st) Tell the salary upfront; 2nd) tell the interview process (luckily it's non-bullshit and not too long). AFAICT there are many permanent senior engineers that are happy in their jobs and couldn't care less about yet another job offer without salary info because it may seem like yet another clueless recruiter wants to lowball them and waste their time. And going through excruciating process to get 5% more is also not something that many people will do. But your offer might actually be better than what they expect, and it's a good starting point. Also, senior engineers might actually care more about work life balance and stability than crazy high contracting rates. (Of course depends on the person). Start by not calling them Snr Engs. That makes it sound like you don't value them and view them as a comodity that you can't be arsed to write out completely. Not to mention, it won't come up in a search when active, motivated candidates are looking for new opportunities. This is not just a nitpick. If someone emailed me looking for a "Snr Eng", the email is getting deleted and flagged as spam. I get your point but to be fair to the poster, there's a character limit on HN. Can you expand on this advice a bit as it is confusing? I was under the impression that Junior and Senior Engineer was pretty ubiquities terminology for the industry. Sure, if you want to hire a Senior Engineer, write "Senior Engineer", don't abbreviate it as "Snr Eng", because that will raise red flags for any senior engineer. Most of us get hundreds of messages a month from recruiters on LinkedIn, and we're quickly filtering out the ones that look like a lazy recruiter just spamming people. OP here. There is a character limit on the title. Ah yeah, don't do this either :P (EDIT: parent has edited their comment) Indeed, that's another red flag. Fair enough. Though "Ask HN: How to attract Sr. Engineers when the contract market is so lucrative?" fits. Senior/lead SRE contractor here from the Netherlands, I can share my own motivation switching to a perm job: VISA. I'm planning to move to Canada with my family and for the right company I'm willing to go back to perm. Offering part-time, remote, extra vacation, bonuses also won't hurt. What might attract me, as a contractor who is considering going perm in a new country - Maybe something to do with stock/shares which become available over time, if that's something you can do. Remote working, some flexibility in working patterns, a good amount of leave each year (30 days is good) - be a good company to work for, which is friendly to family and other non-work needs and sensitive to the balance. A reasonable amount of freedom and influence on the tech stack always helps engineer satisfaction, though the senior engineer you're looking for will likely want to keep things simple rather than chasing every new framework or language. If you're specifically trying to attract people away from contracting then something I hear a lot from my contractor friends (and something that is important to me too) - try to cut out the corporate crap. I don't want to write an annual plan detailing my aims and commitments to the company. I don't want to buy into your corporate vision. I want to do good work and deliver what you need, but I don't want to spend half my life in pointless conversation with managers. some slightly different things than i'm seeing in most of the other comments: * respect during the interview process. i've had interviewers repeatedly fail to answer/make calls for initial phone interviews, send emails about rescheduling a 9AM interview at 6AM, demand i sign NDAs during the interview, lie about what the interview process will consist of. * comparable coworkers. if you're going to hire me as an X level engineer, every other X level engineer i meet had better come across as being on my level. don't call everyone a senior engineer when some folks are unqualified to operate a text editor. it shows that management doesn't know who is competent and who isn't, which has bad implications for raises and work assignment. Have a really bold mission and focus on autonomy and culture. Senior developers can work anywhere they want. Don’t make the job description about what they will do, but about the impact that will have. We are hiring Staff and Sr. Engineers at ClearAngel and it’s easier because our mission is so clear and empowering: build the YC 99% of online founders. The work we are doing will have ripple effects through the economy and through the lives of hundreds of founders. I spend 90% of the interview talking about that and asking them about what they want. Then I spend 10 mins on: oh yeah, we use Rails and Python, monolith moving to micro services etc. Focus on the mission and the culture you will be bringing them into. Oh and pay them top of market salary and give them meaningful options. I don't care about the impact I will have, but I do care about what I will be doing day to day and who I will work with, and most of all, I care about being paid really well. Not because of greed but because tech metros are extremely expensive places to live, and because I want a return on my investment of years of studying, learning and sacrificing a lot of my spare time, which is something people in other professions rarely have to do. Lots and lots of equity. For the most part, money talks. But it doesn't have to be guaranteed cash. You can offer a risky gamble instead. FAANG pays $1000, but instead you can offer a coin flip for $2200, or a snake-eyes dice-roll for $50k or something like that instead. People will tell you all kinds of other things that simply do not matter as much for people who are not already wealthy. Good team, nice people, important mission, free lunch massages, etc. But give a person the choice between all those things and an extra $100k income, and I'm pretty sure you can guess what they'll choose. At least most people. > But give a person the choice between all those things and an extra $100k income, and I'm pretty sure you can guess what they'll choose. At least most people. i suppose "most" can mean a range of things. but i think that if money was even top 3 for somebody, we'd see them studying for FAANG interviews continuously, and applying over and over. in all my years i've run into maybe one person who behaved like that. maybe that's more common behavior than i realize? (google is the only one of them that's had a real presence in my area for >10 years.) it's important! and i think management definitely likes to underestimate the importance, but it seems to be balanced with a selection of other interests. many of which management could provide for ~$0 or <$0, so they're worth mentioning in (what i feel is) the context of this Ask HN. I think the norm now is that most people continuously study for leetcode / FAANG interviews, and the problem is that a lot of companies (maybe more than 80% ???) have taken over this ridiculous interview process now. It's infuriating and insulting, and it needs to stop. Make a company that does not suck to work for. A lot of companies talk big about wanting to make their company "a great place to work". They talk about benefits, about inclusion, about a lot of ancillary things other than the work. But when you start working on work, you find out there's a hornet's nest of beaurocracy, of office politics, departments run by finance rather than commitment to executing business needs effectively, lack of training, lack of industry standards, a sprawl of independent redundant silos, and a lot of people who seem to have no idea what the hell is going on. And of course they'll put you on-call 24/7 and force you to work overtime to meet unrealistic deadlines, without extra pay. Most companies I've worked for, all of the engineers have known how shitty things are, and they've known how to fix
it all. They tell their line-managers, and the line managers tell the middle managers, and the middle managers don't tell the executives. Everything stays shitty because the engineers are the ones who have to deal with the shit and can't do anything about it. A contractor only has to deal with that shit in small bursts and can produce good work that somebody else can deal with actually running. It's the best way to avoid the long-term nightmare of working in shitty permanent roles. And the pay is better. And you can take a vacation! Over three decades in this business, done a lot of contract work (outside the US), currently FTE at a US company. Other than all the micro-annoyances that a lot of my fellow posters already mentioned and the general "we own your behind" attitude that a lot of employers seem to exhibit towards their FTE employees, I think there are two really, really important points that a lot of companies haven't figured out and the FAANGs have to an extent. 1. Have a proper career path for senior technical staff. That's the part that most companies haven't figured out. In the minds of the people who design the career paths in a lot of places, it's apparently desirable to become a manager as soon as possible. Not to mention the "why bother, they're going to leave in a couple of year anyway" approach, which is a self fulfilling prophecy. 2. Have problems that actually require a senior engineer, and let them get on with it with a minimum of red tape and political BS. Please note that I didn't say _technical problems_, there is a lot a good senior engineer can do to improve your technical team by mentoring, process improvements, tooling improvements and so on. Most of us who've been in this industry this long love what we do (because otherwise we'd be off working as a bush pilot or something) and want to share our knowledge as we've now become the people who helped us in our careers when we were the more junior people. 3. Listen to your senior engineers. Yes, I know, I wrote "two points". This one's on the house :). It's a problematic category. You want a temperament and style match from someone who isn't a bullshitter. I've probably been at this too long and likely presume too much competency but I've found the skill continuum model to not have much utility in team formation. People tend to be generally competent in a way that's independent of how long they've been coding. Fred Brooks claims 2 years is essentially the Pareto 80/20 crux point here and I believe that agrees with other skills based practices. Martial arts progression, for instance, usually has some test to demonstrate general competence around 2 years or so. Many trade schools have about a 2 year program. If the bulb is dim after 2 years the trajectory is likely not good for improvement and more importantly for large project delegation. I've been doing this for over 20 years, been running teams for over 15, there's been a lot of people I put hope into. They were probably mistakes to give work to. It sounds like predestination and like I'm being a bastard. Truth is I don't really follow the 2 year advice but it's pretty clearly the reality. I just can't be a calculating brute like that. It's way too sociopathic for me. So now that I've Nicoli Machiavelli'd myself: Make sure they aren't liars, stupid or arrogant and look strictly at their velocity of adaptation. If you are not able to pay market rates (that match the big tech companies) this is the markets way of saying "you should be denied access to this talent because it can be better utilized elsewhere" Pay up or go away, stop trying to find the secret to underpaying devs. How much equity are you keeping? Probably a greedy amount.
So many startups fail because they cant find devs while the founders are trying to keep a Zuck like share of the company based on some 10 year old Fred Wilson blog post. >>If you are not able to pay market rates (that match the big tech companies) this is the markets way of saying "you should be denied access to this talent because it can be better utilized elsewhere" "I have a great idea to make chairs, but the chairs won't generate enough profit to use the special type of gold bar I need to make them. Where can I find cheap gold bars?" > impossible to match day rates pro-rata You're not expected to match day rates if you're offering a permanent contract. I usually advise people doing contract work to charge at least double what they would otherwise get in full-time employment, just to account for their additional costs and time spent on admin. Compare permanent senior engineers rates with permanent senior engineers rates, rather than with day rates - it's a completely different frame of reference. Triple is the UK rule of thumb. Give people what freelancing/contracting can't: I'm thinking, stability, time for their families, visibility over the next years, paid training, peace of mind, etc... I've done both perm and contract work (lately the latter, by my choice), and here's what I've seen. 1) some people prefer stability, they are the ones who will prefer "perm"; make sure you're offering actual stability. Frequent re-orgs, etc. will drive off the very people most likely to prefer permanent positions 2) there are good senior engineers who aren't into a lot of people time, who will prefer not to do contract because of the salesmanship that is inevitably involved. If you're requiring a lot of meetings, etc. you are driving off the "I just want to work" senior engineers who you might otherwise be able to keep. 3) offering interesting technical problems or attacking an important (to society) problem, is a non-salary method of attracting senior people who have probably had a job which lacked these in the past 4) by the time you're senior you have done a fair amount of slogging through bad code; a greenfield project (where you get to make your own architectural decisions) is one way to attract a senior engineer 5) by the time you are a senior engineer you have figured out that what matters most is your direct supervisor; make sure yours are a pleasure to work for. Because money isn't the only thing that matters. Sure, money is great, but it's not the sole determinant of happiness in my experience. Other things that matter: * being part of a team, pulling towards a goal. * stability. Contracting is awesome, but often feast or famine. * work life balance. Yes, as a contractor you control your working hours, but it can be hard to stop working at 5pm too. * benefits (if in the USA, health care is huge and the plans with an employer are almost always better) * ability to explore different areas. When you are a contractor, you are expected to be top notch at what you do. Often that means you don't get to explore new things (except on your own time, which you should do). It's nice to get paid to learn as an employee. I think that contracting is great, but so is employment. Just like when you are a startup you should compete on your own terms (your USP), if you are looking to keep senior developers, find out what you can offer (some of the above) which contracting cannot. (How? Ask senior devs in your market!) Source: I've been a contractor and a full time employee, about a 50% split during my career. > ability to explore different areas. When you are a contractor, you are expected to be top notch at what you do. Often that means you don't get to explore new things (except on your own time, which you should do). It's nice to get paid to learn as an employee. I've also done both over my career, and I haven't noticed much difference in this regard. I've proposed we try out (and they accepted) a different language or technology that I would need to learn numerous times to long-term clients. > long-term clients. Ah, maybe that is it. There is a distinction worth diving into between the first project you do as a contractor (where, in my experience, you are hired to deliver) and later projects where you are a known entity who has solved problems and delivered. In the latter case you are (and I have been) able to propose getting up to speed on new technologies. I was thinking more of the former case when I wrote that, but you're correct, there are different scenarios I glossed over. There are many reasons to work for a company and money is not always #1.
Maybe your product is exciting? Maybe your team, tech, industry? And they don't even need to be exciting necessarily, many would prefer a pleasant non-draining place. What I don't get is why are the rates so different? Arguments like: uncertainty, getting clients is hard, certain overhead isn't paid, not always having work are all valid reasons. However, they don't seem to make sense for such a big difference. Based on those reasons, I'd suspect a 1.5x difference to be more reasonable, but in most cases it's like 2x to 4x. I don’t have to pay benefits and most overhead, which is 25-50% of what you think of as your salary, depending on your salary and geography, so that factor alone gets you to ~1.5x before any accounting for slippage, overheads that the consultant now bears (tax and accounting, marketing/sales, collections). If a consultant is charging less than 2x, I hope they’re thinking of it as a hobby or charity. On the buying side, if I need a specialist wizard on a particular topic for a week for an acute problem, I can shop for skills and largely don’t care what they charge. I want my problem solved and whether it costs $10K or $20K to solve a wizard-scope problem, I literally don’t care so long as it gets fixed. I don’t calculate “well, sure they fixed my problem but I’m annoyed that they make $1M per year at these rates!!” It's usually because of different accounting treatment and the relaxation of employee policies. A contractor can be booked as a fixed expense, can come out of discretionary budgets, you don't have to follow salary banding and it's not necessarily seen as a problem if they're paid more than management - especially if it's hard to tell if they actually are (taxes, insurance, etc. complicate things). The other stuff is retroactive justification. Different tax treatment makes up 1.5x by itself, and then you have all the overhead (accounting, insurance, legal - if you're too stingy to pay a proper lawyer and accountant in the beginning, that will cost you much more later) and "benefits" (e.g. vacation and sick days make a ~10% surcharge), so 2x hourly rate means that as a contractor your annual actual cash-in-hand for the same amount of work is roughly the same if you have a pre-arranged contract where everything works perfectly, which it does not - you need to account for customer nonpayment, you need to account for hours worked on sales proposals that don't go anywhere, you need to account for time&effort in getting this customer, negotiating scope and terms, so if you're treating contracting/consulting as a proper business then an appropriate "customer-billable-hour" rate is 2.5-3x to "FTE-contract-rate" for the same person doing the same work. If you get a good long-term customer that gets you lots of sustainable work on a retainer - reducing (but not eliminating) the overheads on sales,negotiation,downtime and legal/nonpayment risk - then you can go 2x; but 1.5x would be losing you money even in that case, you'd be financially be much better off taking the 1x full time job then. a self-employed contractor is an employer of one person, as such he needs to pay the employer portion of healthcare insurance cost, employment tax, social security, etc... (in the US that's another good 30% on top of salary, in France it can double the cost of employing someone). In addition the contractor does not get the benefit of bonuses, ESPP, profit sharing, 401k contributions, and takes on extra risk, all of that is worth some premium. If you've ever had a client simply refuse to pay you for a two week contract ("sue me"), argued with a client for hours about whether a specification change was "material", had clients decide your estimate changed T&M to a "fixed price contract" ... then even 2x is fools game. 2x is what I might charge clients I know for a low risk, low overhead project. To what others have said, billable hours are never 100%--and may be a lot less. When I was an IT industry analyst we billed something like $10K/day for a consulting engagement but we didn't bill for travel time and a lot of writing we did but didn't sell. Any marketing/selling/administration/ongoing skills development (to say nothing of time you take off) is totally on you. As a contractor you also have to pay for most of your overheads, most notably insurance, training and any certifications. The company is also paying for the convenience of a flexible workforce and specific expertise. It's also relatively easy to treat a contractor as capital expenditure which is often beneficial for the clients accounting. The demand side is a factor too. Some companies seem to place a premium on being able to flex numbers of contract staff rather than adding and removing numbers of permanent employees. Maybe for morale? Are you comparing apples to apples? That is including costs of taxes and insurance? Your underestimating how much the OH head costs of employees is. I think you're asking the wrong question. Which is probably part of the problem. I know it is at most of the places I've ever had anything to do with. No block of people is homogeneous, but a lot of the time companies think they can just have some kind of blanket policy and make everyone happy. In reality, especially if you're a smaller company, I think what you need to have is empathy and flexibility. Everyone you want to hire is different. Some are loners that want to travel, some have families, some want to go back to school while they work, some want to grow their wealth. Some just want to be around cool people and build interesting projects. But what none of them will ever be is the same. If you want to attract and retain top talent then you need to have a conversation with that talent that includes questions like "What will make you happy here?" "What can we do to accommodate your needs day-to-day and long-term?". And then actually help realize those needs. Unless you can match the variety of work and the net value received by the engineer, you can't. But you're not looking for the type of engineer that will succeed at consulting - these people will in general be more extroverted and will look at he risk/ROI as a life-calculus. You're looking for the less flamboyant and risk averse engineer. For me (big tech senior), you'd have to get close to the money. I might take a 10% paycut, but probably not more than 20%. Equity can close the gap, but I can do risk based calculations, so it'll need to be very strong. I also have great benefits, a pretty good work life balance (more thant 40h a week, but when and how much I want. Most big tech Srs I know do- we've been doing this long enough to know how much we want to work. What could attract me out, for at least a bit less money?
* More say on product definition
* Interesting problem space
* Leadership that I believe is genuinely happy to have me on the team, and wants to support me. And that I personally like.
* Team members that I like, including ones that I can mentor
* Clear ability to grow, including increasing rewards with appropriate impact.
* A culture that is a great fit And you'd have to woo more than just a blind linkedIN inMail. People want to be wanted. You likely are underestimating the market rate for senior software engineers, this is a common problem for small companies that don't have too much experience in what they are hiring for. If you're not willing to pay >$175k, you're not going to get good senior engineers. It's difficult problem, but don't forget the day rate might sound high but it has got quite a few hidden costs bundled up in it: pension, holidays, down time, expenses and the various taxes. To answer your question: different things appeal to different people. Other than the obvious of paying someone a boat load of money you could try promoting some of your companies 'soft perks', not the gimmicks like ping pongs tables and free drinks but things like:
- real flexible working
- extra vacation days
- accommodating regarding personal vs work life As others have said:
- selling the work they'll be doing
- the technologies you use
- how many users your products has
- what your products applications are One I see left out is good benefits. Having good health care, dental, etc. that isn't what you get in a one-person package is a big plus for some employees, especially older ones. It was a big pain point when I was doing contract work. Although that was Toronto, so your mileage may very in the US. I think ultimately though if you can't compete on salary you're looking at attracting a certain subset of engineers. There may be great engineers among them, but few of them will be paying down a large mortgage for instance. A lot of property markets just don't allow people to take significantly lower salaries and you have to accept that and go after the engineers who can. Not enough information. What's your team size? How much prerequisite knowledge is your product? Otherwise all I can give you is snark: Hire juniors & call them senior engineers. Or hire a senior engineer to do everything & don't hire any juniors Why are they leaving? Is it just the money? Are you sure? Is there some other sweetener missing? A recruiter friend of mine says she could probably steal half of most corporation's engineers just by learning the non-financial pain points and addressing them. Businesses often have weird ideas about how nasty / ruthless they can be. Usually though its little things not even on the nasty / ruthless scale. Direction/Management style is often a big factor. Not to mention the work itself. The other quirk was about the transition from junior to middle to senior. These are often mismanaged and that can sour others opinions. The other obvious one is people leaving to get a pay rise is this is often the only way to get one. tell your recruiter friend to go ahead. do it. then let us know how that went. She's running an expanding business doing recruitment. I think she already is. As a Snr Eng in one of the FAANG, my _personal_ list: - interesting problem domain (which does not necessarily mean trendy): this is about selling to others why the problem and your company matters - equity/career progression: (controversial comment incoming...) a strong Snr in a FAANG will most likely be a CTO/VP type of leader in a startup, so provide generous equity - freedom in terms of decision making: present (business) problems and let people go and tackle them, you don't want to be micromanaging - freedom in terms of work/life balance: let people manage their schedules, being fully remote, location independent - stuff that most FAANGs will struggle to compete with There has got to be a middle ground on pay. I've worked contract positions that transitioned to full-time. There is something wrong when a company tries to transition me to full-time at less than half my contract rate. I'm talking about total compensation: base pay, pto, bonus, equity, health insurance, even employment tax that they are legally obligated to pay. The sum of that was less than half my contract rate. How can I be paid more than twice that for two years and then they claim they can't afford to get anywhere close for a full-time position? I accepted a role at a modest day rate and turned down offers from FAANGs. Why? 1. The project is entirely FOSS and in an interesting problem space 2. 100% remote work, with flexible time 3. There's no scrum/agile ceremonies and similar corporate stuff BTW can someone provide a quick refresher as to this now allegedly lucrative contract market please? Like, what might be median rates for Senior Developer skills in a reasonably meaty domain (say data engineering, crypto, high-performance web) in say, Bay Area / NYC respectively (I'm assuming there's a differential here). That's be very helpful. Again, not "consulting" per se (and the baggage / shtick that goes along with it), just straight up 6-18 month contracting. Thanks very much! The basic mechanism of capitalism is supply and demand. When you write: "it's pretty much impossible to match day rates", you mean that your company doesn't want to pay the market rate. There is no secret strategy. You either pay market rates or hire less capable developers who will work for the rates you are willing to pay. To add to this: If your company doesn't have the funding for expensive engineer salaries you can compensate with stock options and an exciting product people can believe in. It means your career page needs to become a pitch, and your interview is most definitely going to be a two-way one where you need to convince the engineers. Not everyone is after the money alone, a lot of people want to work on something with a mission they can get behind. From what I’ve seen, you can attract these people by offering them attractive (to them) work. In the case of my employer, we’ve had one very strong guy taking a perm offer because he only wants to work in Scala, and there are very few Scala contracts in town (he also can’t move). This. I'm a senior engineer. I'm passing good at what I do. When I left my last company, I started looking for work in a culture that has changed significantly since the last time I'd looked for work (I was at that company for 27 years). It was a shock. The naked and unapologetic disrespect and ageism has been pretty crazy. I threw in the towel, after a few months, and I'm now working with a nonprofit, for no money, and loving it. You couldn't drag me back into the rat race with wild horses. I'm quite aware of the value of my skills and experience. I was actually willing to work for half that, if the work was interesting. I have my retirement set. I don't need to work, if I don't want to, but I love to work. When I die, the coroner is gonna have to rub "QWERTY" off my cheek. I'd suggest that having a culture of basic respect for folks with experience would go a long ways towards your goal. Maybe less of the "cultural fit" stuff, and the "Draw Spunky" tests. Experienced people can make things happen, which is what we are really after. I ran a shop with experienced C++ programmers for 25 years, and got used to doing really difficult stuff, and regularly shipping our work. One of the shocks I encountered was how rare that kind of thing is. Many folks in the consultant market are there, because no one wants them as employees, or insist on treating them badly, when they are employees. These are folks that can write their own tickets. They don't need to be treated badly, and would often drop their gigs in a heartbeat, if they found a culture that valued and respected them. Here's a suggestion: Hire them at market rate. Make their experience with you a joy. Down the road, say "We can't afford to keep paying you this rate, but we'd be beyond honored to have you on our staff at half that rate." You'd be surprised. I got one of my best and most loyal senior engineers that way. There's the old story about the retired engineer that was brought back in as a consultant to look at a problem that no one could solve. Engineers on the payroll had been looking at it for weeks, with no solution. They looked at the system for five minutes, said "There's your problem. Just do this...", and the issue was solved. They then invoiced the company $10,000. The company responded, saying "You only worked for ten minutes! How can you expect us to pay that much? Please resubmit the invoice with specific line items." The engineer resubmitted the invoice: Aegism is a really big issue. Not only in the form of your $10,000 invoice example. Persons with a certain amount experience, such as yourself, call out BS when they see it. And that is not welcome. Employers seem to prefer young 'uns who don't question anything and just do as they're told. This becomes particularly bad with "consulting firms" who charge by the hour to stuff it up and then charge by the hour to get a new team to fix it and then another team to fix the fix and so it goes. One of thousands of examples is the $6M payroll project in Queensland that blew out to $1B+. My lawyer tells me that I can't name the firm. I’d like to see more companies offering flexible working schedules. 4-day workweeks or part time. Two months on, one month off. FAANGS can’t match flexible work schedules. There is no silver bullet answer. I've been hired and I know how does it feel when company wants to hire, and when they're into teasing and time wasting game. FAANG might get away with recruitment false negatives but even their overconfidence has been overheating with personal clashes in recent years. In between there is a lot of space, and a lot of people looking. For many contractors, it's a lifestyle choice primarily. They often don't want to deal with all the performance reviews and would rather "be their own boss". Day rates aren't always as lucrative as they sound when you consider time on the bench and tax rules such as IR35. Contractors I know would only take a perm gig in very desperate times Do you really need top tier engineers? Top tier firms pay lots of money for engineers because they expect them to have specialized knowledge, ability to deal with global scale, business intuition and communication skills to identify and drive large scale projects. If your company can fully utilize all those skills, those engineers can easily bring in revenue at multiples of their cost. There are a few options I can see: The primary way is to pay more. Technical skills are in a (global) marketplace, and right now it is a sellers marketplace. If demand outstrips supply, this is the natural path. That said, if you can’t match the pay of the top bidders, you need to provide an environment they can’t or won’t, and how you go about this is specific to individual target developers. Some things I might consider being worth accepting a lower offer - the range of things others will consider are different, and I’ll be interested to read the other responses to this thread as they come up! - Be up front about pay and benefits. The number of times I’ve seen “competitive market rates!!11!!” in an ad only to discover they are absolutely nothing of the sort is simply infuriating, and I won’t engage with any recruiter that won’t give an up front range, and concrete measures of how to be at the top end of it. - Don’t use third-party recruiters. This is variable by country, but in the UK recruiters have a _terrible_ reputation. I’ve personally blocked over 100 of them by email and phone, and as a rule do not respond to them. - Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for. - Eliminate barriers to work being done. I can’t count the number of places I’ve seen where developers spend more time in irrelevant meetings designed to boost the sense of importance of a B team middle manager than pairing, or even getting individual tasks done. - Have an altruistic mission, or at least one aligned with the ethics of the candidate. If your business reduces to “invade privacy to sell ads”, I’d be unlikely to be interested even at top end rates. If it’s something less sociopathic, it may be worth a second look even if the explicitly stated salary range is lower. - Don’t attempt to control employee behaviour outside of working hours. This includes open source contributions without getting tied up with legal review, and over-reaching IP agreements. - Don’t expect me to go to an office, and have top notch IT support for remote employees, whether that’s VPNs that work without screwing about, or a BeyondCorp-type model. Others may want to go to an office, and it’s important to support both models. The days of “you must be in the office weekdays from 9-5” are gone though. >Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for. I'm always interested in this point of view, because I understand why candidates don't like it but as a hiring manager myself I also know that there's a fairly large proportion of candidates who look good on paper but can't actually do the most fundamental thing that a developer needs to do: solve an abstract problem with code. What's the alternative to filter those people out? That largely is a case-by-case decision I think. Perhaps via open source work, perhaps via a short take-home assignment. Since work in most of the US is “at will”, it’s an easy problem to solve if it turns out someone has exaggerated their abilities. My problem is not with _any_ coding to be clear. It’s mostly the Google gotcha questions designed to make the interviewer look smart, and where the primary takeaway is that the candidate has or has not seen that question before. Things like “let’s refactor this thing collaboratively and discuss trade offs” are fine - and discussing trade-offs gives you far more of a feel for a senior engineer than whether they can implement some trivially Googleable algorithm for which “use a library” is almost certainly the actual correct answer. This is the style of question I personally use when doing technical interviewing. I always find this argument of "Google gotcha" questions weak. I agree 100% that tricky questions around dynamic programming, linked lists, etc. are a terrible choice. However, I think a lot of these questions do a good job of measuring how well the candidate understands basic data structures. It amazes me how many "seasoned engineers" do not understand when to use things like hash sets/maps (just look at the monthly blog posts about how you shouldn't use `in` in Python on lists because it is O(n)!! It blows my mind this is blog-post worthy). Also, I would far rather have a company not hire me because I failed a programming assessment than have them hire me and then fire me a week later because they were finally able to assess my skills. The issue fundamentally is that most people do not use this kind of knowledge on a daily basis - even those of us doing low level work, and when it is needed, it is a mere web search away - or if necessary I can reach for Knuth. I think you misunderstand my notion of a "google gotcha" - I'm not proposing that interviews do not into rigorous technical detail. I'm proposing that interviews that test knowledge of easily-looked-up trivia rather than an understanding of engineering pragmatism and trade-offs are fundamentally flawed and yield markedly worse results than those that do not _regardless_ of company. FizzBuzz-style questions are fine. Any coding exercise that takes under 30 minutes and doesn't require you to happen to remember some obscure piece of discrete mathematics trivia. Fire fast. I'm out of touch with current contract rates and salaries, but when I switched from contract to full time in 2012, I figured that a nominal pay cut was actually a 30% raise based on the full time perks: paid vacation/holidays, 401K, stock purchase plan, paid healthcare (this was before Obama care) etc. I've been freelancing for... 10 years, but still don't see as many 'contract' positions vs ads for full-time positions. Even many 'contracts' are expecting fulltime, vs more flexible hours. They exist, but perhaps are more prevalent in some countries or regions? Based on my past experience in contract work, I'm guessing many clients want specific help for their problems and people that can on-ramp quickly. The least risky way to fulfill that is to find someone through your network that can be vouched, instead of doing a long song-and-dance of SoWs and portfolio presentations with randos on the internet. That removes the need to post about these positions publicly. I don’t think I’ve ever heard of a senior candidate considering my company to mention or cite a consulting rate as a comp or a reason to not join. I think I’m competing against FAAN[M]G full-time for these candidates and, until your question, never even thought to benchmark against day rates. Yeah, I'm also a little confused. I'm in Germany, but the market for contracting isn't actually a huge deal for a lot of companies. I know a lot of Freelancers but they couldn't even work at 3/4 of the companies that employ software developers (at any level). Most of them are contracting for large businesses, and often for months at a time, but the overlap of "is available for fulltime/is available for contracting" is kinda miniscule - and on the other end of the table there might be some companies that would want to employ a contractor they like fulltime, but just as often they wouldn't as it's just a time-limited "overstaffing". I'm not sure if it's a possibility for you but you can hire internationally if you are operating remote. You can find cheap, great talent from many places especially if you are paying in USD. For like 40k you can hire entire competent teams in Poland for example. Fix HR and hiring committees first. The best usually don't get past these folks, who e.g. demand PDF resumes, job titles, work references and have no idea how to read beyond buzzwords or how to evaluate github profiles. Once you get past the silly, it's usually easier. 1 - Don’t engage anyone who isn’t able to do the math on total comp. (Benefits, downtime, vacation, etc) If someone is optimizing on today’s paycheck you won’t win. 2 - Be generous with equity. 3 - Quantify career growth and progression. 4 - Sort for people who agree with your mission and want a long term impact. Interesting question, as I just handed in my two weeks notice for my day job of nearly 20 years (so I guess I'm a senior engineer, but I suffer from imposter syndrome and think I still don't know what I'm doing after all this time). I'll second the interesting work and keeping people busy, as the job was boring me to tears. Part of it is on me, as I was having problems giving 100%, and that's unacceptable to me as a professional. But if I was being tasked, I don't think it would be as much of an issue. I'll also second bare minimum raises. It's not about the money, but rather that the Trinity study found that inflation averaged 3% YoY. If salary isn't going up by at least that much, you're cutting my pay every year. While I can sling bits in just about anything and have system administrator experience to boot (running my personal domains and mail servers on the open Internet for decades), I have to insist that my personal development seat is Emacs running in Linux. Apart from the fact of it sucking less, I'm so experienced with them both, it's a waste of my time to force me to use other tooling. I can (and have) cross-developed software for Windows, OSX and vxWorks (and soon to pickup Android and maybe iOS), but I've done it all from Emacs under Linux with no issues. I have no issues learning new SDKs, toolkits, frameworks, languages, etc, I just have 20+ years of Linux and Emacs experience under my belt, it's one of my skillsets that is a feature. And last, I'm never going to work in an office again if I can manage it. No, I don't care how awesome your team or office is, I'm happier, healthier and more productive at home. Other tech firms have realized this[0], figure it out or I don't want to work for you. ETA: Ooh, another big factor is leave. I don't need money, in fact I'm probably a bargain, but I want to work less hours, not more, and in my free time I rescue people off mountains. But this requires I be in a state of semi-on call, able to drop things at a moments notice to go rescue people. I always make up the time later (or take annual leave), but part of what I like about software development is the "episodic" nature, where I can cut to something else for a day or two, then come back to the project fresh. [0] - https://stackoverflow.blog/2013/02/01/why-we-still-believe-i... Focus on what FAANG can’t usually give — high signal/noise ratio, feeling of being really important and appreciated, opportunities of making big impact, near zero bureaucracy, big stock options etc. It’s basic marketing thing, no? Differentiate if you cant compete directly. > FAANG can’t usually give > big stock options ? I meant big in percentage, not in cash value If that is your strategy you have no chance of succeeding anyway. The only way you can beat these companies with deeper pockets is being able to offer something they can't. It may be of higher monetary value or personal value. Look for older people. I know I contracted my ass off while I needed to build my wealth, after that I changed to less demanding jobs and started caring about holidays & colleags & raises. Why would you want full time permanent workers? In theory, you shouldn't have to match FAANG rates since you should be hiring a different class of developer (who couldn't make it at FAANG, like bad at LeetCode). being bad at leetcode has nothing to do with being a good engineer I never said that would make them bad, just that they are in a different class. There are plenty of good engineers who can't pass LeetCode style interviews. This effectively removes them from that FAANG compensation level and allows companies to hire them at a lower compensation tier. Basically, there's no point in competing with FAANG compensation since you can get their rejects, many of which are still great engineers. I'd consider leaving my faang level salary for more personal time. Give me a four day week or, even better, a three day week and you could have me for much lower than my current salary. I'm the same - I just launched https://4dayweek.io/ which may be of interest to you :) Ah that's simple: just make sure that you have an incompetent government that will utterly destroy the contracting market, like they did in the UK. :/ In the USA, good health care benefits would be a major way. Look in Europe. We're cheap. €100k is still quite good here. You can use companies like CXC global to make it easier to deal with taxes and the like. Different countries, different cultures, different company values. FAANG = tech.
anything else -> you're a cost center. Become sales and they'll appreciate you Offer good benefits, a gentler pace of work, and security Are you in the US? I don’t really know any highly paid contractors in the us .. maybe I’m in a bubble but I would guess that is <5% of the market - Meaningful work
- nice, open-minded co-workers
- good salary is all you need. Oh, and don't handle us as a piece of shit, who just crank out code because we will leave. 2 cents anectoda: I just out of my third contract period over the last 15 years. I will never do contract again. It promotes bad working condition and less interesting work. It’s all about the company vision and the candidate believing that they can play an important role in achieving that vision. Try paying them market rates? If you can’t, offer equity. Or try to sell them on your “vision” or some other BS and hope you find a sucker. Pay more money. Literally it’s that simple. If you can’t match contract day rates, then your business model is not working in the current market. Do you really need a senior engineer? Not everyone can get into FAANGs, so you don't necessarily need to match FAANG level rates. Out of interest, what are the ballpark daily rates for the contract market in EU/US ? Where are people finding these high contract rates? I’d like to get out of full time employment and into contracting, but literally have no idea where to start. Relying on my own connections is useless and not sustainable, I’d like some serious work, not references to people who “need an app”. Depends on which country US Contract Rates are derisory when compared to the UK Is the contract market lucrative? I have never gotten the impression it was I'm a senior engineer (~30 yrs experience in software dev right now) and I don't really want to work for consulting/contract market. Well, I mean if somebody offered me money beyond my wildest dreams ("never have to work again" kind of money) - maybe, but otherwise it's too much annoying stuff that I'd have to deal with. Some side gigs are ok, but having a steady job makes my life much easier. What I'd be looking in an employer is: 1. Interesting job. Should be doing something new or interesting that would excite me. Also some position where I can make my own decisions, not just mindlessly marching to the beat. 2. Sane management. Which can communicate, set strategy, facilitate communication between teams, deliver proper strategic prioritization and planning and make my technical jobs shuffling the bits around as easy and efficient as possible. Also some measure of trust that I know what I am doing, and if I don't I'll tell you. 3. A good team is very important. Excellent if I can learn from these people, good if I can rely on them to do their part, otherwise it becomes unworkable. 4. No death marches. I mean, I work odd hours and may jump in on weekends too, if I feel like, but that shouldn't be expected of me. Not a single 22 yo without a family or life anymore. 5. No political bullshit. I don't mean politics like Trump vs. Biden or whatever, though seeing that at the workplace would probably make me run fast and far, I mean things that don't have much to do with business but a lot to do with manager's egos and their perception of how their career should go. If I am caught in anything like that, it makes me very sad and looking for the exits. 6. Decent pay, of course, and customary benefits (including vacation time), but if it's not on the level Google pays I'd understand, provided all the rest is good. A question: where do I find those lucrative contracts :) 1. No agile 2. Managers with a decade of direct engineering experience 3. No PMs 4. 100% Remote 5. Solid tech stack 6. Interesting problem to solve outsource; for 7k usd you can get very skilled people Have 10 years of experience in multiple EU countries and my every base salary was below this, yes. Culture, community, and networks, not comp. It depends how you define Sr Engineer, but I'd look for people who are less tolerant to volatility in their income stream and value consistently high pay over sometimes consistent extremely high pay. The nature of capitalism is such that is capitalizes on people with bills to pay, and influences them into having more bills to have to pay. So people with families, mortgages, expensive cars etc.. Looking through all the comments, it seems to me that there is a huge differnce between contracting in the US and contracting in Europe, and that that difference is why more European developers favour contracting than US developers do. Contracting in Europe (especially in the UK and Ireland) is largely controlled by recruiting agencies, who act as middle men between companies and contractors. A contractor looking for a new contract deals with these agencies, not with the end company [usually]. In the US, a contractor is expected to find and manage clients themselves. Perm salaries are also significantly lower in Europe, making day rate contracting incredibly lucrative for a senior dev who can charge top tier rates. My own experience after working as a contractor for 9 years: 1. Money in my pocket is typically 50% more than it would be compared to a reasonably payed perm position. 2. All the perks offered from a perm job I can avail of via my own Ltd company at reduced cost: health insurance, pension contributions, tax efficient travel schemes, etc. 3. Six month contracts are almost always rolling contracts, as in, they are renewed every six months until I decide to leave. I always decide to leave eventually, the contract never ends and forces me to leave. Any gaps between contracts are there because I choose to have them. 4. Projects are ALWAYS more interesting. Business as usual, bug fixing teams, seem to be made up of perm devs who have years of domain knowledge. The greenfield projects tend to go to contractors or teams that are comprised of a lot of contractors, probably because less domain knowledge is required for new projects. 5. Learning on the job is part of contracting. If you don't know X technology, you pick it up as you go along. With the odd very focused exception, I've found that there is no expectation that contractors be 10X or ninja developers. 6. Paperwork takes me about 10 hours per year -- that includes my company VAT returns, preparing docs to send my accountant once a year, and meeting that accountant once a year. 7. Expenses are a huge thing. New lap tops, phones, courses I want to do. All covered by my company as part of my job. 8. The biggest one as far as I'm concerned. Moving from contract to contract, seeing the different ways that teams build their products, picking up new technologies every year -- it all boosts your confidence as a developer. You've seen so many different ways of approaching problems and used so many variations of the tech that nothing phases you. Your confidence is huge. 9. No Leet code or drawn out interviews. I've never done a Leet or online test for a contract. I've rarely had more than a single interview to land a contract. I've never done a white board interview. The hiring process is just easy and simple, as it should be. 10. I write code all day. I specify in each contract that I'm not a team lead or a junior dev mentor. There's no expectation in the companies that I work with that I assume team leadership roles. 11. A day has 7.5 working hours. That's it. No expectation of overtime, or on-call. A day rate contractor works the 7.5 hour day and that's it. The above 11 points are all based on contracting in Europe. I have no doubt that American contractors would disagree or question each point, but that disagreement is probably geographic and based on the different way things work in the US. As to the original question of how to attract senior devs away from contracting: 1. Pay them more -- a lot more. See point one above. 2. Give them greenfield projects. Almost the same in Australia too. You don’t have to match contract wages. There are benefits other than salary that contractors don’t have access to. But let’s be honest. It’s a marketplace. The solution to hiring is more money. That’s how capitalism works. I'm going to be a curmudgeonly contrarian in this thread. You can highlight the text of my comment to make it easier to read after the incoming downvotes. :) I'm not desperately searching for work-life balance, using the latest fad of a technical stack, remoting, unlimited vacation, having the best free snacks in the break room, etc. Sure, at a superficial level, all that stuff sounds great. I'll make use of the in-office climbing wall sometimes. But if you lead with that pitch, you give me no confidence that your company will even be around that long, much less provide me with room to grow professionally and financially. I want a company to sell me on its vision for success in the market that I would be participating in. I want my co-workers to be motivated by the success of the endeavor in which we're all involved. I want an ESOP that will be valuable for my retirement. Why do I want to work with a bunch of people who are mainly there for the freebies? Look at what just happened to Basecamp. They cultivated a workforce that was more concerned with airing political grievances than they were with the success of the company. The second the politics were shut down, a third of their employees walked out. Imagine you're a developer at that company, trying to ship some product or feature to meet some bonus metric - and the people you're depending upon to do their part quit their jobs because they absolutely must argue politics during their work day. My superficial read of the Basecamp kerfuffle is that what people are really upset about is a lack of professional development, but it was expressed as a sort of aimless resentment of everything the founders are. If what the founders are is the most important thing in the company - if the company is thought of as their thing, and not a thing any other employee will ever have a hand in steering, it would be frustrating. I think the walkout is a symptom of the problem you're pointing out, not the cause. People started to think of it as a dead-end job working on someone else's toy. I could see some of what you're saying as well. Although I would argue that if people think it's dead-end job working on someone else's toy -- the company leaders aren't focused on winning. They're still going to attract new employees for the wrong reasons, or at least for reasons that wouldn't get me to want to work there. > They cultivated a workforce that was more concerned with airing political grievances than they were with the success of the company. The second the politics were shut down, a third of their employees walked out. That is a very inaccurate retelling of the story: https://www.theverge.com/2021/5/3/22418208/basecamp-all-hand... Uh, yeah, I've read the account of the Basecamp all-hands meeting a couple of times. I couldn't believe how childish the whole dispute was after the first reading, so I read it again. Rather than spending that morning strategizing about the next version of their software, what bugs needed fixing, how to increase sales, what features were working or not -- they argued over politics. I mean, no one was accused of doing something illegal or even wrong. There was no sexual harassment. There were no racists or racist work practices uncovered. Just non-work political grievances. One guy had different political opinions than some other people. I think he said something positive about Breitbart, gods forbid. Some of the participants claimed to have been literally crying and yelling at their computer screens. Words were interpreted or twisted to frame an argument over if there was no white supremacy anywhere, or whether there was no white supremacy in that work environment. "Privilege" accusations were leveled. The whole thing was ridiculous. >There were no racists or racist work practices uncovered. Pretty sure someone saying "white supremacy isn't a problem" is implicitly racist. You don't just state that and suddenly, there is no white supremacy or racism. It's the same people who declared racism was officially over in the US after Obama was elected. The last decade of racially biased policing says otherwise. Part of the story also was the founders were annoyed the D&I team had asked the company to get rid of & stop maintaining their "Funny customer names" list which apparently was mostly African & Asian people. > Why do I want to work with a bunch of people who are mainly there for the freebies? I mean, some of us value work life balance. Even on projects I'm insanely passionate about, I need to pace myself, otherwise I'll get burnt out. I don't think this is a very contrarian view, is it? I value the same things in the company - I want to work on something that changes the world, I want a company that has a vision, mission and strategy - where the business side is at least as senior as the engineering side. And of course I want to take part of what I create home financially. Bells and whistles in the form of remote work, snacks, etc are nice, but they are bells and whistles :) this mini-rant you posted about Basecamp is not just a wild tangent completely unrelated to the topic of discussion, you're also making things up that have no correspondence to the reality of the situation. to say "They cultivated a workforce that was more concerned with airing political grievances than they were with the success of the company" is just absurd. they lost Sam Stephenson, who had been there 15 years and authored a sizeable amount of their open source. to shine as an open source contributor at a company with DHH, you've got to produce a lot of good work. the guy who kicked off the firestorm was another long-term employee, Ryan Singer, and it's true that he did it by posting about politics. (specifically, praising Breitbart.) but he posted about politics after a decade or more of doing great work for the success of the company. in each case, these people absolutely proved their commitment to the success of the company. and there is absolutely no evidence that the specifics of the political division even had anything to do with airing grievances per se. if you're going to go off on a wild tangent, at least talk about things that actually happened in real life.
1. Finding the problem: $10
2. 38 years of experience, six years of school, so I could find your problem in five minutes: $9,990