Great post. "Try different approaches. Expand your horizons. Look beyond People Like Us and imagine what the world of programming could look like in 10, 20 or even 50 years – and help us move there by hiring to make it so."
We are helping companies to do that at https://stayintech.com/. In the future people who build technology should represent the people who use it.
Happy to see someone calling out what is happening in our industry, namely: this morbid fear of "hiring the wrong candidate" is making people ... hire the wrong candidate!
A word to the hiring managers out there, look to the future, cast the vision, and onboard people who want to go there with you.
I really agree with the sentiment of audition projects. The interviews I have enjoyed the most all involved some sort of take-home project, although I have never been paid for one. On that note, how expensive does it become for a startup to dole out many interview projects across a wide range of candidates? I think a better strategy would be to conduct preliminary interviews and then based on some granularity, assign projects. One more issue I have with take home projects is that it is not always possible to tell who did the work. When it comes to interviews at startups I doubt that there would be much cheating, but for large companies where candidates are more easily able to slip through the cracks, I image this may present an issue. Can anyone speak to this experience?
While it is indeed possible to cheat on the project itself to have any value that project gets followed up with an interview in which its discussed, and I think most people would trip up quite quickly if asked to explain in detail the process of developing some software they didn't in fact write.
Exactly. Asking the candidate to outline the solution, the issues encountered, and the rationale behind the design should quickly illuminate any funny business. Depending on the scope of the project, you could even have them push code to a company repo real-time as they make progress. Obviously VCS histories can be rewritten in some circumstances, but I think it would help give a little more granularity as to how the work was done.
Here's a problem with audition projects: I would never be able to take part in one, since my current job contract has a clause forbidding me from simultaneously working for any competitor in the same field. (This is a German job contract; I don't know if such clauses are common in the US or elsewhere, too.)
So in order to work on an audition project, I'd have to be unemployed already.
Generally, I've come to believe that the 'field' that a company specifies they're in is intentionally left vague. I would assume that most people looking for a new job would more likely than not look for something in a similar industry, and be, in fact, infringing on such clauses if they did audition project work for other employers in said industry.
Talk with your solicitor. A lot of companies like to include such clauses in contracts even if they're not legally enforceable, particularly in the case of US companies operating in a country with relatively strong workers' rights like Germany.
Those clauses are really hard to enforce generally. They're effectively restraint of trade. Your time not working for your employer is your time. Your employer is on dodgy ground specifying what you can do in it. At least that's the interpretation most places I've worked (UK and Australia). Germany may be different.
But specifically if you were taking an interview rather than working a side job you could make the argument that the clause didn't apply in any case.
It all comes down to how much you pissed off your ex-employer by leaving, and how much they want revenge. No-one is going to gain anything from suing you after you've moved jobs.
I agree with other posters that same-field is usually going to be blocked anyway. I've had non-competes at 2 of my 3 jobs which would prevent me from working at any competitor in the industry for X years after quitting anway.
But my current work contract has an anti-moonlighting clause that could also be a problem. It states that I can't have other demands on my time that would interfere with my day job. Now, I interpret that as meaning I can do side projects that have no deadline and just be luxuriously slow and lazy at making progress on them. But for an audition project I probably wouldn't be able to take it that slow.
Audition project just substitute one bias for another. They also presuppose that those who will actually work with the candidate are somehow more enlightened and above bias than the standard interviewers.
That seems more like a question on how the candidate's work is measured.
While there's always some bias, I think it shifts quite a bit once you move from an artificial "interview environment" to a work environment.
Plus as has been said, since they candidates are working with the people they would be working if hired and that relationship doesn't work out, then maybe it's better to keep looking for someone else.
In my experience, those who must work with people 'on trial' hate doing so. They treat the entire experience as a chore, well aware that 90% of these people won't be around next month. That lack of commitment by the organization means those in control are only more free to express bias because they know the person at issue is already disenfranchised and weak.
In my past of applying for jobs as a designer, I had companies that would ask for take home tests. I always refused and of course didn't get the job. Conversely, other companies I worked for offered freelance positions (probation) before settling onto full time which I thought was far more effective and fair method at evaluating me as a long term candidate.
It depends on whether they can show me some of their previous work, usually in the form of pictures from past projects. Serious vendors even invite prospective clients to their stores where they will have a "demo room" showcasing their work.
If they have neither, then it's absolutely fair to ask them to do a small audition project first. Otherwise how can you be sure they're competent?
Keep in mind this idea doesn't exist just in recruitment. It's basically recruitment's version of what's called a "proof of concept", which is proof that the party that is pitching/asserting something (i.e. their skill) can actually deliver.
I got asked to do an audition project as part of an interview last year. After completing the phone interview and receiving the project, I determined that this was something that they were having trouble getting ideas for, and were simply using the interview process to jump start it. I declined to participate and told them I would look for work elsewhere.
If the project is a couple hours, then sure, I have no problem with it. When it's an entire real project for the company, you're just donating a week's work to someone in the hope of getting an offer letter.
Jeff mentions some studies of something known as 'Implicit Bias'. One of the leading Implicit Bias research institutions, out of Harvard, makes some of their tests available online. I highly recommend going through a few of them - https://implicit.harvard.edu/implicit/takeatest.html
This might be an unpopular opinion on HN, but another example of this problem manifests in the sheer volume of companies that require a HackerRank screening test these days. Apart from the clumsy web editor, recording someone under a time constraint means nothing in the larger context of how a programmer's actual work happens. Sigh.
By using such automated tests, companies want to identify top talent by taking a shortcut and not investing any time on their side.
Couldn't agree more with this. Also Codility tests in which fresh graduates do very well and more senior engineers fail, because most of the academical/theoretical/generic stuff is forgotten since it's rarely needed in the real world.
I've seen people that have solid proven development experience of more than a decade, investing time preparing for coding interviews(!). And, in a perverse way, it makes sense because they know that they are going to be asked to do something their experience has little to do with and most likely forgotten after university.
I've had to do that. Doesn't matter that I've been lead programmer on multiple projects and lead teams in developing apps that (at the time) the interviewer could download, play around with, and see my name in the credits...
Nope, we aren't even going to ask you anything about that, or let you open up your iPad and show us, here's a whiteboard, start writing up a recursive permutation algorithm (only ever had to do this in programming interviews) because we want to prove you know how to do recursive stuff (and then tell us why you should almost never use recursive solutions in our apps), oh, and how about a red-black tree (algorithms class ran out of time to cover, unneeded since), or how about coding this specific sort (heap, merge, whatever) that you'd almost never use in actuality because there are tried and true libraries that are already more efficient than you'd ever be doing it from scratch?
Ugh. Fine, you can do your test, but please don't ignore my prior experience or act like you haven't even given a cursory glance at my resume, or even worse, make a dismissive comment when I talk about it during the interview. It really is insulting. And yet half the interviews I've been in have been like this.
I always try to do, and (especially at say a Google or Facebook) it always pays off; there's always some long forgotten data structure I need for at least one of the questions.
So a more realistic test would let the candidate use Wikipedia to refresh his/her memory, but then you would need more complex questions that require demonstrating understanding, like being given a chunk of real code and applying the theoretical concept to improve it.
The context of pressure is also not the same as the pressure from meeting deadlines at work, it is now about proving yourself in some set time.
I took one of these recently, and botched one of the tests. Within 10 minutes after the timer was up, I had restarted my solution with a successful answer and was iterating on it.
The idea that the pressure is the same doesn't seem to apply to all applicants. Doing work under pressure within set times has been a strength of mine(ex. playing chess against higher rated players or when timer is low). I've noticed, however, that my skills fall apart during interviews. Once again, totally different contexts where you're being tested.
> The context of pressure is also not the same as the pressure from meeting deadlines at work, it is now about proving yourself in some set time.
I am so tired of hearing the refrain that "we want to see how you work under pressure". Anybody who thinks that all pressure or stress is the same and that you can translate performance in one stressful situation into any and every other one has no business being near a hiring decision.
People who ask for more complicated code than "reverse a string" or "fizzbuzz" in a remote code screen is doing it wrong.
People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired.
Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't code a loop in the languages on their resumes.
>A surprising number of people can't code a loop in the languages on their resumes.
I guess you can reach two conclusions from that:
1) A surprising number of applicants are totally misrepresenting their abilities – either through deceit or wild ignorance.
2) Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificial constraints, etc.
Certainly many of those applicants fall into the first bucket, but I'm betting a large portion fall into the second. So, you might reconsider whether the false negatives and highly unpleasant experience for many interviewees are worth the perceived value. Maybe there's a better way to get the same insights.
Misrepresenting abilities ... yes, I did that in my first job interview. The job posting said PHP, HTML, MySQL skills. Well, I knew HTML well enough but my PHP and MySQL skills were from a few side projects doing copy-paste-modify with PHP BB's code base to make my own web app, which I never did finish. So I only kinda/sorta knew those languages.
But then at the end of the interview I was given a coding challenge to do at home over the next few days. PHP and MySQL have good online documentation so I was able to knock it out quickly and I got the job. So, yes I misrepresented my skills, but I also knew I could live up to what I was claiming I could do.
Yes, it seems that most companies misrepresent their requirements in job postings. It also seems that most candidates misrepresent their skills in responding to those job postings. There's a certain symmetry there.
Employer: First job out of school pay, requires four years of experience in our exact tech stack.
Candidate: Sure I'm willing to take first job out of school pay (BTW, just graduated in May). Yeah, totally have 4 years of experience, and what do you know, it covers exactly your tech stack!
I actually really like the take-home coding challenge, ideally something a qualified candidate could do in 1-2 hours and inspired by a real on-the-job problem (perhaps distilled a bit). It gives me much more insight into your coding style and is a much more low key, realistic test – especially since my team is fully remote anyway.
OTOH, for example, at a certain (non-IT) company, they overblow requirements for the most junior IT posts in such a way that the ONLY people they're able to hire are people that lie about their experience/abilities on their interviews (and there's no technical interview, so they can do so at will). They're optimizing their recruiting process in a very, well, weird way.
>Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificial constraints, etc.
I've worked with people who crashed and burned during the interview during nervousness and then went on to do okay afterwards.
I'm a believer in trying to make the interview process as close an analog of day to day work as possible and as low key as possible.
That means real, actually encountered problems (no fizzbuzz), and a progressive ramping up of the difficulty so that candidates with confidence problems can have a few easy problems to get over their anxiety with before getting into something meaty.
I think it's mostly (1). The question is mostly "prove to me you've written code before". I typically let them pick their own language. I'm guessing some are fake-it-until-they-make-it and some are genuine Dunning-Krugers. The phone screen is to filter out category (1).
People that suspect they're in category (2) could come to an interview with some code samples. Personally, I'd even be OK if a (2) contacted me after the phone screen with some code samples and an explanation about what happened. Maybe we could set up another phone call and find another way to assess technical abilities.
Good development requires good communication and someone with the maturity to overcome that sort of problem will fit in well somewhere, maybe even on my team.
The one time I tried a fizzbuzz in a series of interviews, one candidate was surprised and almost insulted. At the end of the day, I learned almost nothing about any of the candidates from this question. Only one candidate (in fact, the one female candidate) implemented it substantially different than any other. All the candidates could do it. They were all CS students at a university, so what was the chance they were not going to be able to compile a program anyway? So I think you have to take fizzbuzz with a grain of salt and know when to try a more complex programming exercise.
(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)
I like gradated questions where if someone knocks my first iteration out of the park, I have several avenues to keep probing. That usually involves bringing in more concepts, not merely making the questions more complicated per se. Fizzbuzz doesn't seem to me to have an obvious avenue for bring in more concepts. It's obvious how to make it "more complicated" but not how to expand it.
I often use CSV parsing, where I specify a function that involves a simple string and I want some natural parsing of that in your favorite language. A bonus point for starting with the observation we should use a library, then do it yourself. From there I can pivot into discussing what the correct output data structure is (especially if the rows do not all have the same size or the same data types), converting text into better types, whether or not you understand unambiguously encoding text ("how can you include a comma in your field?", and I'm not worried about whether it's a "standard" answer), UTF8 and other text encoding issues, computational complexity a bit (and while small, it's a very practical, day-to-day bit) and questions of memory efficiency, the question of streaming if the dataset is too big. I can also easily pivot into outputting this CSV file into an HTML table in your favorite language, getting into HTML template issues, security issues that can arise from that, dumping the CSV into a database, and I'm probably even forgetting some of the pivots I've done. (And the point here is that I can choose, not that I ever cover all of these in one interview.) This question template scales from intern level ("can you get this string into an array of array of strings?") to senior engineer ("alas, the text encoding is varying from field to field, now what?") quite easily.
I've phone screened with this in a shared doc, too, since I can copy & paste in the problem pretty easily.
When I've seen people advocate Fizzbuzz, it's always in a context of how 90% of their candidates can't even do it. It's intended as a quick screener that immediately eliminates a ton of obviously bad candidates.
You're clearly getting a better caliber of candidate than those people are. That's great! And clearly, if that's the case, you should adjust accordingly. I think the lesson there is to tailor your process to the people you get.
I know to get away from those companies and never come back. If our values differ so much at the interview stage, it won't get any better a few months from now.
I hate technical interviews, but I completely understand the need.
However, what I cannot condone is wasting the time of 100 applicants. It takes the employer ten minutes to "sort by best" and start calling down the list.
You are 100% right about their time investment. They are saying their time is more important than yours. It is another layer that muddies the process.
"The most significant shift we’ve made is requiring every final candidate to work with us for three to eight weeks on a contract basis. Candidates do real tasks alongside the people they would actually be working with if they had the job. They can work at night or on weekends, so they don’t have to leave their current jobs; most spend 10 to 20 hours a week working with Automattic, although that’s flexible. (Some people take a week’s vacation in order to focus on the tryout, which is another viable option.) The goal is not to have them finish a product or do a set amount of work; it’s to allow us to quickly and efficiently assess whether this would be a mutually beneficial relationship."
It works well in my experience, but we have only used it at smaller scale. 2-3 days working together with somebody is already way more telling than stupid interviews, buzzword compliant skillsets and unrealistic tests.
How would it work in "your experience" if you were the job seeker and not the interviewer? Taking a week of PTO to interview and then not get the job is a pretty big sunk cost. I guess you can only do one of these a year.
If you make weekends and evenings available, it lessens the cost of the job seeker. If you allow for remote work using one of the many online collaboration tools, it lessens the cost for both the job seeker and the employer.
That would violate many people's current employment contracts that either forbid them from working for someone else simultaneously, or that assert ownership of all code written outside of work.
Or they can just walk down the street and get a job anywhere else with similar compensation with less contortion.
The people who will go through this either a) really want to work at your particular company (in which case, great, but unlikely), or b) are desperate for a job because they've been turned down several times.
>I think our industry needs to shed this old idea that it's OK, even encouraged to turn away technical candidates for anything less than absolute 100% confidence at every step of the interview process. Because when you do, you are accidentally optimizing for implicit bias.
Now you've got to spend time optimizing your interviewing team. What if one guy just says yes to everything? He might as well not be there but he's still a weight in that decision. What about the opposite where he says No every time? When do you decide he is actually going to say No every time and not worth being part of that decision process?
The more people you put on this decision table, the lower the chances that any one candidate will make it through. But there's an opportunity cost of time/money to that, so you've got another thing to balance.
I think it would be really, really hard for one person to simultaneously impress 10 people beyond a doubt just because of how many people have to reach consensus. And can you imagine the stress of knowing one dude with a nitpicky attitude (that none of the others know about yet) could sink your chances?
My team does take-home project, a small problem to solve that should take at most a couple hours. It's the same problem for every candidate so we're judging them on common work. It's not real work, it's made up.
In interviewing discussions in places like HN, there is enough pushback against this idea, which is a bit surprising to me. I thought a few hours work was reasonable when I was interviewing. But my point is that just this small bit of work seems already too big for many people, let alone working 10-20 hours a week moonlighting. It's cool that they pay for it, but that pay is pretty insignificant in the overall scheme of things. (Also, now you're not really interviewing, you're doing client work. Different relationship.)
When I have tried moonlighting in the past I found the stress incommensurate with the additional income. So I don't think I would do it as an interview, personally.
It sucks that companies take a risk during hiring. But I'm not really interested in making that my problem, as a job seeker.
I think two hours for a small take-home project is reasonable. Otherwise the applicant would spend two hours in your offices anyway, right? More than two hours, though, and I can see the problem.
It would be acceptable if the results of the project were sufficient to make a hire/no-hire decision.
If I do one two hour project, and either get an offer letter or polite refusal in response, I'd do it in a heartbeat. But no one does that. They would be fools if they did.
An anecdote is not data, but I actually did have this happen. I did a 15 minute phone chat talking about the job and a week later had a one hour online live coding session. Two weeks later, with no more contact I had a formal job offer letter in my inbox. The offer was above market rate, and the commentary in the email from the CEO said that the offer was a negotiating floor. I actually had to ask to fly into the office s(the job was remote) to meet the team and learn some more about the company and work itself.
I ended up declining the job, and they told me that the offer would _stay open_. They even got in touch with me a year later (to the day) to see if I wanted to reconsider. This was all about a year and a half ago now.
You allude to a bigger problem: anyone outside the industry who looks at the hiring process for developers would be put off. I know anecdotally that the industry is struggling to get students interested in software development as a career, and good developers are loathe to leave their jobs. I don't blame either group.
Would I want my kids to spend their careers being put through the wringer of multiple high-stakes interviews or be forced to moonlight in order to get jobs, something that gets progressively harder as people reach their thirties and gain extra responsibilities? No. Rather stay away from the field entirely and look for a more stable career.
Reading HN is really weird for me. Everyone is talking about how the industry is struggling to find new people. Meanwhile, being in Central Europe, I almost can't find a junior position to even apply to!
I am a 2nd year CS student looking for a web-dev job to get experience and learn new stuff and every ad I see requires a couple of years in the industry + knowledge of a huge amount of frameworks. From my viewpoint, there is no real need for beginner devs. Companies are looking for really experienced AND cheap programmers.
I don't disagree that we have our problems, but to me most industries seem worse to work in than ours. Not that we should stick up for ourselves but everything is terrible everywhere. Or you just don't get paid very much.
I wonder what the lifetime earnings of a new software developer/engineer would be, compared to other careers, especially for those that turn out to be non-rock stars in the medium to long term, which would be most. I suspect that the great earnings initially would plateau and be overtaken by careers where time in the game and cumulative experience are primary drivers of experience.
It depends. I have so many job offer emails that I cannot reasonably answer them all. They all want to take over your life. Talk to me, then I'll schedule interviews for you at inconvenient times. What, you didn't look this random company up and memorize facts so you'll look eager? Tsk, tsk. Read these books on interviewing. Make a github account. Practice! Why don't you practice you miserable turd?! I'm just asking that you practice for a month before I'll talk to you. Drive to SOMA and take coffee! Interview at 7pm, today! Answer your emails! Do my project! Now! No, now! Right now! Don't you want this job you never heard of until I contacted you and tried to shove it down your throat? Take some time out of your day, you miserable slacker! Do my project! Now! Answer me! I've emailed you 4 times today, and left 3 voice mails! Answer me! Now! I effed up and didn't build a team, and are already 3 months behind, why aren't you doing my bidding??!! Now! Do it! How will I get rich if you don't do what I demand?! Do it!
That's my inbox. Not too appealing.
No. Now, okay, if you are doing absolutely fantastic, ground-breaking work, and I'd be rubbing elbows with industry leaders, and I am not otherwise in the market or trying to do eleventy seven other things simultaneously maybe I'll carve some time out for your project to prove myself worthy. But, you know, most jobs are jobs. If I play the interview game I can have a handful of job offers in a week (maybe not jobs I want to do, but that's a different story). Your team might be doing it right, but do I have optics into that? Probably not.
If everything I've done in my life is not enough to convince you (generic you, not draw_down you) that I can program and solve your pedestrian problem, then I don't view me as being the problem here.
So, if your take home thing is a 2 hour project, and is in lieu of a whiteboard grilling, then fine, sounds appealing to me. But only in context, because it suggests that you don't actually have any interest in measuring my skills, which go far beyond writing for loops. So, probably not a job for me, no harm, but you know, not appealing. Sell me, I'm not a supplicant. We'll figure out if we are a good match or not, no biggie.
The reality is that the take home things are usually just yet one more requirement, one more hurdle, yet more time out of my life. And you do a few, it goes into a black hole, no one even responds, or you get a one sentence email from HR telling you piss off in the nicest way possible, and the motivation to do another goes into the toilet.
Or the reverse happens. You do really well, they bring you in, throw some brain teaser programming problem on a whiteboard, your mind goes blorp, and suddenly everyone is being aggressive and scowling, or staring at their phones, instead of talking to you. Oy vey. I'm sure it happens, but I have never had take home go well, where I didn't end up feeling like a piece of meat being graded by the USDA.
And I never thought, once, "this is a really good measure of me - good performance on this reflects my on the job performance". Yes, I can write for loops, and fix bugs, but if that all the job is it must be really boring. What do you do? Why should I want to do it? How can I help? How can I grow? How can I help you grow? I have some ideas, are you interested in them? Let's build something!
Nope, just for loops, and then iterate over this structure that should be recursed over (or vice versa) on a white board.
I program. I get jobs done, every time. The code is maintainable. I try to up the bar, not maintain the status quo. I can talk to you about all of this, and if you have a medium IQ you can tell I am not bullshitting you. What more do you reasonably want?
8 weeks of contracting. Burn your vacation. Don't talk to your kids or wife, I'm trying to get rich here off your back. Work for me! Moonlight, and risk getting ...
Your first paragraph really nails the current recruiter experience and why it's so aggravating and why I don't bother 99.5% of the time to respond anymore (assuming I'm working). The rest of your post is also gold, and I wish I could inject it into the brains of just about every person who's interviewed me in the past ten years.
One thing I find off-putting is when the project is the first stage of the interview process. It means the applicant has to invest a large amount of time upfront, while it's easy for the company to send the test over.
I prefer at least having a phone interview upfront, which suggests that the company is willing to put in some effort.
Generally speaking, this is a turn off for me, because I want to see proportional investment by the employer in the hiring process.
If I have to spend two hours doing made-up homework for you before you will even talk to me, I expect that you will then spend an equivalent amount of effort proving to me that your company is somewhere that I would like to work. If you are not willing to invest that amount of time, the whole point of the interview is to reach an arrangement wherein I give you time and you give me money, so you could pay me for those 2 hours instead.
While I don't necessarily walk away from interviews that turn me off, every warning flag does add to the minimum offer amount I would be willing to accept from the employer. If you don't treat me with professional courtesy and respect during the interview, I am silently adding numbers in my head. If you act like I am the one wasting your time, I am probably adding $20000/year to my salary expectations.
I would much rather moonlight for a few hours every week, while getting paid to do actual work, than spend even one hour doing a stupid toy homework problem that ends up being a great signal for the employer and a very poor one for me. It isn't a matter of whether the pay is significant for me, but whether the employer is making and demonstrating an effort to make the process an exchange between equals rather than a superior-inferior relationship.
There is no "the best". There are only people. Some people work wonderfully at one shop, but horribly at another. This can have nothing to do with their skill or even their personality. Each working environment is unique as is each candidate. You simply cannot tell which will work perfectly until long after someone is properly hired.
So why bother interviewing? The goal is not "we only hire the best". Hiring is only half the battle and a short term goal at most. The long term goal should be "we only retain the best". Sometimes that means firing people, but more often it means going to the mat to keep the people who work best: Treating people like human beings and, most importantly, paying them. Pay well and the good people will not leave. Actually fire those who don't work out in the long term and even they will do nearly anything to stay.
Or do what most startups do. Pay next to nothing. Treat everyone like widgets in a great machine. Fire only those whose admit having a life outside of work. And hire only those who share similar opinions on ultimate frisbee because culture!
I think there is "the best in context", and that's what people should strive for. The "best in all situations" is what most people like to chase after however.
Someone who has 20 years of knowledge in a dozen different languages doesn't matter as much if you just need someone with 2 years of very deep knowledge in one very specific language. On paper the former is "better" (even if one can learn/adapt), but in context someone who fits the latter is a better fit.
People can also learn. I'll take a junior developer over a senior developer who's an asshole any time. In a team, over time, the junior developer can more easily become an asset than the senior can change his/her ways.
For engineers a working with them to solve a real issue is pretty telling. GitLab is a young company but so far we never had to fire an engineer and I largely attribute it to this.
Totally agree that retaining is the other side of the story. We actively encourage people to tell about their life outside of work and celebrate the diversity in cultures.
The article also talks about geographic diversity which I think is a great help in getting good people to apply, we have people in 4 continents now. If we only had to hire in the bay area we can't have been as selective as we're now.
> Or do what most startups do. Pay next to nothing. Treat everyone like widgets in a great machine. Fire only those whose admit having a life outside of work. And hire only those who share similar opinions on ultimate frisbee because culture!
>There is no "the best". There are only people. Some people work wonderfully at one shop, but horribly at another.
Well, sure, but from the employer's perspective different people have differing amounts of potential productivity. You definitely want to at least limit your hiring to people who at least have the potential to be star performers.
tl;dr: The only measure of on the job performance is on the job performance. The only thing that matters to your company is also on the job performance. Why not focus on that?
It is utter voodoo.
I came up in the late 80s. Interviews were maybe 2 hours long. You might be handed a piece of paper with a problem to aggregate some information distributed in a few different arrays and print them out. You know, write some for loops and a few logic statements.
Then you talked about the job. This is the job. Do you want to do it? What do you have to bring to us? Do you have a lot of experience and want to lead, or not a lot and want to learn - we'll adjust position and salary.
And you put a team together. Some were great, some were okay, some needed to be let go. In total, all sw people had a job.
Contrast that with today's voodoo, where proxies are weighed more than on the job performance (the only thing that matters).
In the end, you put a team together. Some are great, some are okay, some need to be let go. In total, all sw people have a job.
It's all exactly the same, except the absurdity of interviewing by proxies. It's simple logic - he average of everything is average. Why have we abandoned logic?
So many things matter more than remembering red-black trees from your midterm (I'm 49. I TA'ed a graduate level algorithms class back in the day, but I don't happen to remember it. That's what books are for). Like being able to run a project. Being able to write documentation. Being able to enter a room with a combative and upset client and keep the business. Being able to mentor your colleagues. Taking ownership. Leading by example. Ability to learn. So many things that are not even discussed in the current interview environment.
I've watched companies spin their wheels for months, rejecting perfectly good people, looking for that mythical person with exactly the right, esoteric combination of skills, who, for some unknown reason, wants to stall their career and get hired into a position where they learn nothing because they are expected to know everything already. People that are eager to learn? No, sorry, not rock-star material. All these prior successes mean nothing, no one could possibly learn a technology or new algorithm, right? And, more than once I've had people get downright snide about it. I'm sorry that you misread my resume, contacted me, and I didn't have that absurdly specific combination of skills. My fault, right?
Y'all have lost your minds. :) Which is okay, we're an eccentric bunch, but jeez, let's inject some reason and introspection into it. The faces are different, but the talent is no different than the 70s and 80s. There's zero evidence that any of these interview techniques are reliable. There's tons of evidence that interview techniques are horribly biased in many ways. Just stop.
Wikiquote says this is an unsourced variant of "[I do not] carry such information in my mind since it is readily available in books" (referring to the speed of sound)
There's some information that I need to memorize (how to use git, how to write code).
There are also and other things that are in the periphery of what I need to know, but can look up easily when necessary. These include things like my mother in law's mailing address, my coworkers' phone numbers, my wife's phone number, the population of the US, how to rewire a plug socket, and the recipe for Belgian waffles.
Each of those things would be good to know, but we can effectively offload it to external memory.
There are many developers who think looked-up knowledge is the same as knowledge understood as part of a wider conceptual framework.
They become annoyed during interviews when they are asked some concept and suggest "I'd just look it up on Google", which is fine for matters of programming syntax, but not fine where it reveals that a developer does not understand an important concept.
Yeah, all that stuff is stupid. Who the fuck cares what the capital city is for each of the 50 states? That's what atlases used to be good for, now it's an almost instant search in Wikipedia.
Couldn't agree more. The "innovations" SV has brought to the interview process are more to satisfy the need to "disrupt" the traditional way of interviewing, with no thought to whether they're actually improvements. Take-home tests that are 8 hours long, talking to 14 people over 12 hours (actually happened to me), and tricky questions that will never happen in the day-to-day at that company: all useless and/or unfair.
Has it become more costly to fire bad hires since then? In my mind, a lot of the idiotic behavior in hiring is driven by the fact that it seems to be way more expensive to hire the wrong person than to hire nobody. The risk of litigation from firing someone seems real to a lot of places I've worked.
California has its own special brand of crazy laws, but in a lot of cases bad hires persist because poor managers (most) will do anything they can to avoid the confrontation.
It's an at-will state so you can leave without notice and be laid off without notice. It seems that would cover the majority of circumstances and protect both employee and employer, for better or worse.
Yes, it has. There are more legally protected classes than there were, and the laws were changed to make managers liable personally for wrongful termination.
If you're a first level manager at BigCo, the risk of getting sued outweighs the benefit to your career of getting rid of someone who needs to go.
I suspect that's why you see healthy companies doing a lot of relatively small layoffs - when your manager tells you a person on your team needs to go, you'll lay off the one you might have already fired in 1980. The result is the same, but it's a lot harder to sue over staff reductions than a firing for cause.
Startups are different, of course, because a company with only a handful of employees might go out of business if it has to carry one as dead weight.
Usually it's fear of confrontation and laziness. If you're not discriminating against people, it's fine.
I've had a few folks that I've had to let go folks, including folks in .gov with union contracts and motivated defenders. It is doable.
End of the day, don't be a wuss. Setting up some hunger games "audition" is passive aggressive bs. If you're nervous, hire a contractor and get them on the payroll later. Or just hire the person, and give them a months severance. Problem solved.
That's what my current company did with me. Works really well. Some people are not okay with becoming a contractor first but sometimes that's the way things go.
I think people (managers) have become scared of firing and so try to avoid all risk. Having had to do it is never fun, but it becomes easier the more you do. The first time I had to fire someone I tried everything I could to avoid it and made the situation worse by dragging out the whole process.
The other reason is the company is not really looking to hire, just placate their current employees - "yes we know you are over worked, just hang in there while we hire someone to take off the load".
>"yes we know you are over worked, just hang in there while we hire someone to take off the load"
Which may be why people that are below par haven't been let go? A need to throw bodies at a problem rather than step back and give it some thought / work it out.
Yes it is certainly true that it hard to fire anyone when you are pretending to be looking to expand - nothing breaks the spell that all the hard work is just a consequence of not being able to hire like firing a member of the team.
I recently had an on-site interview at a big SV tech company. I had 4 interviews and 3 of them flat out told me they haven't read my resume. I didn't do as well on the whiteboard hazing but I'm confident that I could have solved them if I had more than 30 minutes to come up with an efficient solution.
What disappointed me was, 3 of the interviewers had no idea about my background and weren't able to extract my strengths. Even though I am a new grad, I have interned for 2 years as an app dev and learned a great deal about design, code quality, testing and etc...
I have read Effective Java, Clean Code, and Head First Design Patterns. I'm reading Java 8 in Action now. I have not memorized them page-to-page and still need more experience to master them, but at least I know some of resources I can go to for more answers. I have participated in code reviews and enjoy them. I can implement LLRBT and many of the algorithms you can expect a new grad to know but I have not invested my time on hacker rank and uva.
I don't know what SV or big tech companies are looking for. I constantly hear interviewers say they want good engineers but fail to capture the essence of a potential good engineer well. What benefit is there in hazing anyone with problems many engineers don't deal with without the tools they use every day, and with an absurd time constraint. Kosaraju didn't come up with SCC in 30 minutes and he had a PHD. Sure I can spend hours studying for whiteboard questions but to what benefit. I am sure anyone of you can come up with a whiteboard problem you can't solve in 30 minutes, but what does that say about you.
If you want to get a job as an app developer, the easiest way is to build the kind of app you'd like to work on and show it to people. If an interviewer sees that you can deliver exactly what they need, you're an instant hire.
Don't complain that interviewers haven't read your resume; it is your job to tell the interviewer about the relevant parts of your resume and why they matter for the job you are applying to.
Don't complain that interviewers haven't read your resume
I disagree. If you're going to interview me for an hour, the least you can do for both of us is to take 10 or 15 minutes ahead of time to familiarize yourself with my background.
it is your job to tell the interviewer about the relevant parts of your resume
Again, I disagree. A resume is only a very cursory overview. You can use it as a starting point to probe me about it, to at least determine if I've actually done what it says or if I'm just a buzzword bullshit artist.
IMO it's very shortsighted for someone to ignore a resume before conducting an interview.
I agree that it is inpolite to not read a resume or a cover letter. But as a candidate, you can't change the fact that your interviewer is not well prepared. The job will go to the candidate that makes the best of the situation.
The bigger point I'm trying to get at is the following: do not expect the interviewer to discover how brilliant you are on their own. Being smart, hard working, is not enough -- you also need to tell people about it.
The first interviewer told me they haven't read my resume at the beginning of my interview. I tried to highlight my strengths. The other 2 tho told me during the conclusion of the interview, when I asked them what skills they'd want to me focus on if I was to start on their team or any advice for a budding engineer. They both started with something along the lines, I don't know your background; didn't get the chance to read your resume. It was too late to go over my resume as I was being escorted to my next event.
I will be more proactive on my next interviews. I did have my github on my resume; I will add more projects to it and get involved in OSS.
Stop thinking of your career like a textbook. You don't need to memorize all that bullshit. Just provide value to the world and the rest will come naturally.
I really like this post, that most companies require workers to be at a specific location is very strange considering our type of work.
I don't want to work in Sillicon Valley, even if the work is interesting. I live in Scandinavia and for me scandinavian countries are the best to live in the world.
It boils down to 2 things: Management is incompetent to tell when work is actually being done, and management doesn't trust their employees. I'm just waiting for the day when requiring on-site commutes is regarded as backwards as it deserves.
I don't know first hand, but I suspect that I'd rather be shot at dawn than live in a Scandinavian country. I tried Canada for a while ( temporary posting due to acquisition) and it just didn't work.
You're used to that, and in a "measurable" way, it's semi-objectively true but it's not for everybody. I think it mainly was that I missed the sheer insanity of America where it is insane. It's something akin to codependency.
And given all that, I'd rather live in a Scandinavian country than SiVa.
Rather be shot down than live in Scandinavia? May I ask why?
We have free healthcare, free education and a good work-life balance. We have 5 weeks of vacation by law. We have parental leave, a lot of it and you may still earn a lot of money. A friend of mine took 9 months of parental leave when he got a child.
Sweden for example has more billionaires per capita then the US. Norway have so much money in their oil-fund that they could pay every Norwegian 1 million NOK and still have money left. We're safe from any storms, earthquakes and basically all natural catastrophes. The most dangerous animal is pretty much the moose. Environmental issues will hit Scandinavian countries very late compared with the US.
I work in the "boring" old insurance industry, based in the midwest. I love reading articles like these, and as I read them I get excited and say to myself "yea!" and "spot on!". But they seem to center around startups and Silicon Valley.
The truth is, when it comes to building, maintaining, and supporting internal, line of business apps, management isn't even pretending to look for high end talent. They want predictability, reliability, and someone who will "fit".
I wonder how many people out there fit my profile. That is, they get excited by reading blog posts like these from some of the thought leaders, and desperately want to apply the thinking to their own workplaces, but then feel like we aren't really the target audience.
I had a job like that once, and it was clear to me I didn't fit there for a variety of reasons so I left because I wanted to make a difference at my job and not be a "resource". I then got a job at a "stable" startup working remotely for twice the pay that the boring industry would pay.
No need to create a throw-away account to share your personal experience.
I've worked in traditionally boring industries that treated programmers as resources to be allocated (healthcare, logistics). Sometimes it's still possible to make a difference. For example the logistics job I had, we were often the only development resources our clients had, so when they wanted to run a promotion or do something like that, our execution could literally make or break their business.
HN obviously has a large bias toward content that is relevant in Silicon Valley (understandably so). This makes it fairly likely that the content that is only relevant to SV still makes its way to the top of the front page from time to time.
It may be counter-intuitive, but I find it easier to apply these types of articles to my non-programming work. My wife and I own a gym, and we need to hire personal trainers from time to time. There's a certifying body for that, so it's easy to know if someone is trivially "qualified" for the job. Are we trying to hire the top 1% of trainers in the country? No, we're at best a medium-sized location for our area. Largely what we look for when hiring is how they will fit in with the existing coaching staff, how they will fit in with our existing clientele, and how likely they are to attract new clientele (or bring with them).
You also highlight that there are a lot of jobs out there where you're basically hiring for competence (which includes being dependable, not being difficult to work with) at the right price. There are a lot of professions where, for the mainstream jobs, there really isn't a lot of payback in "greatness."
Yep, me too, midwest huge insurance company. From what I've seen, there are very few people in mid to upper management that think developers are anything more than a cog in the machine (and only 1 who's ever stated that 'publicly') - I'm looking to leave after 11 years - I've given up on it changing.
2 and a half years also feels too long to me. But in order to not look like a "job hopper" is that the standard time I should expect to stay at a place or is 1 year good enough.
It was too long but of course I didn't realize it at the time. From what I've gathered, as long as it isn't with every job, you don't have to stay that long.
But don't take my career advice. I only really know what not to do at this point.
I moved around in the company, trying to find someplace that was different (e.g. more like a software company) - and I finally did, about 4.5 years ago. The department was outside of the official IT department, because we are vital to the business and have legal reasons to need to move much faster. It was good for a couple of years, but recently, the area I'm in has been getting more like the IT department I left (they are pushing me and other leads to start taking on more "leadership" responsibilities - meaning management type crap, not lead developer) - so I think it's time to move on.
And I should mention that I've looked for other jobs in the area (trying to stay local because of family) - and almost no one pays as good as where I'm at. I'm making a bit above average according to Glassdoor (for my location).
I tried the midwest large insurance company job, and it was not a fun experience. I often had full weeks where I was waiting on something from other slow-moving departments and had literally nothing to do, and my boss knew and didn't really care, although I still had to show up and sit in my desk for eight hours a day.
And I was a developer but had to ask permission and make a case for every single program I wanted to install to help do my job, which isn't necessarily bad (there are understandable security concerns with downloaded software from the internet), except when Net Ops rates it a low priority and takes weeks to give you the permission. I eventually just stopped asking.
The atmosphere was also the most subdued environment I've ever been in. Most people not talking to or acknowledging each other unless their cubes were near, very few jokes, I almost got the feeling I'd get in trouble if I ever showed exuberance.
Not that I ever felt like it anyway. The lighting didn't help with that either, since we were in a room with very little natural light and soft florescent lighting that made it difficult for me to even stay awake there.
I did learn some new things there, and people were polite and friendly, so it wasn't all bad, but I'd never go back.
> The atmosphere was also the most subdued environment I've ever been in. Most people not talking to or acknowledging each other unless their cubes were near, very few jokes, I almost got the feeling I'd get in trouble if I ever showed exuberance.
I know exactly what you mean! It is suffocating! Currently struggling with this right now. I can't stand it because it just feels so fake and phony. To me work is easier and more manageable when you are getting along with colleagues, not when it is overly formal, and corporate, etc.
Yeah, fake and phony, I definitely got that feeling. Like people were putting on a mask the entire time they were there.
I don't even mind corporate necessarily, as long as it's relaxed. My current place people will talk about pretty much whatever, help each other out, tease each other about things, the boss will join us for lunch and talk about Star Wars and Deadpool, team leads are willing to admit that they can make mistakes, you feel like you can be more open and honest around your superiors, no one gasps or blinks an eye when you casually curse, etc.
And yet it's not quite no-holds-barred like a previous job that erupted into nerf gun battles and openly (but not seriously) insulting each other on an almost daily basis.
Relate to both of your points. Being disrespectful and straight up insulting others shouldn't be acceptable, but having too stuffy a working atmosphere creates this feeling like you are walking on egg shells which in my opinion is not conducive to effective and productive work.
But I wonder who it is that sets the culture or tone of a workplace. Is it every employee in concert or more management / the team leads / bosses etc?
As stated several times over the years, particularly on HN and by patio11 (edit: or was it Joel on Software? Perhaps both?), work for a profit center not a cost center. The internal software to run insurance companies is a cost center. It is in managements interest to reduce and keep costs down... that's detrimental to what you do. Working on a software product or Saas is a profit center. What you are making is to be sold. It's an asset. An asset management wants to make as valuable and profitable as possible so they are willing to invest in it. That works to your favor if you're developing that asset.
Yeah, hear ya. Anyone know of any opportunities that match this criteria (profit center) in the Columbus, OH area? I've recently moved here for family reasons, and while there seem to be plenty of opportunities, they are all within the banking, healthcare, insurance verticals, or they are shrouded in mystery behind middleman tech agents. I have not found an easy way to do a search on indeed.com to bring the "profit center" jobs to the forefront.
The majority of "profit center" software and software jobs are on the west coast surrounded around the tech giants and the bustling startups. I believe Austin Texas has a few and so does New York. As for the rest of the country... it's hit or miss. Some of the large(r) Midwest cities will have a software company that has "profit center" software and jobs. I'm further West than you but I know some companies in Madison, Des Moines, La Crosse, Rochester, Decorah exist. Being in smaller markets they don't tend to pay as well $ for $ but when you factor in COLA and QOL they are hard to beat. I know some people that live near me that work remotely for Walmart Labs and make a substantially lot more money. Appleton/Green Bay/Wausau have a lot of insurance software jobs too... the type we seem to want to avoid. I'm not sure what the rust belt has to offer. The best place to look for "profit center" positions is the monthly "Who's Hiring on HN" lists and if you can't/don't want to relocate look for ones that allow remoting. Good luck.
Not sure it's that simple. For example, in many places banks pay the most. Sure, they pay even more to their earners (traders, dealmakers etc.), but they make so much money on their business in general that they can shell out top dollars even for their digital janitors. Contrast that with places where you work on products such as computer vision-based gizmos, CAD software etc - even though you're bringing in the profit there, the pay is not that great.
In addition to my previous comment, I'd like to hear people's thoughts on the "consulting" gig. It seems to rule here. You know the routine. Consulting shop places an individual at a client site and charges the client $100 an hour, and then turns around and gives the consultant less than half of it. I can see the argument of the consulting firm viewing their people both as profit centers and cost centers.
Why are they even called "consulting" firms? They are really just contracting agencies. And why are they so prevalent in the midwest and the insurance/banking/healthcare segments? Is it so that employers don't have to lay people off? Do they record the costs differently on their books versus full time employees? It just seems so obviously not in the interest of a company to use them with regards to culture, turnover, cost.
My last consulting firm accounted their consultant salaries as a cost center, despite our hours worked being directly billed to the client. I left about two weeks after finding out.
It was many. The numbers the company provided to me failed to account for a significant portion of my billed revenue. Presumably the missing money made it to the top level in some way.
I also objected to the idea that someone who directly generates revenue was being labeled a cost center. I left, as did my junior consultant, and shortly after the company failed to gain ongoing contracts at the very large financial services corporation they were trying to break in to.
My main problem with that job however, was that they recruited me as a greenfield .NET developer, but then had me analysing some 800 columns over dozens of tables looking for software errors that were causing incorrect results in the 401k accounts for which our client was the steward.
I use to be in the enterprise "consulting" gig. As a consultant its terrible. The only rate you know is what you are making, and thats just at the per year level. As the consultant you never know what is being changed to the client and so you never know your actual worth. Rates are probably the closest guarded secret for consulting firms. Plus you are a profit center to the consulting company but a cost center to the client. So there is the horrible pull between your management to "maximize the billable hour" and the client wanting to keep costs on the project down. Oh, and god forbid you are on a flat rate project where the only limit is time. Be prepared to work 80hrs and have no life.
I've seen two reasons why mega insurance company inc brings in "consultants." One is the consultant is specialized in an area of tech that is completely outside of the companies expertise. I did some of this being in a niche area of enterprise security. While those contracts still suck they suck a little less because you are at least advising the company and getting them up to speed on something. The other type, and the most common type is the "staff augmentation". I've been on those projects too and its exactly how they seem. The company has some in house knowledge (say a manager of infrastructure and maybe one full time employee for that tech) but the rest is really about throwing bodies at a project. From the client's perspective its all about workforce flexibility and not having the expense of a full time employee on the books. Even at like 100/hr its cheaper I guess for them vs having a full time employee. Plus its not their "core business" although in 2016 I'd argue if you are running a company it's insane not to think of tech as part of your "core business."
Overall, between the unsteady work, travel, etc being an enterprise consultant sucks. Most people that I know go into it because the potential to make a bit more money vs a traditional job at mega insurance company inc is there and they don't like the idea of working for mega insurance company inc for years. However, I've been on contracts where the project is like two years long so you might as well be working for mega insurance company inc anyway.
Honestly, there's a lot of confusion (and overloading, to use OOP parlance) with the term "contractor", and confusion with the term "consultant".
For instance, you can be a "contractor" as a software engineer, where you sign an employment contract to work for 6 or 12 months at a client site, working through an employment agency. At the end of that term, either your contract is renewed or it is not and you're now unemployed.
Or, in the defense industry, you can work as a "contractor" where you're a full-time employee of some company (called a "defense contractor"). That company signs a contract with the government to do some work for them somehow, and you're assigned to do this work. Your work does not have a defined end date (like the 6-month contract you might get to work at some big commercial company), you're just a regular full-time employee, but you still have to track your time (so it can be billed to that government contract), and if something goes wrong with the contract (like it runs out of money), then you can suddenly, with little warning, be furloughed without any pay.
Of course, there's many other kinds of "contractors" too, like the guy you hire to replace your house's roof. And there's all the people who are full-time workers, but are given 1099 forms as classified as "independent contractors" so their employer doesn't have to pay FICA and unemployment insurance for them.
Now, as for "consultants", that usually seems to be pretty much what I described in the part about defense contracting: you're a regular W-2 employee of some corporation, but you're sent out to client sites to do work for them, though there's no fixed-term contract with the client usually.
Almost everyone working in enterprise software is in your same boat. In fact, I'd argue the great majority of software developers outside Silicon Valley are either working for or with enterprise stacks and products & services. Sure, there's indie game developers and some boutique software shops working on small sites, but fundamentally most of their customers are businesses involved in FIRE (finance, insurance, real estate) business verticals or healthcare.
Also: Give the "not-the-best" people a chance to develop.
The CEO of one of my past clients, a consulting company, always said: "You can teach everyone to be a great programmer". And he put his money where his mouth was: He hired people with no programming experience (even with no university education) and personally trained them for several months. Also, senior people in the company were encouraged to also help them and guid them.
He had to fire some of those people later, mostly because they were not a good fit for the company. But some of them became great programmers and software consultants.
"Hire only the best" is really only half of the battle. Give people an environment where learning is encouraged and failure is expected. And help them wherever you can. Most will learn and enjoy it.
I am a big believer that companies underestimate people's ability to learn, but what you describe works well if the company is stable and has little growth - a perfectly fine situation to be in - but I think the majority of startups don't have this kind of stability, and need someone who has the right skills now for whatever they need (building a new service, scaling the backend, tweaking the frontend, porting their product to mobile, etc.), so they can't really afford to do that long term mentoring.
That's probably true for a lot of startups. If you have problems scaling your $language services right now, then you need somebody who can scale $language services.
OTOH, I recently had an interview at a company who have quite a bit of groth and scaling problems right now (but probably not Silicon Valley level), and they still said: "We constantly have to learn new things, so the most important thing a candidate has to have is they have to enjoy learning new things".
AND: there are quite a lot of companies who are in the stable / profitable / predictable growth category and could afford to train/develop their people - But don't.
I dunno from web stuff, really, but none of that sounds like rocket surgery ( because I don't know what I am talking about, you see - this always makes everything easier ). Of the list, "scaling the backend" sounds the riskiest because the tools landscape is very fragmented.
Then again, a person with whom I went to college is a recognized expert on Oracle performance. I find it keenly interesting that such a role even exists.
I look at startup-ey, Webby looking job postings and it's like the qualified people drew to several consecutive inside straights just to have the right buzzwords on their resume. And it's a different set of inside straights than it was six months ago. And it's different yet from firm to firm.
See there how easy it is when you don't know what you're talking about? :)
I always wonder if they actually are a pain to work with.
I've worked from outside the hull speed of several teams and gotten into places where being diplomatic about the sheer propensity to failure was a lot of what I ended up doing. And, frankly, I've just dropped the mic and walked off more than once, once I'd established that the team ultimately just didn't want to perform or had some horrifying external constraint that made the death march inevitable.
Say it with me: "I am powerless over the fact that I suck." At least you can work on the self loathing and make progress.
But seriously - get your ego out of it and life gets better. Let your ego free only when you are alone. You can't fix 'em all.
This is seriously one of the best comments I've read on HN in a long time. I've always had this same inclination, just never had the time to try it myself. If your current environment doesn't allow you to hire inexperienced/no-education people, you can at least work with juniors more to help elevate them (and in turn the entire team). This concept goes way beyond tech as well and can be applied to many many industries
The economics are usually way out of whack though. In my experience, a good programmer is easily worth 5x a "not-so-good" programmer and rarely costs more than 2x as much.
We do have a college intern and hire program, but it's very rare for a new college hire to have the same ROI as my best experienced colleagues.
I would add one proviso, that training can only occur where a company already has someone capable of teaching. A raw recruit may do well if they are trained, but someone has to train them. Most startups seem looking to hire skills rather than people. They want to bring in skills nobody already on board has. Without any form of mentor, the raw recruit will always fail.
My big issue: Startup hiring kids to do work that should be in the hands of lawyers. I've seen interns redlining contracts and social media directors heading compliance teams. Some expertise cannot be developed in-house.
> training can only occur where a company already has someone capable of teaching
Is that true? Maybe for a subset of people, and (union) a subset of the skills. But one can surely improve their knowledge in an environment where there is nobody able to teach him. The environment must support a few failures, because they'll happen, but it is possible.
This works less well when you have only 4 people. I've worked on both kinds of teams and done extensive training and have often pushed to hire people who want to learn over people who know.
Most times, the premise of a start up is that 2-4 people with well developed non overlapping skills get together and build something with each being such an integral part that they are worth a good chunk of equity. Perhaps 5/6 is a CS person that you train as OPs / Dev on the side. But most companies don't have the time or man power until the team gets into the double digits.
On the other hand, if you want to build a pipeline to solve tomorrows hiring problems, go out and interview unskilled people that want to do the job you have. There's some wash out but generally you can make a pretty good batch of people. I've done this in a couple places and it can be very rewarding not to mention as they start to develop and move out to other teams they are often willing to spend some time giving back to the program that helped them up on the ladder. Which means that you have more eyes and hands helping develop people and more time for coffee.
Also, have a look at "Developer's Journey" by Tim Bourguignon - There he tries to find out how to train/mentor/coach people to become great developers. And also what developers can do themselves to improve.
A really good strategy which is unfornately not very common. For one part because of the topic of the article, but for the second part because many companies seem to think that their employees will be hired away by their competitors at the first opportunity, which basically says that they do not trust themselves to be good enough to retain their employees .. but if these companies do not trust themselves how can their customers trust them?
You are right, that is the third component, but hiring is also very expensive, especially if you have a low quote of acceptance and have to interview many candidates for each position.
Good point. Not sure which is more expensive, and it obviously depends on your problem space and the stakes involved (i.e. crud apps vs financials vs health care).
You really can't - but it doesn't matter. This has nothing to do with programming specifically.
You can train most people to do most tasks. With a modicum of natural inclination, competent. With a bit of interest, good. With a willingness to work hard, very good.
However, you can't ever train greatness. You can't make it by any method - only they can.
Your broader point is good though. The most predictably effective way to end up with top talent that works well in your structure is to help it develop.
I would argue it is the exact opposite. On day one name a programming language, important libraries and whatnot and hand out a stack of documents explaining the problem domain. The new guy hasn't necessarily seen or heard about anything of that before. If he can compete with your other good developers after a month, you have found a great programmer. I mean of course if he can do this repeatedly, not that he just was a pretty good fit for the requirements by sheer luck.
I think there is a rough consensus of what "great" means in "a great X" and that it means something like: generally accepted to be significantly better than the vast majority of their peers. Otherwise the adjective becomes meaningless.
You will not meet such people very often unless you are in a truly extraordinary situation, which means you may well never work with one.
My argument is that such people, whatever the field of endeavor, do not ever become great through training alone. You can only develop the conditions for people to reach their full potential, and hope that some (small number) of them truly become great.
> "I think there is a rough consensus of what "great" means in "a great X" and that it means something like: generally accepted to be significantly better than the vast majority of their peers."
You've not really solved the problem by stating that, all you've done is swap one subjective term (great) for another (better).
FWIW, I don't think everyone is naturally suited to programming, but I do know I've met a number of people, with a diverse range of backgrounds, who I am confident would be employable as programmers with the right guidance. The two biggest traits they all share is attention to detail and an openness to learn. I'd argue that's all you really need, everything else is just a matter of effort and experience.
Well, sure, we are deeply into an inherently subjective area.
But I believe you are being obtuse here. I've never met a large group of programmers who wouldn't have rough consensus on their "better" colleagues. Begrudgingly, perhaps, but it is there. Human beings naturally self-organize this way all of the time, the metrics are definitely imperfect but pretending they don't exist or are somehow meaningless is just perverse.
Nothing I said claims that diverse people cannot become perfectly competent programmers, this is certainly true.
The claim was more that "greatness" in part, at least, necessarily comes from within.
> "The claim was more that "greatness" in part, at least, necessarily comes from within."
That goes into the whole nature vs. nurture debate, and you can probably find arguments for both. Playing Devil's Advocate, I'd suggest there are traits that help you become a great programmer, but those can be learned traits. For example, "thinking like a machine". You're a much more effective programmer after you can build a mental model of how the programs you write are working at a lower level of abstraction than the one you're programming in. That's something it's undeniably possible to learn, the main barrier for most people is a lack of interest. You have to be prepared to learn a bunch of supporting material that may not pay off in the near future, but will help you in the long run. That's my experience of what it takes to become good/great/better at nearly anything.
If they are interested, you can - but probably not in an ... affordable amount of time.
What's desired is that our company have the best talent, but that someone else develop it for us. We'll pay the maintenance fee at a high level but we won't actually invest in it.
This is a simple problem - we know the cost of everything but the value of nothing. And then we begin to redefine "best" down to make it easier to measure.
The best organizations "grow" their talent in addition to "finding" it.
Talent is not a resource which merely exists out in the wild like some kind of unicorn. Talent is DEVELOPED in the right environments with the right team and the right resources.
Large companies especially, need to take a bit more responsibility for cultivating talented people instead of merely project-managing "resources" ad-nauseum, and then finding increasingly elaborate ways to find and recruit talent.
They don't just "grow" new talent, they "manage" existing talent to higher levels of productivity. In my life, I've observed huge differences in my own productivity in different working environment.
Both ways (grow and manage), though, I find the notion of "find the best, set them free, done" is insufficient.
I tell you true: when I look back on my career so far, I'm most proud of the work I did helping people climb that hill.
Most of the code I've written, even the best of it, is long gone. The company died, the system eventually got replaced, the business needs changed. I've debugged some epic problems through herculean efforts, but in retrospect most of those problems shouldn't have even existed; bad work process created bad results. I created some great system architectures, but technology advances so rapidly that the great solution of 10 years ago is now sadly out of date.
But getting some non-developer hooked on development? The shine on that doesn't wear off. Taking somebody who's struggling and helping them become a solid contributor? I'll always be proud of that.
Flat out dead wrong. If you hire "anyone" and try to teach them to be a programmer then you will probably fire them.
This is the sort of attitude that leads companies to outsource their development overseas: "Our programmers are people hitting keys. We'll get overseas people to hit keys and overseas people hit keys for less money.", cause, you know, anyone can do it.
Programming is VERY hard and it takes a huge amount of motivation and hard work to become any good at it. Sure you can learn how to do simple stuff without any serious interest, but to be beyond ordinary it takes enormous work and time and research and Joe Schlepp off the street is simply not going to do that.
If you want to hire people and teach them then you need to look for these things: enthusiasm for computers and programming, demonstrated willingness to learn, energy and effort. You should value energy and effort more highly than anything. Those are the raw ingredients for trainees, and people with those ingredients are far from "anyone".
My first job hired me with zero programming experience because they thought this. I like to think I turned out ok, but I strongly disagree with the sentiment. A more accurate statement would be "You can train most people to be relatively competent at average programming tasks."
People who want to feel insulted always find ways to feel insulted.
If you choose to read my comment that way then you are choosing to hear the message that you want to hear, which is a reflection of you and your personal issues.
My comment in no way suggested that overseas developers are incompetent - in fact whether or not a developer is competent has little to do with where they live - although economic opportunity is part of the equation. Great programmers create themselves by hard work and that has nothing to do with location.
Another case of hostility masked as objectivity on HN. You are entitled to your opinion, but it seems like you are justifying your position in life more so than providing anything of value to the conversation.
I do agree with you however in that there is a difference between greatness and adequacy
You know what the irony is? Us programmers thinking that "everyone can be a great programmer" is our preponderant liberal and very idealistic views showing.
And we keep going around and shout that and other people believe it. And in turn we are being taken advantage of with long hours, unfair compensation for our contributions and the worse of it all? Ageism in our industry is rampant.
I look at physicians, surgeons, accountants, lawyers and others with envy, because in those professions, the older you get, the more esteemed and valuable you are. We peak at 30.
To be honest I think the statement should be "anyone can learn to program". To be a great programmer requires many things to align, and mental disorders count as well. A combination of mild autism and mild depression (melancholy?), social isolation and environment in general I think is necessary, but tip the balance in either direction and things start to get real shitty real quick.
I'm not 100% sure what you mean by "market worth." Do you mean salary? Because if so, no.
Do you mean something like "net value to company"? Then maybe. Another way to say that would be "you start to get paid what you're worth after 30 or 35."
I'm mid 30's and the salary cap is what I'm experiencing. Inversely, many of my friends in business, law, medical, etc. made less than I throughout their 20's and have now caught up, with potentials to earn far more.
For example, the lawyers I know are now making partner in firms, the business majors getting percentages based on sales and earnings.
I'm looking to become a consultant but the very idea of increasing pay with experience is foreign in the tech field, but standard in other professional trades. I believe offshoring, H1Bs, and lack of a professional association (AMA, bar, etc) is to blame.
I'm also about 50. I am doing far more senior and interesting work than I was doing when I was 30. I felt like I was just starting to figuring things out then, but now I'm doing way more interesting arch and design for work involving a large team.I had great experience earlier in my career working at large, well respected companies.
At 30 I was just getting started. If you feel you peeked, find some new jobs and technologies that you'd like to have on your resume and find new jobs. How about java and distributed systems at a place like google or facebook, c++ on a major database? Look for those things.
I was only referring to salaries regardless of technologies used. In my relatively expensive US city I do not see any companies willing to pay more than about $150k for a senior dev. This is similar to what I see in most cities, and there are not many companies giving stock options as is common at Google, Facebook, etc.
The question is: you've been doing higher level work, but has your compensation flatlined?
Flattened? Probably not, it's slightly higher salary, like 5%, but it's not enough time for my stock grants to vest and show a clear trajectory.
I left one of the big internet superstars, and tried a startup. After a year I decided it wasn't going anywhere, so I went to a medium sized company that is really growing. I make slightly more in salary than i did at my internet superstar company, and more $ value in stock grants. My new company is growing so the stock should go up, but its less certain too. My job title looks good, so I will be able to use that in my 'next' job, if there is one; maybe I'll stay here forever. My goal is $400-$500k per year in salary and stock, over a 5 year average. Say you get about 200k in salary, and you get an initial 4 year stock grant, and each year they give you another 4 year one, so it takes several years of that to overlap.
I am probably going on too much, but I really want people not to believe some ridiculous story about being washed up at 30. Learn something new, people! Before you take a job, look at your resume and see what your career trajectory is. Do you work places and go after a year (this can be bad)? Do you have a substantial time period at a strong company? Can you talk about why you left each company? What can you contribute?
I was more than 10 years at Microsoft, mostly IC and some lead work, and then back to being an IC at the internet giant, then lead at a startup, now mixed design and dev at the new company; i was hired on dev skills plus experience.
$150k in stock and salary is reasonable for an experienced dev, say 10 years. At the startup we paid mid career good devs 150k in salary, plus worthless options. A typical deal for devs with 10+ years who can do c++, java, distributed programming is 150-175k in salary, a couple 100k in stock, paid over 4 years, plus new grants each year. 2 years ago when twitter was doing better I got almost 200k in salary, plus double that in stock, payable over 4 years.
The unadorned "developer/engineer" role[1] -- that is to say, not CTO or even Lead Engineer -- itself seems to tap out after 8-10 years, in terms of both salary and respect.
That is, in the average case, anyway. There are of course companies which pay upper-tranche (in terms of salary and respect) for very highly talented programmers who aren't in leadership or crossover roles. But these are a comparatively rarified stratum; by and large -- for the great majority of companies out there -- the "Senior Developer / Engineer" role definitely seems to plateau within about that timeframe.
So if you don't find yourself drawn to that category of engineer (and to those kinds of companies -- many truly gifted programmers I've known still pull down decidedly average salaries) -- and you find yourself wanting more salary (or respect / responsibility) -- you better start thinking of something else.
[1] Leaving aside distinctions between "developer" and "engineer", as discussed elsewhere recently, for the sake of simplicity.
Software engineers who "peak at 30" are not taking care of their careers. I'm over 50, haven't worked a full year anywhere in years. I contract or consult, and can usually find a new job lead in hours (or just deal with one of the many sitting in my inbox), and get hired in one (max two) interviews. And it's not because I'm a rocket surgeon. I know lots of software people who are eminently employable in their 50s and 60s.
A critical problem that exaggerates the "ageism" is people who sit in the same corporation for 15-20 years, get laid off because companies change, and haven't refreshed their skills for many years. I saw my spouse go through this last year. She got laid off from the company where she'd worked in a variety of roles for 13 years. Her field toward the end was product management/ownership, and she liked it, but she didn't like Agile - she'd had bad experiences at her employer with careless engineers using "agile" as an excuse to have no process and no oversight. She had also spent many years developing deep domain experience in a narrow specialty (international e-commerce). She could find generic PM jobs easily enough, but they didn't exercise her domain experience and they didn't want to pay her what she'd been making just to be a generic PM. It took her six months to find a new job that uses her domain expertise (educating herself about Agile along the way).
For people less determined and hardworking than her, the problem can easily be much worse. If you've done nothing but Microfocus Cobol for the past 20 years and suddenly have to find a new job because you employer finally ditched that antique piece of crap, and you aren't interested in learning how to do something modern, you're in a world of hurt.
Agile as a developer excuse "to have no process and no oversight"?
That was a satori moment for me, now I get the point that agile (and probably most other processes) can be forged into just about anything with a bit of bad will: I've seen the opposite, that is SCRUM used for micromanagement by a boss with control problems.
If you are not interested in learning something new you pretty much deserve to be in a world of hurt. In this business you can stay relevant into your 80's if you never, ever, stop learning and honing your skills. Peaking at 30 is pure BS.
Some people stay in a job for 15-20 years. They are a programmer for maybe 10 of those, but over time they grow into a niche, the company grows, and that becomes a job title.
Maybe they get called a project manager, or a product owner, head of QA or engineering or lead architect. Either way they aren't a programmer any more and they mostly manage something instead of doing - manage people, contracts, processes, customers...
And that's why programming has a pay ceiling - careerist programmers become something else, and footloose programmers become consultants and contractors and leave the regular pay figures.
The value of a good programmer probably becomes diminishing returns after a certain point. The best programmer in the world can't raise the sales of your web app past a point - if they do what it takes to do that they become something else, like a product manager. That point depends on the technical difficulty of the task and the size of the opportunity, but most code needs a good coder, not a great one, and beyond that it's all product fit, sales and luck.
I'm footloose too, and I'm noticing as I get older that the people interviewing me have often been in their job a long time. They bet on the company and became less flexible in the general labor market in return for better opportunities internally.
Honestly, when I work for them, I'm usually surprised how many normal things they don't know. Maybe they've never seen proper unit testing, or don't know what ITIL is, or think linux is still an immature product and you should stay safe with a microsoft stack.
But they know why the code is the way it is. They know what was tried in the past, and how it failed. And their boss has seen what they do in a crisis, which is much better than trusting someone unpredictable.
My suggestion to someone young, if you have the temperament, is to stay for up to a decade and grow into a new, higher value role. Then learn that until you know it well enough to get a job elsewhere and move before you stagnate.
In my case, when I was 30 I was looking at my first great learning job at Microsoft. I was working on an awesome distributed project, learning a lot, doing fantastic c++ work, making good connections. I was a dev for a few years, then a lead. Shipped some good stuff.
Then in my 40s I went back to being a dev and learned a bunch of cool stuff at one of the amazons, googles, facebooks of the world. Now I'm 50 and have another great job, get tired of replying to recruiters.
Look for jobs that teach you great stuff, expand on the important tech skills you don't have, pay well, and look good on your resume.
"Everyone" here I think means the same as "anyone can be a great cook" in Ratatuille - it does not mean that anyone can learn to cook - but that a good programmer can arise from any background.
My experience would support this. You need a mindset keen towards rigor, and motivation. Given those, and guidance, anyone can learn to program - at least in limited contexts.
I agree. My friend was a barista with a philosophy degree. But he had the intelligence, the rigor, and the desire to learn. All I had to do was point him in a couple of directions and he picked up programming very quickly on his own with no prior experience. In fact, I would say he's far better at it than me even after just a year or so. Mindset is the key.
A lot of people joke about philosophy majors not being able to find jobs or make any money (the only people worse off are those who studied sociology :D), but that's not really true unless you're actually trying to become a philosophy professor. Then you're screwed. But aside from that, studying philosophy is a great way to hone your critical thinking skills, though of course it's not the only way. It's a lot more than just reading Plato and summarizing things, especially once you get beyond the intro-level courses. Obviously, I wouldn't recommend taking philosophy courses instead of CS, but they're an excellent compliment for programmers or pretty much any field.
Programming isn't just about writing the code itself; in many ways, that's the easiest part. It's about identifying and solving problems, many of which aren't actually your problems, meaning you have to have the ability to step outside your own frame of reference to understand the problem in the first place and continue doing so in order to work up a solution. Even for a junior developer, those skills can be a huge boon.
Great points, I was going to write almost the same thing. To build upon your last point, I'd argue that a solid (and rigorous!) philosophy education is in many ways better suited to building a sound logical problem solving mindset than much of the common core CS curriculum. Critical reasoning is much more valuable than just knowing Java or C++ syntax. Not to denigrate CS education, but rather to point out there is a lot more to learning to think in a way useful to programming complex systems than the current core of CS teaches. Especially in large (million line+) code-bases.
Learning, say, Wittgenstein's philosophy regarding grammar and language [1] gives an interesting insight into how humans express ourselves and delves directly into the heart of modern programming, IMHO. Rarely do we software developers write low level algorithms anymore, but writing consistent and complex API's is crucial and shares more in common with be conversant with large volumes of philosophical treatises.
Based on that, it makes sense many philosophy students would have successful careers – being able to reason and solve challenging problems is always key point in making good money. :)
Don't take things too literally. What he basically meant was "anyone with appropriate aptitude and intellectual maturity" -- like you yourself said later on, pretty much.
Which may or may not be entirely correct, but is far from "dead wrong."
BTW, please be careful about referring to foreigners, in any context, as "monkeys."
Parent may have edited the post (as I don't see "monkey" anywhere), but I frequently hear monkey used for any human (often fellow programmers) and have never read a racial or ethnic overtone into it and the usage has generally been to suggest that humans (of all sorts) aren't particularly different from monkeys.
I just got back from an business trip spanning 3 cities and 5 flights. The self-loading cargo in the airports, jetways, and boarding the plane could easily have been described as monkeys. I was literally called a monkey by a colleague for absent-mindedly and needlessly blocking a sidewalk in the parking lot while waiting for someone to pay for parking. I took no offense, of course.
I did edit the post, despite the fact that the reference was towards management thinking about programmers as "monkeys" it appears it was being misinterpreted by skim-readers as overseas people being called monkeys.
My point is that if you do not understand that programming is highly skilled work (and many companies think this) then you might think you can get anyone to do it for a similar outcome and therefore it is a commodity and therefore the only thing that matters is price.
Right, I understood the intended abstraction, after the 2nd or 3rd skim.
Just that even analytical people tend to think "associationally" when they see certain keywords -- and one has to keep in mind that not too long ago, people in many of the countries that software development is frequently outsourced to were, in fact, thought of as monkeys, pretty much (or something on the human-monkey spectrum).
So whenever I see associations like that creeping into my own writing, I try to dial it down.
We overestimate how hard programming is. Very few jobs in industry on a proportional basis require the formal math or computer architecture that you get in a compsci program.
I'm not a 10x programmer by any means, but I was able to write and sell non-trivial software in middle school, with little more than a pirated copy of Delphi and a book.
Most of the difficulty that does exist has more to do with bad engineering practice and poor documentation than anything else.
> "You can teach everyone to be a great programmer"
They tried this during the dot-com boom of the late 90's... I don't think it worked out too well.
They hired just about anyone and paid crazy rates. You could point them out for showing up their first day carrying a "learn ASP in 24 hrs" book.
Fortunately, the dot-com bust weeded them out. Most of these people went back to sell cars or whatever they were doing before while we had to clean out their messes.
"They hired just about anyone and paid crazy rates"
I don't think this proves your point. Just hiring someone to do a job does not equal teaching them. Teaching means not only practice, but also well constructed feedback and sufficient time and space to learn, and to learn from ones mistakes.
Kludging an ASP application together after reading "learn ASP in 24 hrs" does teach something, but there is so much noise that you need expert guidance to interpret the results correctly and point into things that need improving.
Back in the late '90s through the dotcom boom, we were teaching ourselves as we went. There was a running joke about HR looking for "someone with 10 years experience with HTML". In the mid-1990s, I was working on data transport stuff that involved hand-rolled socket code and daemons in C, and parsing the data stream in lex and yacc. We didn't have Apache, or ssh, or xml. A few short years later, I was working on really early Java application servers - technology that wasn't even imagined five years before.
It's hard to even describe what a change in productivity all this stuff was. Using an ORM to get data from a database and dumping it into html tables, and there was a browser that could format it all for display with nothing but some tags that were generated on the fly? Amazing!
I taught myself html, because there wasn't anyone to teach me. I taught myself server-side includes and cgi - no one to teach me. I taught myself Java. Etc. And I still do this today! If someone can teach you how to do something, it's already mainstream.
"If someone can teach you how to do something, it's already mainstream."
I don't think collaborative learning should be undervalued, though. There are several colleagues without whose example and input I would be a much worse programmer. Not in technical details, but harder to define things, like attitude that leads to success and how to make designs simpler.
'Mainstream' does not mean obsolete. Reading and writing and Roman alphabet have been mainstream for centuries, yet people utilize them with an amazing variance of productivity and value.
Actually things were quite different back then -- a lot of people found themselves in the position of needing to hire programmers, who until then had almost contact with that stratum at all. Nor any familiarity with names of programming languages or other buzzwords.
And IT in general was much more slow-moving since then -- even companies with lots of technical staff couldn't (easily) find people to adapt to the crazy quilt of languages (and yes, paradigms) that burst onto the scene.
So if you had even the slightest idea how a website worked -- your were like a gift from high heaven, and treated as such.
These days -- especially in larger cities, near everyone has social contact with some of the programming persuasion; many have dabbled in some form of scripting, at least, themselves; and you can't walk into a coffeeshop or ride a subway train without being immersed in techspeak.
So things have changed quite a bit, and correspondingly, the bar has been raised.
I always think of Michael Lewis' Moneyball story when I read such things. When everybody else is scouting for 200k players, why not pick promising fresh graduates? You might have to spend more time mentoring, but you get extra cash to lengthen your runway.
I've said it for many many years...hiring selects for those whom interview well and have good social engineering skills, not necessarily for those whom can get the job done and make the company successful.
The utterly meaningless "top 1%" metric always makes me laugh. By definition then 99 of every 100 engineers don't make that cut, which means, again by definition, your team has very few if any of them, no matter what hiring practices you employ.
Plus I've found that very often management uses the "oh we hired the wrong people" as an easy cover for its own failings.
There's a very big time cost to hiring just the best. If you're afraid of even one bad hire, then a growing company must be willing to have all their managers and top employees commit 20+% of their time to hiring. Then you ask "Is the 1-2 standard deviation in performance improvement worth it?" If the answer is yes, then it's worth it.
And... Interviews are awful. Seeing how someone work is even better. This is one reason why employee referrals are so important, and audition or temp-projects a good second-best method.
In the end I think it's a Fools Game though - someone who is best in one environment may not be that great for the next. Managing people post-hire is something that can't be avoided.
It's not just a time cost. The graph near the top of Jeff's article shows "Ran Out of Cash" as the #2 cause of startup failures, ahead of anything else hiring-related. I say anything else because hiring the best means paying for the best. If you hire nobody else, then salary costs rise. Attrition probably does too, because the best are often among the first to jump elsewhere.
Every startup needs a few of the best. You should definitely seek out and pay for those few. After that, even a startup has jobs that don't require the best. Hire for potential, attitude, chemistry. Hire for special knowledge when you have to (though you should try to avoid it). But don't demand that every hire be among the proven elite.
You could argue that the best pay for themselves, and that running out of a cash could come from hiring bad people.
The absolutely best employees I've seen haven't been frequent job hoppers. At most it's every 3-5 years. I'm thinking of an unscientific sample size of 5 or 6 people who have had sustained outstanding technical performance of 10-25 years. Companies don't let people like them go. And they tend to be loyal to the mission if treated fairly.
Now a company with $1mm of seed money that's supposed to last 12-18 months can't afford to hire 5 people like that. There's not enough cash or equity to go around.
This is one of those great articles that open up a collection of other articles to look at, whether you agree with the author or not (or somewhat). The links in the body are very informative.
This fear of not hiring the very best explains why everyone in the Valley seems to be interviewing candidates like crazy but nobody is hiring. When I interview I try to tease out potential, and look for signals that show the candidate will work hard and learn fast. Then someone comes in and says, "Well I hazed him and he couldn't implement a red-black tree on a whiteboard. No hire." This mad pickiness causes the mythical "shortage of engineers" meme to spread.
This might explain the string of interviews I've taken place in where it's typically down to one person that shuts everything down because they want to play stump the chump. You know, instead of looking for qualities in candidates that would bring value to the company.
Fortunately, since the best 1% are distributed across thousands of companies, all these companies have to settle for 99% percentile developers as well.
When they say top 1% they generally mean the top 1% of applications. A very large portion of the applications you get for an opening are sent by those who need to send out hundreds of applications to get a job.
To put this in context, "Hire the Best" means: adopt an incredibly risk tolerant nature, initiate an incredibly risky business venture, and then tolerate zero risk in your hiring decisions.
> Using screens to hide the identity of auditioning musicians increased women's probability of advancing from preliminary orchestra auditions by fifty percent.
I thought that the increase was largely attributed to more women being willing to audition anonymously?
> if that describes you, and you have serious Linux, Ruby, and JavaScript chops, perhaps you should email me
I don't know why, but I always thought the Atwood was 100% invested in Microsoft technologies. Not that it matters, it just surprised me.
Speaking of Atwood, has anybody ever used one of his keyboards? Any opinions?
She was able to attribute 25% of the increase in hiring of women by orchestras was due to the blind auditions. She also found that there was an explosion of auditions when orchestras adopted the blind format.
So it had an effect, just not as large as I thought.
That's weird. From what I've seen of women in classical orchestras, if I were the one in charge of auditioning and hiring musicians (not blind), I'd probably be hiring mostly women....
Honestly, if you're a straight guy, why wouldn't you want pretty young women working with you?
Hey, I'm just pointing out that this common trope about men discriminating against women for jobs doesn't really make that much sense, unless all the men in charge of hiring are gay (which obviously isn't the case or the claim).
Seriously, what kind of straight man only wants to be around men all day long, and then (assuming he's married) come home every day to the same woman, and never get to socialize with any other women? Maybe a religious fundamentalist, but not any normal man.
1. Why should women be judged on attractiveness? Men are not generally judged on this standard to join orchestras or do office work. It also, perversely, punishes women for being experienced while men benefit from it, handicapping their lifetime earning power. Professional women probably do not want to spend their lives judged as eye candy.
2. Because of the first point you will still end up with a strong male bias on top of whatever natural one training creates; after all, we're looking at men of any age versus young women, for the most part, in this scenario.
3. The numbers clearly do not bear out the assertion you're making in the first place, since blind auditions significantly increase the likelihood of women being hired after auditioning. It seems your "self-evident" reasoning does not fit the facts.
4. I do not think it is true that all men want to spend more time socializing with women. I don't see how the logic you're positing works unless sexual harassment is just outright permitted. If you're not convinced that sexual harassment is bad then I guess you're operating on a different plane than most of us.
Thanks for the response, but I really don't understand where you're getting the idea that I'm advocating sexual harassment at all.
I'll go backwards:
4. So you think that most men would prefer to not have any women around them most of the time, and only want to socialize with other men? I don't know if that's true or not, but it certainly isn't the case with me. I don't really want to work in a monastery-like atmosphere devoid of females (attractive or not).
3. Maybe, but that's what I'm asking about: why would straight men only want to be around other men? Seriously, I really don't understand this at all. Are most men repressed gays or something? I actually like being in mixed environments, even if I'm not attracted to most or even any of the women. Am I weird that way?
1-2. You seem to be claiming that men aren't also judged on attractiveness, and this seems wrong. I'm quite sure a lot of studies have shown that men are indeed judged on attractiveness, though the standard is somewhat different than for men (it doesn't disfavor older men as much). Just go find a short guy (or worse, a short fat guy) and ask him how his life is going and if he perceives any discrimination.
Anyway, my point all along has not been that only young pretty women should be hired, as you seem to think, my point was that I don't understand why men would discriminate against women in hiring, because to do so would mean you're surrounding yourself with a bunch of dudes, and as I said above, I don't know about other men, but I for one do not enjoy "sausagefests"; I like mixed environments.
I've heard enough men vocalize such thoughts to think that a fair number of them do.
The reason I get the idea that you're advocating sexual harassment is that you keep casting this in sexual terms -- why would you want to be surrounded by men, unless you're gay? Work is not a sexual environment (let's ignore the exceptions for this conversation); why is sexual orientation relevant? Saying "hey, aren't you heterosexual? Then why don't you hire women?" manages to promote a progressive cause with regressive reasoning.
I will concede that men, too, are judged by appearance, but I think that the standard is far more lenient and, as you said, tolerant of age.
In any event, the auditions are meant to judge skill. The conclusion I reach from the success of blind auditions is that evaluators perceive playing as less skillful when they know it is done by a woman.
>The reason I get the idea that you're advocating sexual harassment is that you keep casting this in sexual terms -- why would you want to be surrounded by men, unless you're gay? Work is not a sexual environment (let's ignore the exceptions for this conversation); why is sexual orientation relevant?
So you think that if I'm not actively looking for sex from women, that I should be perfectly happy to live a life completely devoid of any kind of female contact whatsoever?
That seems extremely disturbing to me.
Does that also mean that if I'm not actively looking to have a sex partner of a different race/ethnicity, then I should be perfectly happy to never have any kind of contact with people from other ethnic groups?
Wow, I guess on HN I'm just a real weirdo because I don't want to be surrounded by white males and be completely cut off from contact with other kinds of people.
No. I'm suggesting that arguing that you don't want to be surrounded exclusively by white males because "hey, I'm not gay" (implicitly, because you want to have sex with these people, or at least would not object to doing so) is somewhere between off-putting and troglodytic.
"From what I've seen of women in classical orchestras, if I were the one in charge of auditioning and hiring musicians (not blind), I'd probably be hiring mostly women.... Honestly, if you're a straight guy, why wouldn't you want pretty young women working with you?"
This is what you wrote. So, no, I think you're just trying to walk away from the implications of what you wrote because you are embarrassed. How do you propose interpreting that without any sexual bent?
You're taking one line I wrote and applying it to everything. I've made a bunch of other statements in this conversation about how I prefer mixed groups, not only of sex but of ethnicity too. One nice side-effect of a mixed group is there might be some dateable people in there, but it's not a given, and it's nice to have a mixed group (IMO) for many other reasons than just sex or seeing pretty faces, but I don't see how it's wrong to want to work in a mixed environment and have that possibility if you're single.
Playing devil's advocate, that strategy can still end up with a deficit of women. If your selection bias is (pretty ^ young) women > dudes > (unattractive v old) women, your hires are still going to be predominantly dudes, unless the talent pool is so deep there is always a qualified woman available who is also pretty and young .
You have a good point here, but just from what I've seen with symphonies, it seems like usually the performers, of both sexes, are fairly young(-ish). And they're usually all reasonably attractive. They're up on a stage for people to see them, after all, so naturally whoever's trying to keep ticket sales up is going to want them to look nice.
In the spirit of this advice, if you are serious about really finding the best people, you should offer very comprehensive severance packages as part of every offer -- on the order of 6-10 months of salary, possibly even "grossed up" so that it results in at least 6 months of salary after taxes.
Instead of spending money on needlessly complicated hiring processes, with back and forth phone calls, panel Skype interviews, foolish interactive coding exams, multiple on-sites, etc., you can spend that money on severance.
Use a cheaper and more straightforward hiring process. Talk to people, dig into their background and preferred working style a little. If they appear to be competent, then just hire them. If they are not qualified for the job or they are not a cultural fit later, just fire them.
Because you will have explained to them that their first month on the job is still part of the overall fit assessment, and that you value the risk they are taking by offering them severance to re-engage in a job search if it turns out you made a mistake by hiring them, you are not doing a disservice to the new hire. You're merely letting both parties gather more evidence about goodness of fit.
This is money well spent, and for most companies, 6 months of salary is easily affordable for severance. In fact, an unwillingness to offer at least that much to each new hire would be a huge red flag.
Will talented people be willing to give up their full time job for a job they may very likely get fired from?
Automattic does something interesting from what I've read. They have you work there as a trial for 1-2 months while keeping your full time job. This is probably pretty stressful but you get the ability to work with the candidate while not asking them to sacrifice their livelihood if things don't work out. Needless to say, it seems a lot of people don't get hired after the trial.
> Will talented people be willing to give up their full time job for a job they may very likely get fired from?
Maybe, maybe not. If they are already on the job market, then they probably don't mind looking for a job. If they feel that taking your job and getting fired still leaves them financially covered for an additional 6 months of searching, then they may not care too much.
If that company becomes known for this, then being "fired" from them won't really be a bad signal on your resume (if you even want to list it on your resume at all, depending on how long of a stint it is).
I don't think my idea is perfect. No hiring method is perfect. But I think that businesses should take a perspective that's fundamentally more about investing in getting to know and support someone as they are on-boarded, instead of Spanish Inquisitioning them and if they don't run away screaming then rationalizing that you've hired the best possible person (who, surprise, leaves after 18 months anyway because you didn't assess their fit or how their aptitudes really match up with job needs, you just whiteboard hazed them).
This is already caused as much by companies as it is by candidates who are job hoppers. When I see a resume with short stints, it basically has no effect on me any more. If the person is good and I do my job to make them happy to stay, that's the best I can hope for. Pretending like either I can predict who the job hoppers are in advance, or that I should only hire people who magically have some intrinsic desire to work for me no matter how I treat them are both fantasies.
>Talk to people, dig into their background and preferred working style a little. If they appear to be competent, then just hire them.
If I am very good at this assessment, then this may work. However, if I trust my skills to assess someone accurately, I am unlikely to have a complicated hiring process.
If I am a company owner (or manager!) who is not good at assessing people this way, then wouldn't substituting my process with this proposal make me spend a lot of money twice?
1) Paying salary to more people than open positions (Because I don't spend money on a hiring process and rely on my assessment skills, I may end up with many not-so-best-fits)
I am not sure I believe this. First, if you are aware that you're not good at assessing it, then have someone else in your company do the assessment, or hire someone who can (possibly on the advice of your investors or something).
If you can't do either of those, I am afraid your business just isn't going to work out.
So, almost by definition, the person doing the assessment is reasonably good at it. For otherwise, you won't be around very long regardless.
Also, if you find that you're hiring a lot of people who seem good, but ultimately are fired, maybe look in the mirror. Maybe it is that your expectations are unrealistic, or maybe you expect people to adhere to "culture" standards that do not support human flourishing.
Unless the tech problem you need to solve involves lasering in on a fleetingly tiny population of candidates (most don't), then a sequence of looked-competent-but-needed-to-fire people is probably more a reflection on the company than the candidate stream. It's unlikely that all of them were elaborate fakers.
The costs of (1) should be low unless there's a fundamental problem with the company (in which case the costs of (1) are way cheaper than hiring a management consultant to help you not fix it).
(2) is a real cost, and yes, some companies can't afford it (so maybe they scale back to 3 months severance? Maybe they add continued health coverage. Maybe they let you pick a foosball table to keep) ... but it is just the cost of getting useful information about an employee, instead of the not-very-useful info that most hiring processes generate.
> If I am very good at this assessment, then this may work. However, if I trust my skills to assess someone accurately, I am unlikely to have a complicated hiring process.
If you don't have the skills for that assessment, how do you know your complicated hiring process works?
You accept more risks on the hiring process, by hedging them with the firing process.
If it'll be good or bad depends on the actual risk balance you create between those two processes. But if the idea that the hyper strict hiring process does not help selecting great candidates, a moderate increase on nominal risk on the hiring process will actually improve your odds there, and you'll gain both ways.
> If they are not qualified for the job or they are not a cultural fit later, just fire them.
This is the entire problem with the inability to hire the "best"; It's dangerous to try and fail with lawsuits, unemployment, etc. I personally prefer to work for companies that don't hold on to poor employees and have quit companies that do the opposite. If you want to "hire the best" you have to "fire the worst". I accept the risk that comes with this of course (and many others may not).
Why would anything ever be grossed up? Because the purpose of the payment is to give the recipient a particular amount of money, usually related to specific costs, not some amount less taxes.
The costs of sustaining a job search after being fired are a bit different than the costs of living while you have a reliable income stream. The grossing-up part is meant to reflect a nominal amount of money to cover those kinds of costs, not just a virtual continuation of the salary-less-taxes you'd been living on while employed.
In my experience, severance and sign on bonuses are often grossed up, as are payments made for relocation expenses.
But there's no reason to be hung up on that part. It's perfectly fine to just offer a regular severance benefit without grossing it up.
If I give an employee a $100 Amex gift card as a spot bonus, I do gross that up.
If I pay relocation expenses, I require receipts (at which point, it's non-taxable for most situations, so doesn't need grossing up). It's not that I disbelieve the new hire, but rather that I have to make it accountable in order to make it non-taxable.
If I pay cash comp (whether as a signing bonus, periodic bonus, commission, in contemplation of on-going employment, or as part of a termination agreement), they're wages in my book and I've never seen them grossed up (unless more of the character of the gift card or Christmas ham variety).
> If I pay relocation expenses, I require receipts
This might be a deal breaker for me if I was interviewing with someone. It's not that I care about the accountability part, it's more that a ton of relocation costs are unforeseen incidentals, or are private expenses (like first month's rent ... it's not your business what I choose to pay in rent), that should be covered by just paying cash to the new hire. Making them track down receipts for all of it might work out to be more costly, in terms of time lost, than just bearing the taxes, and certainly might involve requiring knowledge of expenses the employee may rightfully prefer to keep private.
Usually, I expect that the company will handle almost all aspects of relocation on their own (e.g. buying plane tickets and hotel rental for housing visit, calling up and hiring the moving company to pack and ship belongings). The part that would be paid as cash would be the cost of rental fees, deposit, and first month's rent, as well as some small amount for incidentals, which should be grossed up.
On the other stuff I guess we just disagree. I don't view sign-on bonus or severance pay as wage pay, even if they are pegged to wage level. For the other stuff, I agree, it's just part of regular income and the employee should bear the tax. But for sign on bonuses and severance, I think it's fair for the employer to bear the tax in light of the purposes of those payments.
Sign on bonuses are very different in this discussion though, since not everyone provides them and the amounts can vary a lot and for low amounts grossing up can matter significantly, while for larger amounts, employees are usually happy to bear the tax cost themselves. I'm not so worried about what an employer's policy is for these.
It would matter to me to negotiate a specific value paid for severance, though, rather than "6 months' salary" which will then have taxes taken out. If an employer was put off by this, it could be a problem, depending on all the other aspects of the job. One way to avoid this is that if secretly what I want is 6 months severance grossed up, then I'll try to negotiate 9 months severance, without mentioning the grossing up part. It's less off-putting to the counterparty, even if it would be nicer if I could just speak plainly.
I'm just speaking from my experience as a candidate in previous roles. I'm sure everyone has different experiences.
It wouldn't end up as a deal-breaker. In the discussions leading up to it, you'd object to providing receipts, indicate that you're trying to cover other types of costs, and I'd respond with, "OK, we'll call it a signing bonus," and then negotiate the exact [pre-tax] amount.
I (and I assume most hiring managers) have broad discretion on the amount of a signing bonus. For an engineer I want, I will never care about the difference between a $5K and a $10K signing bonus (or if we're talking about bonus in lieu of relo, the difference between $15K and $25K). It's a one-time expense to me, comes out of a different budget, and yet candidates seem to really value them seemingly out of proportion to the economic benefit.
It can vary a lot. I think $10k is a generous signing bonus if it comes in addition to relocation. $15k is around the smallest lump sum relocation I would consider reasonable though.
Some firms offer > $30k signing bonuses (some more than double that) independently of relocation. It's rare, but not exceedingly rare.
> A successful sports team should hire the best, even if that's what everyone else is trying to do too.
Yes, but sports teams recognize "the best" is dependent on the other pieces in the organization. Teams that try to stack their rosters with "the best" in objective measure typically crash and burn. Teams that recognize "the best" is whomever fits the team's scheme and current players the best succeed. Too many software companies want the first sense instead of the second.
No, this can't work at e.g. the NFL. There is a $155 million per year hard salary cap. There are 53 players which much be paid under this cap. Which means the average salary is just under $3 million.
One of "the best" quarterbacks gets paid $20 million."The best" at various other key positions such as left tackle and defensive end and at cornerback can easily get paid $10 million each.
Even if you forget about special teams, you can't afford to pay 11 offensive players $10 million each plus 11 defensive players $10 million each.
Which means that you pay a few superstars at $10 million or more, some more good players $5 million, a bunch of OK players $3 million, and a bunch of rookies and scrubs under $1 million each.
Nobody can afford to hire the best at everything. I'm sure that's just as true in business as it is in sports.
I worked for companies which "hire the best." My experience was always exactly the same - a group of very talented engineers who couldn't accomplish a damn thing together because egos got in the way.
My current company doesn't hire the best, but instead focuses on people who enjoy making impact in a small team, share the same vision and have a bit of an entrepreneur in them. We don't quiz people or give them tests. We just sit down with them and start talking tech. The results are really amazing and make for a great place to work because everyone feels like the project they work on is their baby.
372 comments
[ 3.0 ms ] story [ 305 ms ] threadA word to the hiring managers out there, look to the future, cast the vision, and onboard people who want to go there with you.
So in order to work on an audition project, I'd have to be unemployed already.
But specifically if you were taking an interview rather than working a side job you could make the argument that the clause didn't apply in any case.
It all comes down to how much you pissed off your ex-employer by leaving, and how much they want revenge. No-one is going to gain anything from suing you after you've moved jobs.
But my current work contract has an anti-moonlighting clause that could also be a problem. It states that I can't have other demands on my time that would interfere with my day job. Now, I interpret that as meaning I can do side projects that have no deadline and just be luxuriously slow and lazy at making progress on them. But for an audition project I probably wouldn't be able to take it that slow.
While there's always some bias, I think it shifts quite a bit once you move from an artificial "interview environment" to a work environment.
Plus as has been said, since they candidates are working with the people they would be working if hired and that relationship doesn't work out, then maybe it's better to keep looking for someone else.
In my past of applying for jobs as a designer, I had companies that would ask for take home tests. I always refused and of course didn't get the job. Conversely, other companies I worked for offered freelance positions (probation) before settling onto full time which I thought was far more effective and fair method at evaluating me as a long term candidate.
If they have neither, then it's absolutely fair to ask them to do a small audition project first. Otherwise how can you be sure they're competent?
Keep in mind this idea doesn't exist just in recruitment. It's basically recruitment's version of what's called a "proof of concept", which is proof that the party that is pitching/asserting something (i.e. their skill) can actually deliver.
If the project is a couple hours, then sure, I have no problem with it. When it's an entire real project for the company, you're just donating a week's work to someone in the hope of getting an offer letter.
By using such automated tests, companies want to identify top talent by taking a shortcut and not investing any time on their side.
Nope, we aren't even going to ask you anything about that, or let you open up your iPad and show us, here's a whiteboard, start writing up a recursive permutation algorithm (only ever had to do this in programming interviews) because we want to prove you know how to do recursive stuff (and then tell us why you should almost never use recursive solutions in our apps), oh, and how about a red-black tree (algorithms class ran out of time to cover, unneeded since), or how about coding this specific sort (heap, merge, whatever) that you'd almost never use in actuality because there are tried and true libraries that are already more efficient than you'd ever be doing it from scratch?
Ugh. Fine, you can do your test, but please don't ignore my prior experience or act like you haven't even given a cursory glance at my resume, or even worse, make a dismissive comment when I talk about it during the interview. It really is insulting. And yet half the interviews I've been in have been like this.
I took one of these recently, and botched one of the tests. Within 10 minutes after the timer was up, I had restarted my solution with a successful answer and was iterating on it.
The idea that the pressure is the same doesn't seem to apply to all applicants. Doing work under pressure within set times has been a strength of mine(ex. playing chess against higher rated players or when timer is low). I've noticed, however, that my skills fall apart during interviews. Once again, totally different contexts where you're being tested.
I am so tired of hearing the refrain that "we want to see how you work under pressure". Anybody who thinks that all pressure or stress is the same and that you can translate performance in one stressful situation into any and every other one has no business being near a hiring decision.
People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired.
Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't code a loop in the languages on their resumes.
I guess you can reach two conclusions from that:
1) A surprising number of applicants are totally misrepresenting their abilities – either through deceit or wild ignorance.
2) Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificial constraints, etc.
Certainly many of those applicants fall into the first bucket, but I'm betting a large portion fall into the second. So, you might reconsider whether the false negatives and highly unpleasant experience for many interviewees are worth the perceived value. Maybe there's a better way to get the same insights.
But then at the end of the interview I was given a coding challenge to do at home over the next few days. PHP and MySQL have good online documentation so I was able to knock it out quickly and I got the job. So, yes I misrepresented my skills, but I also knew I could live up to what I was claiming I could do.
Employer: First job out of school pay, requires four years of experience in our exact tech stack.
Candidate: Sure I'm willing to take first job out of school pay (BTW, just graduated in May). Yeah, totally have 4 years of experience, and what do you know, it covers exactly your tech stack!
Edit: exactly the point shawn-furyan is making.
https://news.ycombinator.com/reply?id=11224427&goto=item%3Fi...
I've worked with people who crashed and burned during the interview during nervousness and then went on to do okay afterwards.
I'm a believer in trying to make the interview process as close an analog of day to day work as possible and as low key as possible.
That means real, actually encountered problems (no fizzbuzz), and a progressive ramping up of the difficulty so that candidates with confidence problems can have a few easy problems to get over their anxiety with before getting into something meaty.
People that suspect they're in category (2) could come to an interview with some code samples. Personally, I'd even be OK if a (2) contacted me after the phone screen with some code samples and an explanation about what happened. Maybe we could set up another phone call and find another way to assess technical abilities.
Good development requires good communication and someone with the maturity to overcome that sort of problem will fit in well somewhere, maybe even on my team.
(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)
I often use CSV parsing, where I specify a function that involves a simple string and I want some natural parsing of that in your favorite language. A bonus point for starting with the observation we should use a library, then do it yourself. From there I can pivot into discussing what the correct output data structure is (especially if the rows do not all have the same size or the same data types), converting text into better types, whether or not you understand unambiguously encoding text ("how can you include a comma in your field?", and I'm not worried about whether it's a "standard" answer), UTF8 and other text encoding issues, computational complexity a bit (and while small, it's a very practical, day-to-day bit) and questions of memory efficiency, the question of streaming if the dataset is too big. I can also easily pivot into outputting this CSV file into an HTML table in your favorite language, getting into HTML template issues, security issues that can arise from that, dumping the CSV into a database, and I'm probably even forgetting some of the pivots I've done. (And the point here is that I can choose, not that I ever cover all of these in one interview.) This question template scales from intern level ("can you get this string into an array of array of strings?") to senior engineer ("alas, the text encoding is varying from field to field, now what?") quite easily.
I've phone screened with this in a shared doc, too, since I can copy & paste in the problem pretty easily.
You're clearly getting a better caliber of candidate than those people are. That's great! And clearly, if that's the case, you should adjust accordingly. I think the lesson there is to tailor your process to the people you get.
I know to get away from those companies and never come back. If our values differ so much at the interview stage, it won't get any better a few months from now.
However, what I cannot condone is wasting the time of 100 applicants. It takes the employer ten minutes to "sort by best" and start calling down the list.
You are 100% right about their time investment. They are saying their time is more important than yours. It is another layer that muddies the process.
"The most significant shift we’ve made is requiring every final candidate to work with us for three to eight weeks on a contract basis. Candidates do real tasks alongside the people they would actually be working with if they had the job. They can work at night or on weekends, so they don’t have to leave their current jobs; most spend 10 to 20 hours a week working with Automattic, although that’s flexible. (Some people take a week’s vacation in order to focus on the tryout, which is another viable option.) The goal is not to have them finish a product or do a set amount of work; it’s to allow us to quickly and efficiently assess whether this would be a mutually beneficial relationship."
The people who will go through this either a) really want to work at your particular company (in which case, great, but unlikely), or b) are desperate for a job because they've been turned down several times.
Now you've got to spend time optimizing your interviewing team. What if one guy just says yes to everything? He might as well not be there but he's still a weight in that decision. What about the opposite where he says No every time? When do you decide he is actually going to say No every time and not worth being part of that decision process?
The more people you put on this decision table, the lower the chances that any one candidate will make it through. But there's an opportunity cost of time/money to that, so you've got another thing to balance.
I think it would be really, really hard for one person to simultaneously impress 10 people beyond a doubt just because of how many people have to reach consensus. And can you imagine the stress of knowing one dude with a nitpicky attitude (that none of the others know about yet) could sink your chances?
In interviewing discussions in places like HN, there is enough pushback against this idea, which is a bit surprising to me. I thought a few hours work was reasonable when I was interviewing. But my point is that just this small bit of work seems already too big for many people, let alone working 10-20 hours a week moonlighting. It's cool that they pay for it, but that pay is pretty insignificant in the overall scheme of things. (Also, now you're not really interviewing, you're doing client work. Different relationship.)
When I have tried moonlighting in the past I found the stress incommensurate with the additional income. So I don't think I would do it as an interview, personally.
It sucks that companies take a risk during hiring. But I'm not really interested in making that my problem, as a job seeker.
If I do one two hour project, and either get an offer letter or polite refusal in response, I'd do it in a heartbeat. But no one does that. They would be fools if they did.
Would I want my kids to spend their careers being put through the wringer of multiple high-stakes interviews or be forced to moonlight in order to get jobs, something that gets progressively harder as people reach their thirties and gain extra responsibilities? No. Rather stay away from the field entirely and look for a more stable career.
I am a 2nd year CS student looking for a web-dev job to get experience and learn new stuff and every ad I see requires a couple of years in the industry + knowledge of a huge amount of frameworks. From my viewpoint, there is no real need for beginner devs. Companies are looking for really experienced AND cheap programmers.
That's my inbox. Not too appealing.
No. Now, okay, if you are doing absolutely fantastic, ground-breaking work, and I'd be rubbing elbows with industry leaders, and I am not otherwise in the market or trying to do eleventy seven other things simultaneously maybe I'll carve some time out for your project to prove myself worthy. But, you know, most jobs are jobs. If I play the interview game I can have a handful of job offers in a week (maybe not jobs I want to do, but that's a different story). Your team might be doing it right, but do I have optics into that? Probably not.
If everything I've done in my life is not enough to convince you (generic you, not draw_down you) that I can program and solve your pedestrian problem, then I don't view me as being the problem here.
So, if your take home thing is a 2 hour project, and is in lieu of a whiteboard grilling, then fine, sounds appealing to me. But only in context, because it suggests that you don't actually have any interest in measuring my skills, which go far beyond writing for loops. So, probably not a job for me, no harm, but you know, not appealing. Sell me, I'm not a supplicant. We'll figure out if we are a good match or not, no biggie.
The reality is that the take home things are usually just yet one more requirement, one more hurdle, yet more time out of my life. And you do a few, it goes into a black hole, no one even responds, or you get a one sentence email from HR telling you piss off in the nicest way possible, and the motivation to do another goes into the toilet.
Or the reverse happens. You do really well, they bring you in, throw some brain teaser programming problem on a whiteboard, your mind goes blorp, and suddenly everyone is being aggressive and scowling, or staring at their phones, instead of talking to you. Oy vey. I'm sure it happens, but I have never had take home go well, where I didn't end up feeling like a piece of meat being graded by the USDA.
And I never thought, once, "this is a really good measure of me - good performance on this reflects my on the job performance". Yes, I can write for loops, and fix bugs, but if that all the job is it must be really boring. What do you do? Why should I want to do it? How can I help? How can I grow? How can I help you grow? I have some ideas, are you interested in them? Let's build something!
Nope, just for loops, and then iterate over this structure that should be recursed over (or vice versa) on a white board.
I program. I get jobs done, every time. The code is maintainable. I try to up the bar, not maintain the status quo. I can talk to you about all of this, and if you have a medium IQ you can tell I am not bullshitting you. What more do you reasonably want?
8 weeks of contracting. Burn your vacation. Don't talk to your kids or wife, I'm trying to get rich here off your back. Work for me! Moonlight, and risk getting ...
I prefer at least having a phone interview upfront, which suggests that the company is willing to put in some effort.
If I have to spend two hours doing made-up homework for you before you will even talk to me, I expect that you will then spend an equivalent amount of effort proving to me that your company is somewhere that I would like to work. If you are not willing to invest that amount of time, the whole point of the interview is to reach an arrangement wherein I give you time and you give me money, so you could pay me for those 2 hours instead.
While I don't necessarily walk away from interviews that turn me off, every warning flag does add to the minimum offer amount I would be willing to accept from the employer. If you don't treat me with professional courtesy and respect during the interview, I am silently adding numbers in my head. If you act like I am the one wasting your time, I am probably adding $20000/year to my salary expectations.
I would much rather moonlight for a few hours every week, while getting paid to do actual work, than spend even one hour doing a stupid toy homework problem that ends up being a great signal for the employer and a very poor one for me. It isn't a matter of whether the pay is significant for me, but whether the employer is making and demonstrating an effort to make the process an exchange between equals rather than a superior-inferior relationship.
So why bother interviewing? The goal is not "we only hire the best". Hiring is only half the battle and a short term goal at most. The long term goal should be "we only retain the best". Sometimes that means firing people, but more often it means going to the mat to keep the people who work best: Treating people like human beings and, most importantly, paying them. Pay well and the good people will not leave. Actually fire those who don't work out in the long term and even they will do nearly anything to stay.
Or do what most startups do. Pay next to nothing. Treat everyone like widgets in a great machine. Fire only those whose admit having a life outside of work. And hire only those who share similar opinions on ultimate frisbee because culture!
Someone who has 20 years of knowledge in a dozen different languages doesn't matter as much if you just need someone with 2 years of very deep knowledge in one very specific language. On paper the former is "better" (even if one can learn/adapt), but in context someone who fits the latter is a better fit.
People can also learn. I'll take a junior developer over a senior developer who's an asshole any time. In a team, over time, the junior developer can more easily become an asset than the senior can change his/her ways.
Totally agree that retaining is the other side of the story. We actively encourage people to tell about their life outside of work and celebrate the diversity in cultures.
The article also talks about geographic diversity which I think is a great help in getting good people to apply, we have people in 4 continents now. If we only had to hire in the bay area we can't have been as selective as we're now.
What happened that makes you this bitter?
Well, sure, but from the employer's perspective different people have differing amounts of potential productivity. You definitely want to at least limit your hiring to people who at least have the potential to be star performers.
It is utter voodoo.
I came up in the late 80s. Interviews were maybe 2 hours long. You might be handed a piece of paper with a problem to aggregate some information distributed in a few different arrays and print them out. You know, write some for loops and a few logic statements.
Then you talked about the job. This is the job. Do you want to do it? What do you have to bring to us? Do you have a lot of experience and want to lead, or not a lot and want to learn - we'll adjust position and salary.
And you put a team together. Some were great, some were okay, some needed to be let go. In total, all sw people had a job.
Contrast that with today's voodoo, where proxies are weighed more than on the job performance (the only thing that matters).
In the end, you put a team together. Some are great, some are okay, some need to be let go. In total, all sw people have a job.
It's all exactly the same, except the absurdity of interviewing by proxies. It's simple logic - he average of everything is average. Why have we abandoned logic?
So many things matter more than remembering red-black trees from your midterm (I'm 49. I TA'ed a graduate level algorithms class back in the day, but I don't happen to remember it. That's what books are for). Like being able to run a project. Being able to write documentation. Being able to enter a room with a combative and upset client and keep the business. Being able to mentor your colleagues. Taking ownership. Leading by example. Ability to learn. So many things that are not even discussed in the current interview environment.
I've watched companies spin their wheels for months, rejecting perfectly good people, looking for that mythical person with exactly the right, esoteric combination of skills, who, for some unknown reason, wants to stall their career and get hired into a position where they learn nothing because they are expected to know everything already. People that are eager to learn? No, sorry, not rock-star material. All these prior successes mean nothing, no one could possibly learn a technology or new algorithm, right? And, more than once I've had people get downright snide about it. I'm sorry that you misread my resume, contacted me, and I didn't have that absurdly specific combination of skills. My fault, right?
Y'all have lost your minds. :) Which is okay, we're an eccentric bunch, but jeez, let's inject some reason and introspection into it. The faces are different, but the talent is no different than the 70s and 80s. There's zero evidence that any of these interview techniques are reliable. There's tons of evidence that interview techniques are horribly biased in many ways. Just stop.
https://en.wikiquote.org/wiki/Albert_Einstein
And again on the plane on the way home I said it to the pilot who was carrying a book into the cockpit.
And when my 18 year child went out driving for the first time on his own I handed him a book titled "How to drive".
There are also and other things that are in the periphery of what I need to know, but can look up easily when necessary. These include things like my mother in law's mailing address, my coworkers' phone numbers, my wife's phone number, the population of the US, how to rewire a plug socket, and the recipe for Belgian waffles.
Each of those things would be good to know, but we can effectively offload it to external memory.
They become annoyed during interviews when they are asked some concept and suggest "I'd just look it up on Google", which is fine for matters of programming syntax, but not fine where it reveals that a developer does not understand an important concept.
Yeah, all that stuff is stupid. Who the fuck cares what the capital city is for each of the 50 states? That's what atlases used to be good for, now it's an almost instant search in Wikipedia.
It's an at-will state so you can leave without notice and be laid off without notice. It seems that would cover the majority of circumstances and protect both employee and employer, for better or worse.
If you're a first level manager at BigCo, the risk of getting sued outweighs the benefit to your career of getting rid of someone who needs to go.
I suspect that's why you see healthy companies doing a lot of relatively small layoffs - when your manager tells you a person on your team needs to go, you'll lay off the one you might have already fired in 1980. The result is the same, but it's a lot harder to sue over staff reductions than a firing for cause.
Startups are different, of course, because a company with only a handful of employees might go out of business if it has to carry one as dead weight.
I've had a few folks that I've had to let go folks, including folks in .gov with union contracts and motivated defenders. It is doable.
End of the day, don't be a wuss. Setting up some hunger games "audition" is passive aggressive bs. If you're nervous, hire a contractor and get them on the payroll later. Or just hire the person, and give them a months severance. Problem solved.
The other reason is the company is not really looking to hire, just placate their current employees - "yes we know you are over worked, just hang in there while we hire someone to take off the load".
Which may be why people that are below par haven't been let go? A need to throw bodies at a problem rather than step back and give it some thought / work it out.
What disappointed me was, 3 of the interviewers had no idea about my background and weren't able to extract my strengths. Even though I am a new grad, I have interned for 2 years as an app dev and learned a great deal about design, code quality, testing and etc...
I have read Effective Java, Clean Code, and Head First Design Patterns. I'm reading Java 8 in Action now. I have not memorized them page-to-page and still need more experience to master them, but at least I know some of resources I can go to for more answers. I have participated in code reviews and enjoy them. I can implement LLRBT and many of the algorithms you can expect a new grad to know but I have not invested my time on hacker rank and uva.
I don't know what SV or big tech companies are looking for. I constantly hear interviewers say they want good engineers but fail to capture the essence of a potential good engineer well. What benefit is there in hazing anyone with problems many engineers don't deal with without the tools they use every day, and with an absurd time constraint. Kosaraju didn't come up with SCC in 30 minutes and he had a PHD. Sure I can spend hours studying for whiteboard questions but to what benefit. I am sure anyone of you can come up with a whiteboard problem you can't solve in 30 minutes, but what does that say about you.
Don't complain that interviewers haven't read your resume; it is your job to tell the interviewer about the relevant parts of your resume and why they matter for the job you are applying to.
I disagree. If you're going to interview me for an hour, the least you can do for both of us is to take 10 or 15 minutes ahead of time to familiarize yourself with my background.
it is your job to tell the interviewer about the relevant parts of your resume
Again, I disagree. A resume is only a very cursory overview. You can use it as a starting point to probe me about it, to at least determine if I've actually done what it says or if I'm just a buzzword bullshit artist.
IMO it's very shortsighted for someone to ignore a resume before conducting an interview.
The bigger point I'm trying to get at is the following: do not expect the interviewer to discover how brilliant you are on their own. Being smart, hard working, is not enough -- you also need to tell people about it.
I will be more proactive on my next interviews. I did have my github on my resume; I will add more projects to it and get involved in OSS.
Haven't heard so much from Joel these days - sad :(
I don't want to work in Sillicon Valley, even if the work is interesting. I live in Scandinavia and for me scandinavian countries are the best to live in the world.
You're used to that, and in a "measurable" way, it's semi-objectively true but it's not for everybody. I think it mainly was that I missed the sheer insanity of America where it is insane. It's something akin to codependency.
And given all that, I'd rather live in a Scandinavian country than SiVa.
Sweden for example has more billionaires per capita then the US. Norway have so much money in their oil-fund that they could pay every Norwegian 1 million NOK and still have money left. We're safe from any storms, earthquakes and basically all natural catastrophes. The most dangerous animal is pretty much the moose. Environmental issues will hit Scandinavian countries very late compared with the US.
The truth is, when it comes to building, maintaining, and supporting internal, line of business apps, management isn't even pretending to look for high end talent. They want predictability, reliability, and someone who will "fit".
I wonder how many people out there fit my profile. That is, they get excited by reading blog posts like these from some of the thought leaders, and desperately want to apply the thinking to their own workplaces, but then feel like we aren't really the target audience.
I've worked in traditionally boring industries that treated programmers as resources to be allocated (healthcare, logistics). Sometimes it's still possible to make a difference. For example the logistics job I had, we were often the only development resources our clients had, so when they wanted to run a promotion or do something like that, our execution could literally make or break their business.
It may be counter-intuitive, but I find it easier to apply these types of articles to my non-programming work. My wife and I own a gym, and we need to hire personal trainers from time to time. There's a certifying body for that, so it's easy to know if someone is trivially "qualified" for the job. Are we trying to hire the top 1% of trainers in the country? No, we're at best a medium-sized location for our area. Largely what we look for when hiring is how they will fit in with the existing coaching staff, how they will fit in with our existing clientele, and how likely they are to attract new clientele (or bring with them).
But don't take my career advice. I only really know what not to do at this point.
And I should mention that I've looked for other jobs in the area (trying to stay local because of family) - and almost no one pays as good as where I'm at. I'm making a bit above average according to Glassdoor (for my location).
And I was a developer but had to ask permission and make a case for every single program I wanted to install to help do my job, which isn't necessarily bad (there are understandable security concerns with downloaded software from the internet), except when Net Ops rates it a low priority and takes weeks to give you the permission. I eventually just stopped asking.
The atmosphere was also the most subdued environment I've ever been in. Most people not talking to or acknowledging each other unless their cubes were near, very few jokes, I almost got the feeling I'd get in trouble if I ever showed exuberance.
Not that I ever felt like it anyway. The lighting didn't help with that either, since we were in a room with very little natural light and soft florescent lighting that made it difficult for me to even stay awake there.
I did learn some new things there, and people were polite and friendly, so it wasn't all bad, but I'd never go back.
I know exactly what you mean! It is suffocating! Currently struggling with this right now. I can't stand it because it just feels so fake and phony. To me work is easier and more manageable when you are getting along with colleagues, not when it is overly formal, and corporate, etc.
Idk, that's just my perspective.
I don't even mind corporate necessarily, as long as it's relaxed. My current place people will talk about pretty much whatever, help each other out, tease each other about things, the boss will join us for lunch and talk about Star Wars and Deadpool, team leads are willing to admit that they can make mistakes, you feel like you can be more open and honest around your superiors, no one gasps or blinks an eye when you casually curse, etc.
And yet it's not quite no-holds-barred like a previous job that erupted into nerf gun battles and openly (but not seriously) insulting each other on an almost daily basis.
But I wonder who it is that sets the culture or tone of a workplace. Is it every employee in concert or more management / the team leads / bosses etc?
Why are they even called "consulting" firms? They are really just contracting agencies. And why are they so prevalent in the midwest and the insurance/banking/healthcare segments? Is it so that employers don't have to lay people off? Do they record the costs differently on their books versus full time employees? It just seems so obviously not in the interest of a company to use them with regards to culture, turnover, cost.
I also objected to the idea that someone who directly generates revenue was being labeled a cost center. I left, as did my junior consultant, and shortly after the company failed to gain ongoing contracts at the very large financial services corporation they were trying to break in to.
My main problem with that job however, was that they recruited me as a greenfield .NET developer, but then had me analysing some 800 columns over dozens of tables looking for software errors that were causing incorrect results in the 401k accounts for which our client was the steward.
I've seen two reasons why mega insurance company inc brings in "consultants." One is the consultant is specialized in an area of tech that is completely outside of the companies expertise. I did some of this being in a niche area of enterprise security. While those contracts still suck they suck a little less because you are at least advising the company and getting them up to speed on something. The other type, and the most common type is the "staff augmentation". I've been on those projects too and its exactly how they seem. The company has some in house knowledge (say a manager of infrastructure and maybe one full time employee for that tech) but the rest is really about throwing bodies at a project. From the client's perspective its all about workforce flexibility and not having the expense of a full time employee on the books. Even at like 100/hr its cheaper I guess for them vs having a full time employee. Plus its not their "core business" although in 2016 I'd argue if you are running a company it's insane not to think of tech as part of your "core business."
Overall, between the unsteady work, travel, etc being an enterprise consultant sucks. Most people that I know go into it because the potential to make a bit more money vs a traditional job at mega insurance company inc is there and they don't like the idea of working for mega insurance company inc for years. However, I've been on contracts where the project is like two years long so you might as well be working for mega insurance company inc anyway.
For instance, you can be a "contractor" as a software engineer, where you sign an employment contract to work for 6 or 12 months at a client site, working through an employment agency. At the end of that term, either your contract is renewed or it is not and you're now unemployed.
Or, in the defense industry, you can work as a "contractor" where you're a full-time employee of some company (called a "defense contractor"). That company signs a contract with the government to do some work for them somehow, and you're assigned to do this work. Your work does not have a defined end date (like the 6-month contract you might get to work at some big commercial company), you're just a regular full-time employee, but you still have to track your time (so it can be billed to that government contract), and if something goes wrong with the contract (like it runs out of money), then you can suddenly, with little warning, be furloughed without any pay.
Of course, there's many other kinds of "contractors" too, like the guy you hire to replace your house's roof. And there's all the people who are full-time workers, but are given 1099 forms as classified as "independent contractors" so their employer doesn't have to pay FICA and unemployment insurance for them.
Now, as for "consultants", that usually seems to be pretty much what I described in the part about defense contracting: you're a regular W-2 employee of some corporation, but you're sent out to client sites to do work for them, though there's no fixed-term contract with the client usually.
The CEO of one of my past clients, a consulting company, always said: "You can teach everyone to be a great programmer". And he put his money where his mouth was: He hired people with no programming experience (even with no university education) and personally trained them for several months. Also, senior people in the company were encouraged to also help them and guid them.
He had to fire some of those people later, mostly because they were not a good fit for the company. But some of them became great programmers and software consultants.
"Hire only the best" is really only half of the battle. Give people an environment where learning is encouraged and failure is expected. And help them wherever you can. Most will learn and enjoy it.
OTOH, I recently had an interview at a company who have quite a bit of groth and scaling problems right now (but probably not Silicon Valley level), and they still said: "We constantly have to learn new things, so the most important thing a candidate has to have is they have to enjoy learning new things".
AND: there are quite a lot of companies who are in the stable / profitable / predictable growth category and could afford to train/develop their people - But don't.
Then again, a person with whom I went to college is a recognized expert on Oracle performance. I find it keenly interesting that such a role even exists.
I look at startup-ey, Webby looking job postings and it's like the qualified people drew to several consecutive inside straights just to have the right buzzwords on their resume. And it's a different set of inside straights than it was six months ago. And it's different yet from firm to firm.
See there how easy it is when you don't know what you're talking about? :)
I've worked from outside the hull speed of several teams and gotten into places where being diplomatic about the sheer propensity to failure was a lot of what I ended up doing. And, frankly, I've just dropped the mic and walked off more than once, once I'd established that the team ultimately just didn't want to perform or had some horrifying external constraint that made the death march inevitable.
Say it with me: "I am powerless over the fact that I suck." At least you can work on the self loathing and make progress.
But seriously - get your ego out of it and life gets better. Let your ego free only when you are alone. You can't fix 'em all.
We do have a college intern and hire program, but it's very rare for a new college hire to have the same ROI as my best experienced colleagues.
My big issue: Startup hiring kids to do work that should be in the hands of lawyers. I've seen interns redlining contracts and social media directors heading compliance teams. Some expertise cannot be developed in-house.
Is that true? Maybe for a subset of people, and (union) a subset of the skills. But one can surely improve their knowledge in an environment where there is nobody able to teach him. The environment must support a few failures, because they'll happen, but it is possible.
Most times, the premise of a start up is that 2-4 people with well developed non overlapping skills get together and build something with each being such an integral part that they are worth a good chunk of equity. Perhaps 5/6 is a CS person that you train as OPs / Dev on the side. But most companies don't have the time or man power until the team gets into the double digits.
On the other hand, if you want to build a pipeline to solve tomorrows hiring problems, go out and interview unskilled people that want to do the job you have. There's some wash out but generally you can make a pretty good batch of people. I've done this in a couple places and it can be very rewarding not to mention as they start to develop and move out to other teams they are often willing to spend some time giving back to the program that helped them up on the ladder. Which means that you have more eyes and hands helping develop people and more time for coffee.
http://devjourneyhomepage.azurewebsites.net/
People would rather hire someone who has made mistakes on someone else's dime (another word for it is "experience").
"Can you imagine if we train our employees and they leave?
Well, can you imagine if we don't train them and they stay?"
You can train most people to do most tasks. With a modicum of natural inclination, competent. With a bit of interest, good. With a willingness to work hard, very good.
However, you can't ever train greatness. You can't make it by any method - only they can.
Your broader point is good though. The most predictably effective way to end up with top talent that works well in your structure is to help it develop.
You will not meet such people very often unless you are in a truly extraordinary situation, which means you may well never work with one.
My argument is that such people, whatever the field of endeavor, do not ever become great through training alone. You can only develop the conditions for people to reach their full potential, and hope that some (small number) of them truly become great.
You've not really solved the problem by stating that, all you've done is swap one subjective term (great) for another (better).
FWIW, I don't think everyone is naturally suited to programming, but I do know I've met a number of people, with a diverse range of backgrounds, who I am confident would be employable as programmers with the right guidance. The two biggest traits they all share is attention to detail and an openness to learn. I'd argue that's all you really need, everything else is just a matter of effort and experience.
But I believe you are being obtuse here. I've never met a large group of programmers who wouldn't have rough consensus on their "better" colleagues. Begrudgingly, perhaps, but it is there. Human beings naturally self-organize this way all of the time, the metrics are definitely imperfect but pretending they don't exist or are somehow meaningless is just perverse.
Nothing I said claims that diverse people cannot become perfectly competent programmers, this is certainly true.
The claim was more that "greatness" in part, at least, necessarily comes from within.
That goes into the whole nature vs. nurture debate, and you can probably find arguments for both. Playing Devil's Advocate, I'd suggest there are traits that help you become a great programmer, but those can be learned traits. For example, "thinking like a machine". You're a much more effective programmer after you can build a mental model of how the programs you write are working at a lower level of abstraction than the one you're programming in. That's something it's undeniably possible to learn, the main barrier for most people is a lack of interest. You have to be prepared to learn a bunch of supporting material that may not pay off in the near future, but will help you in the long run. That's my experience of what it takes to become good/great/better at nearly anything.
https://en.m.wikipedia.org/wiki/Arete_(moral_virtue)
What's desired is that our company have the best talent, but that someone else develop it for us. We'll pay the maintenance fee at a high level but we won't actually invest in it.
This is a simple problem - we know the cost of everything but the value of nothing. And then we begin to redefine "best" down to make it easier to measure.
The best organizations "grow" their talent in addition to "finding" it.
Talent is not a resource which merely exists out in the wild like some kind of unicorn. Talent is DEVELOPED in the right environments with the right team and the right resources.
Large companies especially, need to take a bit more responsibility for cultivating talented people instead of merely project-managing "resources" ad-nauseum, and then finding increasingly elaborate ways to find and recruit talent.
Both ways (grow and manage), though, I find the notion of "find the best, set them free, done" is insufficient.
Most of the code I've written, even the best of it, is long gone. The company died, the system eventually got replaced, the business needs changed. I've debugged some epic problems through herculean efforts, but in retrospect most of those problems shouldn't have even existed; bad work process created bad results. I created some great system architectures, but technology advances so rapidly that the great solution of 10 years ago is now sadly out of date.
But getting some non-developer hooked on development? The shine on that doesn't wear off. Taking somebody who's struggling and helping them become a solid contributor? I'll always be proud of that.
Flat out dead wrong. If you hire "anyone" and try to teach them to be a programmer then you will probably fire them.
This is the sort of attitude that leads companies to outsource their development overseas: "Our programmers are people hitting keys. We'll get overseas people to hit keys and overseas people hit keys for less money.", cause, you know, anyone can do it.
Programming is VERY hard and it takes a huge amount of motivation and hard work to become any good at it. Sure you can learn how to do simple stuff without any serious interest, but to be beyond ordinary it takes enormous work and time and research and Joe Schlepp off the street is simply not going to do that.
If you want to hire people and teach them then you need to look for these things: enthusiasm for computers and programming, demonstrated willingness to learn, energy and effort. You should value energy and effort more highly than anything. Those are the raw ingredients for trainees, and people with those ingredients are far from "anyone".
If you choose to read my comment that way then you are choosing to hear the message that you want to hear, which is a reflection of you and your personal issues.
My comment in no way suggested that overseas developers are incompetent - in fact whether or not a developer is competent has little to do with where they live - although economic opportunity is part of the equation. Great programmers create themselves by hard work and that has nothing to do with location.
I do agree with you however in that there is a difference between greatness and adequacy
And we keep going around and shout that and other people believe it. And in turn we are being taken advantage of with long hours, unfair compensation for our contributions and the worse of it all? Ageism in our industry is rampant.
I look at physicians, surgeons, accountants, lawyers and others with envy, because in those professions, the older you get, the more esteemed and valuable you are. We peak at 30.
Note: government is not one of these industries. Developers are underpaid but the job security is real.
Do you mean something like "net value to company"? Then maybe. Another way to say that would be "you start to get paid what you're worth after 30 or 35."
For example, the lawyers I know are now making partner in firms, the business majors getting percentages based on sales and earnings.
I'm looking to become a consultant but the very idea of increasing pay with experience is foreign in the tech field, but standard in other professional trades. I believe offshoring, H1Bs, and lack of a professional association (AMA, bar, etc) is to blame.
At 30 I was just getting started. If you feel you peeked, find some new jobs and technologies that you'd like to have on your resume and find new jobs. How about java and distributed systems at a place like google or facebook, c++ on a major database? Look for those things.
The question is: you've been doing higher level work, but has your compensation flatlined?
I left one of the big internet superstars, and tried a startup. After a year I decided it wasn't going anywhere, so I went to a medium sized company that is really growing. I make slightly more in salary than i did at my internet superstar company, and more $ value in stock grants. My new company is growing so the stock should go up, but its less certain too. My job title looks good, so I will be able to use that in my 'next' job, if there is one; maybe I'll stay here forever. My goal is $400-$500k per year in salary and stock, over a 5 year average. Say you get about 200k in salary, and you get an initial 4 year stock grant, and each year they give you another 4 year one, so it takes several years of that to overlap.
I guess I can say I'm in Seattle.
I was more than 10 years at Microsoft, mostly IC and some lead work, and then back to being an IC at the internet giant, then lead at a startup, now mixed design and dev at the new company; i was hired on dev skills plus experience.
$150k in stock and salary is reasonable for an experienced dev, say 10 years. At the startup we paid mid career good devs 150k in salary, plus worthless options. A typical deal for devs with 10+ years who can do c++, java, distributed programming is 150-175k in salary, a couple 100k in stock, paid over 4 years, plus new grants each year. 2 years ago when twitter was doing better I got almost 200k in salary, plus double that in stock, payable over 4 years.
The unadorned "developer/engineer" role[1] -- that is to say, not CTO or even Lead Engineer -- itself seems to tap out after 8-10 years, in terms of both salary and respect.
That is, in the average case, anyway. There are of course companies which pay upper-tranche (in terms of salary and respect) for very highly talented programmers who aren't in leadership or crossover roles. But these are a comparatively rarified stratum; by and large -- for the great majority of companies out there -- the "Senior Developer / Engineer" role definitely seems to plateau within about that timeframe.
So if you don't find yourself drawn to that category of engineer (and to those kinds of companies -- many truly gifted programmers I've known still pull down decidedly average salaries) -- and you find yourself wanting more salary (or respect / responsibility) -- you better start thinking of something else.
[1] Leaving aside distinctions between "developer" and "engineer", as discussed elsewhere recently, for the sake of simplicity.
A critical problem that exaggerates the "ageism" is people who sit in the same corporation for 15-20 years, get laid off because companies change, and haven't refreshed their skills for many years. I saw my spouse go through this last year. She got laid off from the company where she'd worked in a variety of roles for 13 years. Her field toward the end was product management/ownership, and she liked it, but she didn't like Agile - she'd had bad experiences at her employer with careless engineers using "agile" as an excuse to have no process and no oversight. She had also spent many years developing deep domain experience in a narrow specialty (international e-commerce). She could find generic PM jobs easily enough, but they didn't exercise her domain experience and they didn't want to pay her what she'd been making just to be a generic PM. It took her six months to find a new job that uses her domain expertise (educating herself about Agile along the way).
For people less determined and hardworking than her, the problem can easily be much worse. If you've done nothing but Microfocus Cobol for the past 20 years and suddenly have to find a new job because you employer finally ditched that antique piece of crap, and you aren't interested in learning how to do something modern, you're in a world of hurt.
That was a satori moment for me, now I get the point that agile (and probably most other processes) can be forged into just about anything with a bit of bad will: I've seen the opposite, that is SCRUM used for micromanagement by a boss with control problems.
Some people stay in a job for 15-20 years. They are a programmer for maybe 10 of those, but over time they grow into a niche, the company grows, and that becomes a job title.
Maybe they get called a project manager, or a product owner, head of QA or engineering or lead architect. Either way they aren't a programmer any more and they mostly manage something instead of doing - manage people, contracts, processes, customers...
And that's why programming has a pay ceiling - careerist programmers become something else, and footloose programmers become consultants and contractors and leave the regular pay figures.
The value of a good programmer probably becomes diminishing returns after a certain point. The best programmer in the world can't raise the sales of your web app past a point - if they do what it takes to do that they become something else, like a product manager. That point depends on the technical difficulty of the task and the size of the opportunity, but most code needs a good coder, not a great one, and beyond that it's all product fit, sales and luck.
I'm footloose too, and I'm noticing as I get older that the people interviewing me have often been in their job a long time. They bet on the company and became less flexible in the general labor market in return for better opportunities internally.
Honestly, when I work for them, I'm usually surprised how many normal things they don't know. Maybe they've never seen proper unit testing, or don't know what ITIL is, or think linux is still an immature product and you should stay safe with a microsoft stack.
But they know why the code is the way it is. They know what was tried in the past, and how it failed. And their boss has seen what they do in a crisis, which is much better than trusting someone unpredictable.
My suggestion to someone young, if you have the temperament, is to stay for up to a decade and grow into a new, higher value role. Then learn that until you know it well enough to get a job elsewhere and move before you stagnate.
It's so rare to actually use something made by someone in their 20s, that it is a noteworthy event to mention their age.
Then in my 40s I went back to being a dev and learned a bunch of cool stuff at one of the amazons, googles, facebooks of the world. Now I'm 50 and have another great job, get tired of replying to recruiters.
Look for jobs that teach you great stuff, expand on the important tech skills you don't have, pay well, and look good on your resume.
My experience would support this. You need a mindset keen towards rigor, and motivation. Given those, and guidance, anyone can learn to program - at least in limited contexts.
Programming isn't just about writing the code itself; in many ways, that's the easiest part. It's about identifying and solving problems, many of which aren't actually your problems, meaning you have to have the ability to step outside your own frame of reference to understand the problem in the first place and continue doing so in order to work up a solution. Even for a junior developer, those skills can be a huge boon.
Learning, say, Wittgenstein's philosophy regarding grammar and language [1] gives an interesting insight into how humans express ourselves and delves directly into the heart of modern programming, IMHO. Rarely do we software developers write low level algorithms anymore, but writing consistent and complex API's is crucial and shares more in common with be conversant with large volumes of philosophical treatises.
Based on that, it makes sense many philosophy students would have successful careers – being able to reason and solve challenging problems is always key point in making good money. :)
[1]: http://plato.stanford.edu/entries/wittgenstein/#Gra
Don't take things too literally. What he basically meant was "anyone with appropriate aptitude and intellectual maturity" -- like you yourself said later on, pretty much.
Which may or may not be entirely correct, but is far from "dead wrong."
BTW, please be careful about referring to foreigners, in any context, as "monkeys."
I just got back from an business trip spanning 3 cities and 5 flights. The self-loading cargo in the airports, jetways, and boarding the plane could easily have been described as monkeys. I was literally called a monkey by a colleague for absent-mindedly and needlessly blocking a sidewalk in the parking lot while waiting for someone to pay for parking. I took no offense, of course.
My point is that if you do not understand that programming is highly skilled work (and many companies think this) then you might think you can get anyone to do it for a similar outcome and therefore it is a commodity and therefore the only thing that matters is price.
Just that even analytical people tend to think "associationally" when they see certain keywords -- and one has to keep in mind that not too long ago, people in many of the countries that software development is frequently outsourced to were, in fact, thought of as monkeys, pretty much (or something on the human-monkey spectrum).
So whenever I see associations like that creeping into my own writing, I try to dial it down.
http://theconversation.com/the-ape-insult-a-short-history-of...
I'm not a 10x programmer by any means, but I was able to write and sell non-trivial software in middle school, with little more than a pirated copy of Delphi and a book.
Most of the difficulty that does exist has more to do with bad engineering practice and poor documentation than anything else.
They tried this during the dot-com boom of the late 90's... I don't think it worked out too well.
They hired just about anyone and paid crazy rates. You could point them out for showing up their first day carrying a "learn ASP in 24 hrs" book.
Fortunately, the dot-com bust weeded them out. Most of these people went back to sell cars or whatever they were doing before while we had to clean out their messes.
I don't think this proves your point. Just hiring someone to do a job does not equal teaching them. Teaching means not only practice, but also well constructed feedback and sufficient time and space to learn, and to learn from ones mistakes.
Kludging an ASP application together after reading "learn ASP in 24 hrs" does teach something, but there is so much noise that you need expert guidance to interpret the results correctly and point into things that need improving.
It's hard to even describe what a change in productivity all this stuff was. Using an ORM to get data from a database and dumping it into html tables, and there was a browser that could format it all for display with nothing but some tags that were generated on the fly? Amazing!
I taught myself html, because there wasn't anyone to teach me. I taught myself server-side includes and cgi - no one to teach me. I taught myself Java. Etc. And I still do this today! If someone can teach you how to do something, it's already mainstream.
"If someone can teach you how to do something, it's already mainstream."
I don't think collaborative learning should be undervalued, though. There are several colleagues without whose example and input I would be a much worse programmer. Not in technical details, but harder to define things, like attitude that leads to success and how to make designs simpler.
'Mainstream' does not mean obsolete. Reading and writing and Roman alphabet have been mainstream for centuries, yet people utilize them with an amazing variance of productivity and value.
And IT in general was much more slow-moving since then -- even companies with lots of technical staff couldn't (easily) find people to adapt to the crazy quilt of languages (and yes, paradigms) that burst onto the scene.
So if you had even the slightest idea how a website worked -- your were like a gift from high heaven, and treated as such.
These days -- especially in larger cities, near everyone has social contact with some of the programming persuasion; many have dabbled in some form of scripting, at least, themselves; and you can't walk into a coffeeshop or ride a subway train without being immersed in techspeak.
So things have changed quite a bit, and correspondingly, the bar has been raised.
Some people are not just hitting keys.
The utterly meaningless "top 1%" metric always makes me laugh. By definition then 99 of every 100 engineers don't make that cut, which means, again by definition, your team has very few if any of them, no matter what hiring practices you employ.
Plus I've found that very often management uses the "oh we hired the wrong people" as an easy cover for its own failings.
One of these things is not like the others.
And... Interviews are awful. Seeing how someone work is even better. This is one reason why employee referrals are so important, and audition or temp-projects a good second-best method.
In the end I think it's a Fools Game though - someone who is best in one environment may not be that great for the next. Managing people post-hire is something that can't be avoided.
Every startup needs a few of the best. You should definitely seek out and pay for those few. After that, even a startup has jobs that don't require the best. Hire for potential, attitude, chemistry. Hire for special knowledge when you have to (though you should try to avoid it). But don't demand that every hire be among the proven elite.
The absolutely best employees I've seen haven't been frequent job hoppers. At most it's every 3-5 years. I'm thinking of an unscientific sample size of 5 or 6 people who have had sustained outstanding technical performance of 10-25 years. Companies don't let people like them go. And they tend to be loyal to the mission if treated fairly.
Now a company with $1mm of seed money that's supposed to last 12-18 months can't afford to hire 5 people like that. There's not enough cash or equity to go around.
Thanks for sharing.
I thought that the increase was largely attributed to more women being willing to audition anonymously?
> if that describes you, and you have serious Linux, Ruby, and JavaScript chops, perhaps you should email me
I don't know why, but I always thought the Atwood was 100% invested in Microsoft technologies. Not that it matters, it just surprised me.
Speaking of Atwood, has anybody ever used one of his keyboards? Any opinions?
Claudia Goldin was one of the authors of this study: https://www.aeaweb.org/articles.php?doi=10.1257/aer.90.4.715
She was able to attribute 25% of the increase in hiring of women by orchestras was due to the blind auditions. She also found that there was an explosion of auditions when orchestras adopted the blind format.
So it had an effect, just not as large as I thought.
Honestly, if you're a straight guy, why wouldn't you want pretty young women working with you?
Seriously, what kind of straight man only wants to be around men all day long, and then (assuming he's married) come home every day to the same woman, and never get to socialize with any other women? Maybe a religious fundamentalist, but not any normal man.
1. Why should women be judged on attractiveness? Men are not generally judged on this standard to join orchestras or do office work. It also, perversely, punishes women for being experienced while men benefit from it, handicapping their lifetime earning power. Professional women probably do not want to spend their lives judged as eye candy.
2. Because of the first point you will still end up with a strong male bias on top of whatever natural one training creates; after all, we're looking at men of any age versus young women, for the most part, in this scenario.
3. The numbers clearly do not bear out the assertion you're making in the first place, since blind auditions significantly increase the likelihood of women being hired after auditioning. It seems your "self-evident" reasoning does not fit the facts.
4. I do not think it is true that all men want to spend more time socializing with women. I don't see how the logic you're positing works unless sexual harassment is just outright permitted. If you're not convinced that sexual harassment is bad then I guess you're operating on a different plane than most of us.
I'll go backwards: 4. So you think that most men would prefer to not have any women around them most of the time, and only want to socialize with other men? I don't know if that's true or not, but it certainly isn't the case with me. I don't really want to work in a monastery-like atmosphere devoid of females (attractive or not).
3. Maybe, but that's what I'm asking about: why would straight men only want to be around other men? Seriously, I really don't understand this at all. Are most men repressed gays or something? I actually like being in mixed environments, even if I'm not attracted to most or even any of the women. Am I weird that way?
1-2. You seem to be claiming that men aren't also judged on attractiveness, and this seems wrong. I'm quite sure a lot of studies have shown that men are indeed judged on attractiveness, though the standard is somewhat different than for men (it doesn't disfavor older men as much). Just go find a short guy (or worse, a short fat guy) and ask him how his life is going and if he perceives any discrimination.
Anyway, my point all along has not been that only young pretty women should be hired, as you seem to think, my point was that I don't understand why men would discriminate against women in hiring, because to do so would mean you're surrounding yourself with a bunch of dudes, and as I said above, I don't know about other men, but I for one do not enjoy "sausagefests"; I like mixed environments.
The reason I get the idea that you're advocating sexual harassment is that you keep casting this in sexual terms -- why would you want to be surrounded by men, unless you're gay? Work is not a sexual environment (let's ignore the exceptions for this conversation); why is sexual orientation relevant? Saying "hey, aren't you heterosexual? Then why don't you hire women?" manages to promote a progressive cause with regressive reasoning.
I will concede that men, too, are judged by appearance, but I think that the standard is far more lenient and, as you said, tolerant of age.
In any event, the auditions are meant to judge skill. The conclusion I reach from the success of blind auditions is that evaluators perceive playing as less skillful when they know it is done by a woman.
So you think that if I'm not actively looking for sex from women, that I should be perfectly happy to live a life completely devoid of any kind of female contact whatsoever?
That seems extremely disturbing to me.
Does that also mean that if I'm not actively looking to have a sex partner of a different race/ethnicity, then I should be perfectly happy to never have any kind of contact with people from other ethnic groups?
Wow, I guess on HN I'm just a real weirdo because I don't want to be surrounded by white males and be completely cut off from contact with other kinds of people.
This is what you wrote. So, no, I think you're just trying to walk away from the implications of what you wrote because you are embarrassed. How do you propose interpreting that without any sexual bent?
Instead of spending money on needlessly complicated hiring processes, with back and forth phone calls, panel Skype interviews, foolish interactive coding exams, multiple on-sites, etc., you can spend that money on severance.
Use a cheaper and more straightforward hiring process. Talk to people, dig into their background and preferred working style a little. If they appear to be competent, then just hire them. If they are not qualified for the job or they are not a cultural fit later, just fire them.
Because you will have explained to them that their first month on the job is still part of the overall fit assessment, and that you value the risk they are taking by offering them severance to re-engage in a job search if it turns out you made a mistake by hiring them, you are not doing a disservice to the new hire. You're merely letting both parties gather more evidence about goodness of fit.
This is money well spent, and for most companies, 6 months of salary is easily affordable for severance. In fact, an unwillingness to offer at least that much to each new hire would be a huge red flag.
Automattic does something interesting from what I've read. They have you work there as a trial for 1-2 months while keeping your full time job. This is probably pretty stressful but you get the ability to work with the candidate while not asking them to sacrifice their livelihood if things don't work out. Needless to say, it seems a lot of people don't get hired after the trial.
Maybe, maybe not. If they are already on the job market, then they probably don't mind looking for a job. If they feel that taking your job and getting fired still leaves them financially covered for an additional 6 months of searching, then they may not care too much.
If that company becomes known for this, then being "fired" from them won't really be a bad signal on your resume (if you even want to list it on your resume at all, depending on how long of a stint it is).
I don't think my idea is perfect. No hiring method is perfect. But I think that businesses should take a perspective that's fundamentally more about investing in getting to know and support someone as they are on-boarded, instead of Spanish Inquisitioning them and if they don't run away screaming then rationalizing that you've hired the best possible person (who, surprise, leaves after 18 months anyway because you didn't assess their fit or how their aptitudes really match up with job needs, you just whiteboard hazed them).
It probably depends on lots of factors, but I do like the consulting idea better.
This is already caused as much by companies as it is by candidates who are job hoppers. When I see a resume with short stints, it basically has no effect on me any more. If the person is good and I do my job to make them happy to stay, that's the best I can hope for. Pretending like either I can predict who the job hoppers are in advance, or that I should only hire people who magically have some intrinsic desire to work for me no matter how I treat them are both fantasies.
It's only that, if one is on that position, there won't be much downside to take your offer. But if one currently has a stable job, there is.
If I am very good at this assessment, then this may work. However, if I trust my skills to assess someone accurately, I am unlikely to have a complicated hiring process.
If I am a company owner (or manager!) who is not good at assessing people this way, then wouldn't substituting my process with this proposal make me spend a lot of money twice?
1) Paying salary to more people than open positions (Because I don't spend money on a hiring process and rely on my assessment skills, I may end up with many not-so-best-fits)
2) Severance package to let them go
I am not sure I believe this. First, if you are aware that you're not good at assessing it, then have someone else in your company do the assessment, or hire someone who can (possibly on the advice of your investors or something).
If you can't do either of those, I am afraid your business just isn't going to work out.
So, almost by definition, the person doing the assessment is reasonably good at it. For otherwise, you won't be around very long regardless.
Also, if you find that you're hiring a lot of people who seem good, but ultimately are fired, maybe look in the mirror. Maybe it is that your expectations are unrealistic, or maybe you expect people to adhere to "culture" standards that do not support human flourishing.
Unless the tech problem you need to solve involves lasering in on a fleetingly tiny population of candidates (most don't), then a sequence of looked-competent-but-needed-to-fire people is probably more a reflection on the company than the candidate stream. It's unlikely that all of them were elaborate fakers.
The costs of (1) should be low unless there's a fundamental problem with the company (in which case the costs of (1) are way cheaper than hiring a management consultant to help you not fix it).
(2) is a real cost, and yes, some companies can't afford it (so maybe they scale back to 3 months severance? Maybe they add continued health coverage. Maybe they let you pick a foosball table to keep) ... but it is just the cost of getting useful information about an employee, instead of the not-very-useful info that most hiring processes generate.
If you don't have the skills for that assessment, how do you know your complicated hiring process works?
If it'll be good or bad depends on the actual risk balance you create between those two processes. But if the idea that the hyper strict hiring process does not help selecting great candidates, a moderate increase on nominal risk on the hiring process will actually improve your odds there, and you'll gain both ways.
This is the entire problem with the inability to hire the "best"; It's dangerous to try and fail with lawsuits, unemployment, etc. I personally prefer to work for companies that don't hold on to poor employees and have quit companies that do the opposite. If you want to "hire the best" you have to "fire the worst". I accept the risk that comes with this of course (and many others may not).
The costs of sustaining a job search after being fired are a bit different than the costs of living while you have a reliable income stream. The grossing-up part is meant to reflect a nominal amount of money to cover those kinds of costs, not just a virtual continuation of the salary-less-taxes you'd been living on while employed.
In my experience, severance and sign on bonuses are often grossed up, as are payments made for relocation expenses.
But there's no reason to be hung up on that part. It's perfectly fine to just offer a regular severance benefit without grossing it up.
If I pay relocation expenses, I require receipts (at which point, it's non-taxable for most situations, so doesn't need grossing up). It's not that I disbelieve the new hire, but rather that I have to make it accountable in order to make it non-taxable.
If I pay cash comp (whether as a signing bonus, periodic bonus, commission, in contemplation of on-going employment, or as part of a termination agreement), they're wages in my book and I've never seen them grossed up (unless more of the character of the gift card or Christmas ham variety).
This might be a deal breaker for me if I was interviewing with someone. It's not that I care about the accountability part, it's more that a ton of relocation costs are unforeseen incidentals, or are private expenses (like first month's rent ... it's not your business what I choose to pay in rent), that should be covered by just paying cash to the new hire. Making them track down receipts for all of it might work out to be more costly, in terms of time lost, than just bearing the taxes, and certainly might involve requiring knowledge of expenses the employee may rightfully prefer to keep private.
Usually, I expect that the company will handle almost all aspects of relocation on their own (e.g. buying plane tickets and hotel rental for housing visit, calling up and hiring the moving company to pack and ship belongings). The part that would be paid as cash would be the cost of rental fees, deposit, and first month's rent, as well as some small amount for incidentals, which should be grossed up.
On the other stuff I guess we just disagree. I don't view sign-on bonus or severance pay as wage pay, even if they are pegged to wage level. For the other stuff, I agree, it's just part of regular income and the employee should bear the tax. But for sign on bonuses and severance, I think it's fair for the employer to bear the tax in light of the purposes of those payments.
Sign on bonuses are very different in this discussion though, since not everyone provides them and the amounts can vary a lot and for low amounts grossing up can matter significantly, while for larger amounts, employees are usually happy to bear the tax cost themselves. I'm not so worried about what an employer's policy is for these.
It would matter to me to negotiate a specific value paid for severance, though, rather than "6 months' salary" which will then have taxes taken out. If an employer was put off by this, it could be a problem, depending on all the other aspects of the job. One way to avoid this is that if secretly what I want is 6 months severance grossed up, then I'll try to negotiate 9 months severance, without mentioning the grossing up part. It's less off-putting to the counterparty, even if it would be nicer if I could just speak plainly.
I'm just speaking from my experience as a candidate in previous roles. I'm sure everyone has different experiences.
I (and I assume most hiring managers) have broad discretion on the amount of a signing bonus. For an engineer I want, I will never care about the difference between a $5K and a $10K signing bonus (or if we're talking about bonus in lieu of relo, the difference between $15K and $25K). It's a one-time expense to me, comes out of a different budget, and yet candidates seem to really value them seemingly out of proportion to the economic benefit.
Some firms offer > $30k signing bonuses (some more than double that) independently of relocation. It's rare, but not exceedingly rare.
A successful sports team should hire the best, even if that's what everyone else is trying to do too.
Yes, but sports teams recognize "the best" is dependent on the other pieces in the organization. Teams that try to stack their rosters with "the best" in objective measure typically crash and burn. Teams that recognize "the best" is whomever fits the team's scheme and current players the best succeed. Too many software companies want the first sense instead of the second.
No, this can't work at e.g. the NFL. There is a $155 million per year hard salary cap. There are 53 players which much be paid under this cap. Which means the average salary is just under $3 million.
One of "the best" quarterbacks gets paid $20 million."The best" at various other key positions such as left tackle and defensive end and at cornerback can easily get paid $10 million each.
Even if you forget about special teams, you can't afford to pay 11 offensive players $10 million each plus 11 defensive players $10 million each.
Which means that you pay a few superstars at $10 million or more, some more good players $5 million, a bunch of OK players $3 million, and a bunch of rookies and scrubs under $1 million each.
Nobody can afford to hire the best at everything. I'm sure that's just as true in business as it is in sports.
My current company doesn't hire the best, but instead focuses on people who enjoy making impact in a small team, share the same vision and have a bit of an entrepreneur in them. We don't quiz people or give them tests. We just sit down with them and start talking tech. The results are really amazing and make for a great place to work because everyone feels like the project they work on is their baby.