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.
"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 :-)
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.
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.
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.
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.
Obviously you can get away with paying below market rates if you provide some other benefits to make up for it.
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?
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.
But that wasn't the case, at least for me.
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 x100.
I don't understand why companies see this as acceptable, especially when market rates might be so much higher.
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.
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.
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?
https://www.wsj.com/articles/SB10000872396390444914904577615...
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.)
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 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.
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
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.
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.
[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.
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
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.
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
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.
If I was contracting I would be counting the money while watching them mess it up with a wry grin on my face.
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.
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
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.
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.
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.
Like what kind of gadgets ?
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.
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'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!
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 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.
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.
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.
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.
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.
We build software businesses here. The UK should try it some time.
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.
> 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.
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.
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?"
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.
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.
Be it pushing for certification, mooc, internal training credit.
All of that was part of my review for instance. It does work.
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.
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.
The “Active Shooter” one at JPMC was somewhat sobering.
I was not referring to conplicance trainings. Those, of course you won’t learn a thing.
Then contracting has been no different to perm work in that respect, for me. :shrug:
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.
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.
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 :)
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.
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.
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.
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.
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.
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.
The difference in compensation more than offsets the cost for insurance, in most cases.
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.
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.
Do you or anyone else have advice on how to get started with becoming a contractors?
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.
It's "etc". Short for "et cetera". https://en.wikipedia.org/wiki/Et_cetera
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.
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.
- 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.
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.
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.
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?
In 11 years of professional work, it's only ever been used as a weapon against the development team.
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?
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.
Not OP, but cynicism against agile get me (somewhat) avoidance of the most toxic workplaces, which is what agile is.
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 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.
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).
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.
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?
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 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)
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.
However, code always documents how it works (sometimes poorly, of course).
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
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
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!
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.
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.
I'm getting that 'agile' is not one of those words, but what words are?
If I ever accept a client or job, there's always a grace period.
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.
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.
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.
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.
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.
It just doesn't work.
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.
Plenty of engineer-run shops are lowercase a agile, but it's not something they bring up constantly.
Agile is the literal exact opposite of "getting out of the way of tech practitioners".
How do you prefer to organize larger software development efforts that have to be coordinated with other business processes?
Edit: This is a genuine question, I'd be very keen to hear concrete ideas on how to work better.
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.
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.
I don't get what you're trying to say here.
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.
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.
Agile is more suited toward software maintenance IMO, not building new software. Rarely are senior engineers looking for the former.
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.
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.
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.
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.
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.
Doesn't matter if you're just been hired. Doesn't matter if you work part time.
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).
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.
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.
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.
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/"
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.
Another way: give a 2% discount for payment within 30 days. Haven't met an accountant that passes up a discount.
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.
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.
BTW at bleeding edge R&D labs the OH rate can be 500 -600%
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).
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.
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.
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.
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.
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.
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.
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.
Also, stay away from Agile/SCRUM bullshit. I personally stay away from companies who have "Agile Coaches" or "SCRUM Masters".
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.
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.)
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.
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.
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.
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/
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:
- 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
Of course it's subjective, but I'd wager more senior engineers would want remote work.
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.
Maybe that's the real advantage of contracting, not having to do a dog-and-pony show every time?
The cost of hiring the wrong person is pretty high, doubly so in countries where it's hard to let them go later.
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.
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.)
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.
Companies here address the gap through other forms of compensation like discretionary bonuses, more annual leave, employee stock purchase programs, RRSP contribution matching etc.
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.
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).
This is not just a nitpick. If someone emailed me looking for a "Snr Eng", the email is getting deleted and flagged as spam.
(EDIT: parent has edited their comment)
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.
* 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.
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.
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.
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.
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!
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 :).
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.
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.
"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?"
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.
I'm thinking, stability, time for their families, visibility over the next years, paid training, peace of mind, etc...
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.
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.
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.
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.
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.
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.
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!!”
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.
Any marketing/selling/administration/ongoing skills development (to say nothing of time you take off) is totally on you.
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.
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.
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.
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.
If you're not willing to pay >$175k, you're not going to get good senior engineers.
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
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.
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
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.
- 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
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?
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
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!
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.
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.
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:
1. Finding the problem: $10
2. 38 years of experience, six years of school, so I could find your problem in five minutes: $9,990Persons 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.
FAANGS can’t match flexible work schedules.
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.
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.
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?
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.
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.
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.
They exist, but perhaps are more prevalent in some countries or regions?
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.
Once you get past the silly, it's usually easier.
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.
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...
It’s basic marketing thing, no?
Differentiate if you cant compete directly.
> big stock options
?
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.
FAANG = tech. anything else -> you're a cost center. Become sales and they'll appreciate you
is all you need.
Oh, and don't handle us as a piece of shit, who just crank out code because we will leave.
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.
Or try to sell them on your “vision” or some other BS and hope you find a sucker.
Literally it’s that simple.
If you can’t match contract day rates, then your business model is not working in the current market.
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.
2. Managers with a decade of direct engineering experience
3. No PMs
4. 100% Remote
5. Solid tech stack
6. Interesting problem to solve
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.
1. Pay them more -- a lot more. See point one above.
2. Give them greenfield projects.
But let’s be honest. It’s a marketplace. The solution to hiring is more money. That’s how capitalism works.
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.
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.
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.
That is a very inaccurate retelling of the story: https://www.theverge.com/2021/5/3/22418208/basecamp-all-hand...
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.
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.
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.