Fast Company has an interview with the CEO of 37signals, a software company in Chicago:
We’re about being in business for the long haul and keeping the team together over the long haul. I would never trade a short-term burst for a long-term decline in morale. That happens a lot in the tech business: They burn people out and get someone else. I like the people who work here too much. I don’t want them to burn out. Lots of startups burn people out with 60, 70, 80 hours of work per week. They know that both the people or the company will flame out or be bought or whatever, and they don’t care, they just burn their resources. It’s like drilling for as much oil as you possibly can. You can look at people the same way....
So you think there’s a slash-and-burn mentality in the tech world?
For sure. I think there’s a lot of lottery-playing going on right now. Companies staffing up, raising a bunch of money, hiring a bunch of people, and burning them out in the hopes that they’ll hit the lottery.
I'm glad to see someone discussing this openly. When I went to work for my first startup in 1987, they cared more about ability than specific skill set: would you be able to learn a particular application or language (although usually not both) well enough to be useful in a few months? Now employers are so focused on next week or next month that if you can't be fully productive in the first week (preferably the second or third day), they aren't interested. And then they get upset because they can't find anyone to hire.
Another ugly change is the emphasis on "show us how brilliant you are with an unrealistic code test during a 20 minute interview." I can see the logic behind this if you are hiring a fresh college graduate who does not yet have a list of professional references. But if you are hiring someone with decades of experience, wouldn't it be more valuable to see how effective this guy or gal is by asking previous supervisors? Nope! And so you get employers arrogantly assuming that anyone who seems smart in this artificial, high-pressure setting must be the best choice, while someone who works better in a more realistic setting just isn't smart enough to do anything valuable.
Employers are increasingly refusing to consider applicants who are past 40. I have even seen ads that said, directly, "This position is open to recent college graduates and those with less than 15 years of experience." Is it really true that those of us who have been doing Java for five years are worthless (or at least, worth less) because we did C and assembly language for 25 years before that?
Another part of the problem is that lots of engineers have housing-bubble era mortgages, so they can't easily move. Yes, if you live somewhere where demand is high for rentals, such as Silicon Valley, you can rent your existing house out. But in much of America, demand just isn't that high, especially if you live somewhere with views like these:
Hopefully more companies will start waking up to reality but it sure is hard to be optimistic.
ReplyDeleteI'm looking for the job description that includes "must already be an expert in programming languages and software packages to be released in the future."
This part stood out at me: It’s like drilling for as much oil as you possibly can.
ReplyDeleteSeems he doesn't understand how resource extraction and professional work differ; there's a finite amount of oil in an oilfield. You can get it out fast, or slow, but the amount is set (for any given extraction technology and budget).
Programmers are different; we don't have N hours of "work" in us that can be extracted over our professional lifespan.
"Burnout" is caused by working too much, but it wears off - and realistically it seems to me that more hours often produces less (work * quality) product than shorter hours - they're falling into the trap of the idea of fungible man-hours.
I can work a 14 hour day for a week at a time in a sprint - but after the first day or two (and at the end of every day) I won't be thinking and producing nearly as well as if I was rested and had time off...
(Most of those startups I hear about running people like that never seem to make anything worthwhile for all their effort, either...)
Now employers are so focused on next week or next month that if you can't be fully productive in the first week (preferably the second or third day), they aren't interested. And then they get upset because they can't find anyone to hire.
ReplyDeleteThe latter tells you the former isn't really the issue. My best guess is that most managers have no confidence in their abilities to mentor (very possibly because they don't really know the technology) or of monitoring progress except by the most brute force metrics.
As for your complaints about code tests, sorry, I've been on the other side and I'd never hire a coder without a "trivial" one that demonstrates the applicant can code their way out of a paper bag.
In the '90s it was write a function in C to reverse a doubly linked list and find (at least some of) the problems with this small function prewritten on the white board.
Applicants were graded on having a clue, not getting the syntax all correct and so on. If we'd followed your desired approach (and I for one don't age discriminate, then again I'm only a few years younger than you and was at my "Sell by" date by the time I started doing a lot of this), half the people we would have hired would have to have been let go, and the companies could easily have failed.
Was we really asking for too much?
In a way we did it to our selves back in the 80's when we changed the law so that companies would be highly motivated to only make there business decisions base on what the next quarters profit. Add to this the image of only people (read boys) who are single and under 30 know computers and you end up where we are now.
ReplyDeleteThe hurrier ya go, the behinder ya get.
ReplyDeleteHGA: something got lost, then. I went through one of these recently involving writing something in node.js (a dialect of Javascript). Things that got me marked down were:
ReplyDelete1. They said that they wanted 100 events randomly fired between 5 and 10 seconds. They did not specify the granularity--and I went ahead and make it fire in integer intervals.
2. There were three semicolons missing. Some Javascript interpreters are picky; others aren't. This was obviously a major reason to reject me.
3. They weren't happy that I stored the data in an array and sorted rather than sorting on the fly. There was nothing in the requirement that specified this as a goal.
And I notice that a month later, they are still advertising that you will get an interview if you complete the code sample--and I notice that they have made the requirements more specific in some of the areas that they dinged me for.
Oh well, I wasn't impressed with the business model anyway, and I suspect that they wouldn't be much of an operation to work for.
Indeed:
ReplyDelete1: That's design, actually specification (i.e. potentially their error), not coding issue (see below).
They could have down-checked you on domain knowledge ... but coding on the whiteboard in real time is not the place to do this. And unless you were claiming to have knowledge of the specific domain where this granularity would be relevant....
2: That's syntax, that's what a good editor like EMACS or a post-processor checker in the tool chain is for, especially since the code's headed for a server, not a web page (slightly longer and more involved round trip, I assume).
Given what a total freaking nightmare Javascript semicolons are, I would make damned sure the applicant was sufficiently aware of the issue, but unless he was in a job writing Javascript at that moment I wouldn't down check him unless an error was really, dangerously egregious. Whiteboard code tests are absolutely not a place to demand that level of perfection.
3: Again, design.
In the interests of brevity, I didn't mention a design test would also be included, but it was of a very different nature. Give the requirements, pencil/pen and paper, let the applicant work on it undisturbed and unmonitored for N minutes, then go over the proposed design and discuss the decisions.
The coding test is simply to make sure the person can actually code their way out of a paper bag (too many people with great resumes and references can't, in one case half of the best applicants forwarded by the best head hunter in the D.C. area in the mid-90s), and discovering that the hard way is frequently fatal to a startup.
The design test is to determine if the applicant can think, and initial differences of opinion are OK, that's what the discussion is for. The discussion among other things helps to indicate if you can work with the applicant, if you and he can converge on designs acceptable to all. Playing the "gotcha" game in this is entirely unproductive, and, yeah, they showed they weren't a place you'd likely enjoy working at.
Beau: especially with the end of the VC funded startup business model (a great run from the the late '50s when the laws were changed to the final nail in the coffin with SarBox), what you initially talk about is much less relevant. Quarterly results only matter that much if you're a public company and that's just not happening any more unless lightening strikes like with Facebook. Now the model is to stay private and organically grow or get bought out by a big and likely public company.
ReplyDeleteAs for your second point, I think it's part image, part companies just not getting it, viewing software developers as interchangeable cogs and not wanting to pay much for them (particularly bad at companies where they're a cost center vs. making the product). What can you say about a field where a handful of years of experience can get "senior" prepended to your job title and where normal, salaried jobs dry up at around age 35-40?
I have some direct knowledge of the latter, since thanks to my genes I look much younger than I am. This includes one job search where I got a clue and in the middle of it erased all evidence of exactly how old I was, and others where I e.g. slipped and mentioned working on PDP-11s, upon which the serious and older software engineer I was talking with exclaimed "Just how old are you!" since his mental model of me just went TILT ^_^.
Back when I was hiring (into the mid 90s), I would try to find out if the applicant knew the underlying principles of the technology.
ReplyDeleteThe difference between an engineer and a technician is the engineer know the physics and math behind what he's working with, while the tech just knows a few formulas and lots of heuristics.
I used to hire engineers and call the programmers.
Today they hire programmers who, even with their shiny BA or BS in CS or related, are just code monkeys. And that seems to be what they want.
I think a lot of the really successful startups do hire engineers, or at least really, really bright code monkeys.
BTW.. regarding how to measure skill... The courts have made it dangerous to measure general skills (IQ tests will get you sued, for example, even if the military uses them routinely). The courts have also made it dangerous to give an honest reference. So employers and employees are in a pickle - the anti-discimination posse has made it very hard to do the job of a hirer: discriminate between a good and a bad hire.
Since they can't check with your prior supervisors, and you can fake your resumes, is it any wonder that hiring in IT is so arbitrary? I'm not defending it, of course, because it sucks, but I do think that's part of the problem.
I also suspect this is why there are technical hot spots like silicon valley. There, with a high concentration of talent and employers, the word gets around by informal channels. People "know" who is competent who and who isn't.
It's a mess. BTW, I'm older than you and if I leave my job do not ever expect to be able to get another - the age discrimination is also insidious.