We only hire the trendiest - <AUTHOR> http://danluu.com/programmer-moneyball/ <comment><USER5> I've found that the best predictors of a good hire are indications of the following characteristics during the interview/vetting process:

\- adaptability -- can this person deal with situations that are spontaneous and unplanned without losing his/her cool.

\- openness -- is this person instinctively scornful of new concepts/ideas or energized by the chance to be exposed to something potentially interesting.

\- resourcefulness -- has this person found ways to keep learning after college and has he/she continued to up his/her game.

\- desire to ship -- does this person have a deep desire to produce work that will be used by others.

\- desire to grow -- does this person have clear career growth goals. Ideally these are not tied to titles or bossing others around, which are negatives.

\- rationality -- can this person admit to being wrong and speak about it authentically... can I imagine this person admitting to being slightly wrong and even very wrong about something and handling it gracefully.

\- territoriality -- does this person seem territorial or speak about issues of proudly defending turf in previous positions? Doing so is a negative.

\- poker face -- does this person seem to be playing it close to the vest in the interview or otherwise have very low levels of openness? This is a big warning sign and an instant do not hire.

<comment><USER6> > \- rationality -- can this person admit to being wrong and speak about it > authentically... can I imagine this person admitting to being slightly wrong > and even very wrong about something and handling it gracefully.

I think this is a super important characteristic for a great employee to have, but I don't know how reasonable it is to expect to see much of it in an interview. In an interview setting, the candidate is under a lot of pressure to come across as "perfect" in the sense that they want to appear to meet all of the expectations the interviewer has for them.

Asking about mistakes they have made, or putting them in a position to make a mistake during the interview itself can just be really stressful. Candidates that think you want them to make no mistakes will feel they are doing poorly. Candidates that know you want them to be comfortable being wrong—whether or not they actually are—can easily game this.

> \- poker face -- does this person seem to be playing it close to the vest in > the interview or otherwise have very low levels of openness? This is a big > warning sign and an instant do not hire.

One of the things I've heard from HR/recruiting folks is that it's not a good idea to use body language as a signal. There's a lot of cultural and personality variation around it. You can end up with an unfairly biased opinion simply because they come from a culture that is not very demonstrative, or they are introverted or otherwise have personality traits that lead them to not display a lot of emotion or energy.

I agree with all of the characteristics you list here. It's a great snapshot of what I like in a good coworker. But, man, accurately detecting them in an interview seems super hard to me. But maybe I just don't have much confidence in my own interviewing skills.

<comment><USER7> On the rationality point, I've definitely been one to talk openly when asked about times I've failed / would have done something differently. I've looked at it as a no-loss scenario: if I'm talking with a company and they can't accept that no one is perfect, then I'd rather not work for that company anyways.

Interviewing in a sense is kinda like dating, one way to really screw things up is if you're both looking for different things. If you're both trying to get into a fling, then yeah I guess lie your pants off and have unreasonable expectations of each other. If you're looking for long-term match, just lay your cards on the table and if you match, you match.

<comment><USER8> There is one rather big key difference in dating versus interviews. You only get once chance to find out _everything_ about a company during an interview. Whereas dating has many "meetings". This is the real problem with interviews. They're an all or nothing.

<comment><USER9> Many selective companies have many phone screens and coding projects, plus hours of on site interviewing. Google's process notoriously takes months. Some companies interviews likely take 10+ hours all in all. That's more like 3rd date territory in terms of hours spent together, and plenty of time to evaluate a hire, not some one shot thing.

<comment><USER10> Google's process consists essentially of 2 meetings - phone screen, and onsites. You don't get engaged to someone after the second or third date. It's not about hours spent, it's also about hours spent reflecting on the relationship.

<comment><USER11> So right here is the mysterious reason why perfectly qualified people don't get hired at Google - _they didn 't spend hours reflecting on the relationship_!!!

<comment><USER10> I realize you're trying to mock me, but you've totally failed because that's exactly my point. If your interview process consisted of a 6 month work trial period for every single candidate (and assuming no candidates dropped out), you would pretty much be able to detect nearly every single qualified person. Of course, this is not feasible in practice, so we settle for interviews.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Daniel Kahneman talks about an idea called substitution in his book Thinking Fast and Slow that I think really applies here. Here's the jist: When your brain is faced with doing a task that's going to require a lot of glucose it will look for shortcuts to save you energy. One of those shortcuts is your mind will look for an available heuristic, swap out the energy hungry analysis for the heuristic, and then signal your conscious mind that you did all the analytical hard work.

[https://erikreads.files.wordpress.com/2014/04/thinking- fast-...](https://erikreads.files.wordpress.com/2014/04/thinking-fast-and- slow-book-summary.pdf)

I think the truth of that matter is, most of us (myself included), don't know how to interview people well. Interviewing is really hard. Rather than doing the hard work by researching the subject and testing ideas, most of us try to imitate successful companies much in the same way the Melanesian cargo cults imitated the construction of airfields and air traffic control towers to lure back that wonderful cargo.

I suspect we like to tell ourselves that we're more analytical because our work can demand rigorous precision. More often than not, I find we developers tend to select heuristics that indirectly test a person on how similar they are to ourselves or people we aspire to be like. Then again, I'm probably making a broad generalization.

<comment><USER13> >When your brain is faced with doing a task that's going to require a lot of glucose it will look for shortcuts to save you energy. One of those shortcuts is your mind will look for an available heuristic, swap out the energy hungry analysis for the heuristic, and then signal your conscious mind that you did all the analytical hard work.

Sorry I didn't read the book but I am curious if there is any scientific evidence to back this up.

<comment><USER14> I have heard there are MRI studies that back this up. Basically people make instinctual decisions and the rational parts of their brains light up afterwards to rationalize the decision they have already made. I am on mobile but that should be searchable.

Humans are very good at pattern recognition and we're optimized for it. Real calculation takes time and energy and might make us less able to survive.

<comment><USER15> > Real calculation takes time and energy and might make us less able to > survive.

Sometimes that grass moving strangely is just the wind..sometimes it's the tiger, the ancestors who sat down to have a good think about it got eaten.

When I was younger and played chess my teacher drilled into me that when you find a good move that's the time to look for a better one, we instinctively play the first 'good' move we see, in fact manoeuvring your opponent into a trap by giving them an obvious 'good' move is effective against people who don't play a lot and very ineffective against people who do (and even then vastly stronger players than I ever was still fall for it occasionally).

</comment></comment></comment></comment><comment><USER16> I sometimes think there's a built in pomposity in the whole attitude of hiring, looking for someone "good enough to qualify." Instead, I like to think of it as, we are looking for someone to _help us_ , someone who has different experience and knowledge, someone who could tell us how we can improve. Then instead of this adversarial situation of selecting a new ingroup member, it's a solicitation for assistance with a built in humility.

<comment><USER17> Appreciate the humanization of both job candidates and employers inherent in the shift you advocate.

I have done a bit of hiring and it was very hard to walk the line between effective use of my time and being open to people with all kinds of experience. (It was a junior position and I talked to some very junior candidates.)

But it is always important to remember that there is a human being on both sides of the table.

<comment> J-dawg Could you expand on how you ended up walking that line? Did you feel you wasted your time on under-qualified people? Did you end up hiring anyone who initially didn't seem like a textbook candidate? If so, how did they turn out?

The reason I ask is that I've always been nervous about applying for jobs when I don't have every skill listed on the ad.

The advice I've been given is usually something like "Apply anyway. The job advert is a wish list, not a minimum."

But I'm still terrified of an interviewer opening my CV and asking how the hell I slipped through the screening process. Or even worse, being too polite to be so blunt and awkwardly going through the motions of an interview.

It would be awesome to get the perspective of an interviewer.

<comment><USER17> Hi.

I definitely wasted time interviewing underqualified people. But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front). Actually, all of interviewing feels like wasted time (you have this burning need, and you want to fill it yesterday, or better yet a month ago, and yet you have to go through this process and learn about all these strangers, while the building feels like it is on fire).

Note that I said _feels_ like wasted time, not _is_ wasted time. It's a bit like learning a new programming language--you end up going down lots of blind alleys before you find the way you really want to go.

(All we could afford was non textbook candidates, and out of 3 hires, 2 worked out.)

As far as walking the line, as I got more comfortable interviewing, I always worked off a rubric, and set things up so that I could ease out of a phone interview early if it was clear that they didn't live up to their resume. Ended up doing the same thing with the in person interviews as well. Definitely screened by resume.

> I've always been nervous about applying for jobs when I don't have every > skill listed on the ad.

This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements. And you don't know before applying. (And sometimes the goal posts in the organization move when their "requirements" meet the labor market.)

Personally, I'd apply if you have half of the requirements and feel like you can speak to the way you learn.

If you're interested in the company, I'd also take the extra step and do some work around it, whether that's writing a pain letter ( [http://www.forbes.com/sites/lizryan/2015/03/01/how-to- write-...](http://www.forbes.com/sites/lizryan/2015/03/01/how-to-write-your- first-pain-letter/) ) or writing a simple client against someone's external API or creeping^Hscanning LinkedIn, Twitter and Github profiles and finding out about the team and company.

Good luck!

<comment><USER18> >But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front).

Well that's your own fault as the job advertiser, and when I say "you", I mean _almost all_ companies that advertise jobs. You almost never state the salaries to be paid, so tons of peoples' time gets wasted by pointless interviewing which gets followed up with insultingly low salary offers.

If you're a cheap-ass and want to pay a pathetic salary, you should state this in your job ad, so that non-deadwood people don't bother to apply to your job.

>This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements.

It's not that hard to tell the difference. When the word "required" is used, that sounds like a requirement to me. When a separate list is preceded by "nice to have", "plusses", etc., those are obviously skills that the company would like to have in a candidate, but are not hard-and-fast requirements. If the company is so stupid they can't write a simple job advertisement this way, and they use the word "requirements" or "required" when they really meant "nice to have", then they don't deserve any employees at all.

<comment><USER17> Why should the company lead with what they are willing to pay? Why is it on the company and not the possible employee? Why shouldn't every phone screen begin with the possible employee saying "this is my salary range" and politely exiting the call if the screener won't validate that the salary offered is within that range?

When I buy a car, the person selling the car sets the price. I can take it or leave it.

When I rent a house, the landlord sets the price. I can take it or leave it.

When I'm selling my labor as an employee, why am I not the person setting the price that the company takes or leaves?

I'll tell you why, because the first party to state a number in any negotiation is at a disadvantage, because the counter party suddenly has more information.

Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point, but if I ran a company, I'd want to justify that. (There's also a case to be made that, especially with knowledge work, the employee has an asymmetrical advantage because they know how hard they are working, and it's hard for the employer to know.)

That said, when I enter into a new engagement to sell my labor, aka an interview, I do my best to make sure they want to buy my time before I set a price. It's negotiation.

Edit: I love the parent comment even though we disagree, upvoted.

<comment><USER18> >Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point

That's exactly why I think the employer should give up that negotiating point.

The other reason is that employers are constantly whining about how they don't have enough engineers, can't find qualified people, etc., and then lobbying Congress to do something about it. Employees don't have this kind of political power.

Finally, I wouldn't mind if negotiation were simply eliminated with job salaries. You don't negotiate with the cashier at Walmart about how much you're going to pay for some vegetables or a TV. The price is the price, take it or leave it. It'd be better if everything were that way, so that consumers could compare things more accurately. There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There's a reason for that.

<comment><USER19> _There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There 's a reason for that_

That's a big claim that you make very authoritatively. You should back it up, or change your wording to better express that you're making a hypothesis without much evidence.

<comment><USER20> Well as for some prominent examples haggling is considered bad form for small transactions in the nordic countries and they do kind of well. All the places I go to that have a culture of haggling seems to be way worse off.

I guess others can provide more data points that points in this direction but I'd also appreciate counterexamples.

<comment><USER21> You've identified a correlation.

What solipsism is objecting to ("big claim"/"hypothesis") is the statement "There's a reason for that", which implies that there's a causal relationship between the prevalence of haggling and countries being "backwards and economic disasters" (for which there's been no evidence provided).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> There have been a number of posts about hiring practices lately. And a lot of them contradict each other. My conclusion is, that people hire people that are similar to _themselves_ or similar to how they would like to see _themselves_ , and the whole hiring process, the style of interviews and coding tasks and the sources from which they hire, is based upon this model.

A company founded by Stanford CS students will focus on ivy league CS students; friends of mine have a pretty successful consulting company and none of them has a formal CS background, but years of experience delivering complex software; they focus on guys that can deliver, regardless of background. Some people never went to MIT, but have a deeply ingrained wish that they would have - by surrounding themselves with MIT grads, they suddenly generate the wanted association.

<comment><USER23> Most hiring processes spend gigantic amounts of effort to see how a candidate works as a member of the team, without actually having the candidate... work as a member of the team.

I suspect that the reason why, is that so few engineering teams do pair programming full-time, complete with daily-or-more rotations.

Pairing gives you the ability to spin somebody up rapidly enough to see how well they do on real code, and at the same time get a good read on personal fit from multiple team members.

Pivotal is _shockingly_ good at this. You start with an hour-long pairing exercise over the phone. If that goes well, you come in, sign an NDA, and pair on two different projects, with a block for lunch in the middle.

That's a grand total of ten hours of screening time.

This process isn't fool-proof, mind you. But it does do a good job of answering the most important question: Do I want to show up for work, tomorrow, and start working with this person?

Perhaps just as importantly, it gives the candidate enough information to answer that same question for themselves.

Nothing tells you whether or not you want to work somewhere, like actually working there.

<comment><USER24> What's the compensation like for 10+ hours of work?

<comment><USER25> Great answer. When I see these ideas floated around, I always think that these companies will never hire people who value their time and have at least a decent job. When a company comes to me with these great "deals" the first thing I say is thank you very much and move their emails to my spam box.

<comment><USER26> And that saves them the hasle of extending an offer to someone who doesn't want the job because it doesn't offer enough life improvement. Win/Win

</comment></comment></comment></comment></comment><comment><USER27> I once had an internal recruiter tell me during a phone screen that my resume was weak since I went to a no-name school in the south called Georgia Tech.

During my last interview round, another interviewer found it hard to believe that I did not use Twitter.

I think these problems existing more in the "trendy" areas such as the Bay area. Once you leave that culture, ignorant recruiters are still around, but the exclusivity is less.

<comment><USER28> Georgia Tech is a no-name school? Ridiculous.

I did not go there but all the engineers I've had the pleasure of meeting from there seem to know their stuff.

Which is far, far, more than I can say for my alma mater.

<comment><USER29> It's a joke, Georgia Tech is top 10

<comment><USER30> One of the 25 top 10 schools in fact

</comment></comment></comment></comment><comment><USER31> I see wonderful symmetry here. There are TrendyCos (hot startup unicorns), BigCos (established companies like google or amazon or microsoft) and UnknownCos (not in the limelight so there is not much information about them). Likewise there are TrendyDevs (hotshots who produce one heavily github-starred framework after another), BigCoDevs (multiple years of experience at one of the BigCos, probably were responsible for some important part of one of their numerous services) and UnknownDevs (been there done that, hard to say).

And here is the rub. There are certainly many undervalued gems among UnknownCos and UnknownDevs but also many abysmally bad workplaces and programmers. So you either have some inside knowledge about them (a referral, an acquaintance working at UnknownCo), have some magic method for separating the gems (like tptacek claims to possess) or it is just too risky to consider them.

<comment><USER32> There's no magic to it at all. Have every candidate work on programming problems related to the work you do at your company. Have every candidate work on the same problems, and let them do it from home. Build and iterate on a rubric for grading those challenges.

It is amazing to me that almost nobody does this, but: almost nobody does this. They have programmers write code on a whiteboard, or on some whiteboard- coding site; they have them do programming puzzles ("solve Towers of Hanoi non-recursively"), they have them talk about code, or, more likely, computer science trivia. They'll have them "pair off" with one of their own programmers and "fix a bug". They'll have them work as a 1099 for a month to see if they're any good.

In reality, most companies are trying to hire on trendiness; they want people from the right schools and/or the right cohort of companies. They're aggressively courting friends and colleagues of their existing team, and the special people get very different interviews than everyone else. The actual technical evaluation is mostly a facade.

<comment><USER33>
        Have every candidate work on the same problems, and
        let them do it from home

To be fair, I've seen a lot of good arguments against programming assignments. I think at the end of the day, the employer needs to conduct some method of determining if the employee has the technical capabilities needed for the specific job they're being hired for. However, there are MANY other factors too like "how well they get along with the team" that need to be considered. That's what they're trying to determine with the pairings and other stuff you mentioned I think. Whether that works is another story.

<comment><USER32> Every team I've talked to starts out with some X-factor they think they need to assess for. It's my belief that if you can have the discipline to stop filtering for X-factors, you'll build better, more effective teams, because those factors are really just vectors for personal biases.

Regardless of whether you agree with me about that, I think we can all stipulate that if work-sample technical evaluations work (and: they do), most of what companies try to evaluate in on-site interviews is stupid. No part of working effectively with a team requires timed recall of how to implement a stable quicksort, or reversing a doubly linked list at a whiteboard.

At the very least, using work sample tests allows you to build an on-site interview process that honestly engages with "team fit" (or whatever your X-factor is).

My guess, though, is that when more teams adopt work samples and then go through the motions of trying to design a pure team-fit interview, they're going to realize --- once they don't have "implement Bellman-Ford on this whiteboard" to fall back on --- how unequipped they always were to evaluate team-fit in the first place.

<comment><USER34> The problem could also be that many teams simply don't have the time or possess the knowledge to do an assessment like you're suggesting (which I agree is a good way to assess candidates). It requires someone to actually design an assignment (which is a task that many coders might not be good at), and requires one or more people to evaluate it.

The ridiculous whiteboard coding of puzzles probably stems from laziness or inability to implement what you're suggesting. I know that personally, if someone asked me to developed a work sample evaluation for my job, it would take me many hours to come up with something, and frankly I even once complete we would have no way of knowing if it is actually a good predictor of whether or not someone is the right employee.

<comment><USER32> Hours? It could take a week, and if you're going to hire more than one person this quarter, it will still be worth it _just in the time savings from not having developers deliver bad interviews_.

<comment><USER35> Have you done this? My worry would be that sooner or later you'll have a candidate who posts the assignment online ruining your weeks of effort. It also seems like it makes it much easier to cheat if you make it a take home.

<comment><USER32> Yes, I ran a process like this for several years. I ran recruiting for the largest software security firm in the US; before that firm bought us, I used this process to more than double the size of my company. When I left, to work on a recruiting startup, not one of the people I'd overseen hiring had quit or been fired.

I'm religious about this topic for a reason. :)

<comment><USER36> Was the 0% turnover due to great teammates, great projects, or above-market comp? I've _never_ seen 0%!

<comment><USER32> We paid the market median to new hires; we definitely didn't buy our way to that turnover (NCC pays better than a lot of early stage startups, but not better than late-stage ones).

No, I attribute the turnover to the recruiting mechanism. We found great people who were sorely mispriced by the market, and we took advantage of that to create a win-win scenario: people without the resume to get a similar job at a competing firm got an extremely impactful resume bullet and a good-paying job, and we got people who genuinely wanted to be on our team and weren't applying as a once-a-year lateral job-hopping gamble.

(I have no problem with people job-hopping, by the way, but every employer is trying to minimize their exposure to that.)

<comment><USER37> You were also recruiting for a "cool" sector where people would be learning marketable skills. Do you have any evidence that the same technique would work for more "boring" companies? (I ask because I'd like to convince my manager that creating a work-sample test wouldn't be a waste of time)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> "Contractors are generally not the strongest technically"

Where does this come from? I actually see a contractor as someone who had experienced way more "war stories" than the guy who has been sitting in the same chair for 10/20 years. As a contractor, you are exposed to more technologies, more business sectors, different working cultures.

<comment><USER39> "Consulting" or "contracting" can refer to different kinds of work arrangements. One of these is what's called "staff augmentation."

Large companies with huge teams of full-time employed software programmers will often hire contractors to fill gaps. These contractors are typically contractors-in-name-only: they work under exactly the same conditions as full- time employees but with a worse tax situation, without access to benefits, and without eligibility to receive equity or cash bonuses. They are often contracted through intermediaries who take a large cut. These contractors can be fired more easily than their full-time employed colleagues, and they may often work on time-limited contracts that cannot be renewed. (They often do not count against a manager's allotted "head count.")

These contractors are typically in this position, because cannot get hired as full-time employees. They often jump between contracting jobs until someone gives them a chance or until they manage to get a client to "convert" them to full-time.

Staffing firms are in on this. If a recruiter sends you to interview for a contract role at some large company, it means they don't think you could get a job as a full-time employee. Hiring managers also know this. If they see you've only ever worked as a contractor, then they will assume you don't have what it takes to get a job as a full-time employee.

(This is not right, and this is not fair.)

<comment><USER40> Can I ask what location this is? It's vastly different to my experience of the contracting environment in the UK.

<comment><USER41> I think this is an U.S thing where this kind of division has sprung up - <USER2> you have contractor ("temp", "paid less") full-time employee consultant ("paid more")

<comment><USER42> There is a pretty important distinction here -- We have seen in the US consulting market (at large corporations) an influx of 90s style contractor arrangements for staff augmentation. This is basically the counter to failed outsourcing efforts. These contractors almost entirely work for large groups like Robert Half, Tata, Infosys, Tek Systems and others.

We also still have a very very strong consultant labor force making 2-3x what W2 full-time employees can pull in. These consultants generally work through smaller consulting firms that take smaller cuts for the placement/handling billing and invoicing.

<comment><USER43> I'd classify it into three groups for the UK...

Perm - Mid level benefits + Pay (maybe options in a startup)

Contractor - Individual with their own Ltd company, pays less tax and much higher take home pay but without any benefits.

Consultant - On-site via a supplier on a framework of some kind, however, often a permanent employee of the supplier with the supplier cashing in the margin.

At least 50% of the tech workforce in companies I work with or where peers are at in London are made up of contractors, especially in Banking.

</comment></comment></comment></comment></comment></comment><comment><USER44> "When I started programming, I heard a lot about how programmers are down to earth, not like those elitist folks who have uniforms involving suits and ties. You can even wear t-shirts to work! But if you think programmers aren't elitist, try wearing a suit and tie to an interview sometime. You'll have to go above and beyond to prove that you're not a bad cultural fit. We like to think that we're different from all those industries that judge people based on appearance, but we do the same thing, only instead of saying that people are a bad fit because they don't wear ties, we say they're a bad fit because they do, and instead of saying people aren't smart enough because they don't have the right pedigree… wait, that's exactly the same." \--- that's his conclusion and that pretty much sums it up for me as a black junior developer from MidWest University who's looking for work now.

<comment><USER45> There are a lot of down to Earth devs, but there's also some... how do I say this delicately? ... Assholes. These people grew up knowing they were smarter than average, but didn't learn to talk to an average. They always have to be the smartest person in the room. This person's sentences start with "Well, technically..." more often than not because you're dumber than they are.

A lot of us go through a period, when we're young, where we start correcting people because, well, we're smart and they're wrong. Most of us get over it and actually learn how to talk to an average (being able to accept when _they_ are right and being able to STFU when they are wrong or explaining it delicately if it's actually something important). Mostly because we learn that an average _hates_ to be corrected all the time. But also because conversations can be _fun_ if you just don't worry about whether what people are saying is "technically" correct or not.

<comment><USER44> I agree that there's definitely a lot of down to Earth Devs and they are probably some of the reasons why I didn't give up on this career(even though I didn't fit in nobody's box and felt alienated from everyone since Freshman year of college), but booooy are there so many holier-than-thou "I went to CalFord or StanTech so I am a god!!" whose last iota of humility was probably when they were in middle school. It almost feels adversarial sometimes when going through tech interviews(as if the process of preparing for them wasn't draining enough). Fortunately, there's a glimmer of hope most smarter-than- average devs are actually good people and are willing and nice enough to help when asked. It just doesn't seem like so when I am doing phone screens or talking to some people at insert-programming-language meetup.

</comment></comment></comment><comment><USER46> Holy cow, was this a refreshing perspective.

I'm one of those underrated engineers who has had trouble getting past nearly every phase of the hiring process at various times. It's frustrating because I'm pretty smart and very passionate about building software, _especially_ tools.

This bias against having the wrong keywords on your resume is incredibly unproductive,I agree, but I would guess it's a result of how little you can actually tell about someone from just a page or two of their work history, which is all most companies have to go on from a resume alone.

I am dying to get some company to take a chance on me, to someday have the benefit of a real mentor, and to be given a real opportunity to feed all this ambition that just won't go away.

I'm pretty sure I'm not alone in that, either. We're here, we're waiting, and we are legion. It's time for a solution to the problem of how to put us in touch with all those hiring managers that complain about how hard it is to find talent.

<comment><USER47> > I'm pretty smart

Is this really a good attitude to have?

<comment><USER48> OK sure, there's the appeal of "Smart? Any human is as a lowly slug to the cosmos!" but in the context of a _job application_ it would be dancing around the common use of the word. If the meaning is "I'm probably in the minority of humans who could solve this problem" then it is definitely a good attitude to have in the context of applying for a job.

Now if you say "I'm hardly ever wrong" that won't go over as well.

</comment></comment></comment><comment><USER49> A lot of businesses which are basically web sites don't need high-powered technical talent. They just need competent people who can make the thing go. This isn't new technology any more. Don't overcomplicate things.

Soylent is looking for a software engineer.[1] Soylent, as someone figured out a few months back, does about two sales transactions a minute. They now have all of two products. They should be using some off the shelf shopping cart program. Yet they're apparently using NoSQL and other fancy technologies.

[1] [https://jobs.lever.co/soylent/e4541619-244c-47ba- bbbf-6f1fee...](https://jobs.lever.co/soylent/e4541619-244c-47ba- bbbf-6f1fee692673)

<comment><USER50> And, of course, said engineer needs to relocate to Los Angeles.

</comment></comment><comment><USER51> Is the anti windows/.NET bias really that common? I have been a .NET dev for 6 years because that was my job. But I don`t believe that makes me useless on any other stack. In fact lately I desire to work on something that feels exciting and fresh again but sometimes I feel like .NET devs are looked down upon and it`s not so easy to land a job or contract outside .Net land.

<comment><USER52> I wouldn't say it's an "Anti .NET" bias, as much as it's an "anti too many years in the same exact thing" bias.

1\. Choose a different language for your next side project. 2\. Step in the door with C#, try to help out on projects or change positions inside the company. 3\. Attend hackathons, contribute to opensource projects.

A good programmer can quickly feel comfortable in any programming language. Recruiters feel more comfortable when you can actually show proof of that.

<comment> UK-AL Changing stack usually involves a decrease in salary.

<comment> UK-AL I would say most companies pay more for specialists, then someone who knows a little bit about everything.

I personally know many languages a little bit, but I find writing my CV to target a specific stack results in a better responsive.

</comment></comment></comment></comment><comment><USER53> Experienced devs are super annoying; telling you it's not a good idea to replace your GUI stack with a browser and whatnot.

<comment><USER54> And they prefer using uncool tools intelligently to solve a complex problem; rather than using the next cool thing dumbly that creates more problems than it solves.

<comment><USER55> Exactly. More than once I've written a small shell script to do things that other people do in multiple KLOC of Go or NodeJS.

<comment><USER56> When I quit my prior job, they started a multi-month project to replace all of my PowerShell with "proper" C#.

Then they decided it was too hard, threw it all away, and just decommissioned parts of the application and run everything else manually.

Working under brilliant minds like that you can see why I quit.

<comment><USER57> Sounds like a bunch of C# devs who didn't know Powershell and couldn't be arsed to learn it. Even though it has similar syntax. To some developers every problem requires the only hammer they have.

Must have been really bad. Why not just hire you on as a consultant?

<comment><USER58> which is sad, because Powershell is great

</comment></comment></comment></comment></comment></comment><comment><USER59> The "Moneyball" quote is by far the most provocative. Never mind hanging around bashing TendyCo or trendy engineers. There is a market for programmers, and like in every market, some are overvalued and some are undervalued.

But unlike stocks, you don't extract value from your programmers by selling them at what the market perceives it will pay. So you aren't hunting for programmers that are valued by the market, you're hunting for programmers that will be productive.

And because it costs you time and money to even talk to programmers, you want the programmers with the highest probability of accepting an offer and being productive. Which means that regardless of your budget productive programmers that are undervalued by the market are the very best ones to interview.

Think about that the next time you see an ad that "encourages women and people of colour to apply." Maybe they're raving SJWs who hate white men. Or maybe they're playing Moneyball. (Where or is `||`, not `^^`, of course.)

<comment><USER60> In my experience, hiring managers, and almost all companies apart from extremely early-stage do-or-die start-ups, simply do not care about productivity. Sure, they'll use productivity as a political excuse to fire you, overlook you, or ding you on a bonus or something. But that's just a way of cover their political games with plausible deniability paperwork. At the end of the day, they don't really care about productivity, and most businesses are not punished by consumers when the business is not productive, beyond a low, low threshold of productivity that non-do-or-die stage businesses can mostly automate and extract from workers who only even need to be semi- conscious to do the work. I've experienced this laissez-faire autopilot attitude first hand, even in a multi-billion dollar asset management company where there was "real money on the line every day" and blah blah blah.

Just look at the office space provided to knowledge workers. Open-plan offices demonstrably destroy productivity. You're literally throwing away something like 10-15% of a worker's productivity (and thus also the corresponding compensation you pay them) just by placing them in a loud, no-privacy open- plan space.

But companies can't get enough open-plan. They want on-site cafes, rock- climbing walls, elaborate decorations, game rooms, liquor-focused cultural activities, etc. etc. all taking place right on top of the space where work is supposed to get done. Can there be more of an unequivocal admission that they don't actually value productivity?

The idea that most businesses have to be really sensitive to bottom-line productivity is a Big Lie. They hire you because they think you'll be a politically ally to their particular internal faction for their pet projects and power struggles. They may need to use your on-paper credentials to win arguments or to "certify" some things, but make no mistake, they absolutely don't care about what you can _do_.

<comment><USER61> I'm a hiring manager at a mature healthcare software company. Productivity is my number one concern. Among regulatory overhead, testing, and legacy compatibility, a developer has to work hard and smart to move the ball forward here. Teams are lean. A single unproductive developer will cause us to miss the scheduled release date of a feature.

<comment><USER60> There are a number of buzzwords in your comment that cause me to doubt its veracity. Without getting into an extended debate about exactly how you detect this productivity in a candidate (something even the best tech firms openly admit is extremely hard to do), the best thing is just to agree to disagree.

<comment><USER61> I didn't say I could detect it in the hiring process -- far from it actually. I just said that I care about productivity, as a counter point to your claim that most companies do not care.

I can't agree to disagree about being called a liar. Can you be more specific about which "buzzwords" cause you to doubt which of my claims?

<comment><USER60> I didn't mean to call you a liar. You might _believe_ you are screening for and prioritizing productivity. I'm saying that I don't believe that's actually what the hiring process you're a part of is screening for, even if the people who comprise that process believe it. Obviously, this is just my prior opinion, a default, since I don't have special evidence.

Regarding your comment, the most major issue is with that term "lean." In many cases, this means some usage of Agile/Scrum nonsense, which if true completely throws out any credibility that the position is focused on productivity in the least bit. Sometimes instead of Agile, "lean" is used for six-sigma like micromanagerial process, which suffer all the same criticisms as Agile.

Even in the best case, a team that self-identifies as "lean" is failing to make use of specialization of labor. Many of these teams hire people into roles titled "full-stack" or "generalist" and they say stupid shit like, "because our team is lean, you will have to wear many hats." (I am actually so sick of hearing the phrase "wear many hats" that it causes me to instantly reject a job out of hand at this point).

"Full stack" is arguably the single worst trend in all of software. It goes completely against the major benefits of software development: specialization and separation of concerns. Many organizations that use full-stack practices also believe that they don't need to provide meaningful job descriptions. They want to leave job descriptions vague ("many hats!!") and argue that candidates have to be adaptable if they want to cut it in this crazy dynamic world of ours.

This is all total bullshit. There might be a small period of time in a start- up life cycle when it pays to have many generalists and leave everyone's work assignments vague. But most start-ups, and certainly most established companies, have no business operating in "lean" mode. You need to empower employees to know the limits of their job descriptions, so that they won't be treated as catch-all, pan-everything work receptables who are capped solely by the literal limits of their physical exhaustion (at which point you whip together another pan-everything job ad to hire yet another generalist to handle the undifferentiated work overflow).

This fails to respect the worker's speciality (which is something the worker absolutely had to protect to advance in their career). It also means the company is not extracting the full value from the worker that they could by doing the challenging job of _actually managing them_ and setting up the workflows so that work requiring that specialist skill is routed to the right worker. If the company embraces a "full-stack" "we're lean so everyone wears many hats" attitude, it's an overt admission that the company couldn't give two shits about what you're actually capable of doing for them, and instead only cares that you do what they happen to tell you to do right now, even if it's hilariously underutilizing you or is hilariously inappropriate for someone with your particular skills, or is using in a way that fails to address critical business needs you've identified.

Basically, I see "lean" and I immediately think, "managers believe they can throw a bunch of so-called full-stack developers on a Scrum team and then flip on autopilot." The managers are going to get mad if that machine learning expert they assigned to clean up the legacy Rails codebase ever breathes a word of dissatisfaction over not being fully utilized or utilized in their speciality.

"lean" is by far the buzzword that is most negative from your comment, but I also see the phrase "move the ball forward" and I immediately picture those trite motivational posters with eagles and someone passing a baton in a relay race and I just roll my eyes. We're not in middle school. We go to work to do work. We can speak about the work we do in grown up terms. Not "moving the ball forward." To me, this communicates a very top-down attitude about what progress means. There are some high-level, likely paternalistic or even misogynistic, ideals about company progress and what a good little worker must do to be productive. No thank you! Even if this language is not indicative of the worst kinds of problems, it still is extremely infantilizing.

"A single unproductive developer ..." oh boy, don't even get me started. Right away this sounds like someone with a way over-inflated opinion of the work their team does. "Our work is so very important that we can't abide even a single person who isn't amazingly productive." Yeah, OK. For one, you just said your team is lean, so whose fault is it that you don't have adequate redundancy built into your technical resources (your tech staff). If someone said their distributed database "couldn't tolerate even a single node failure" you'd ask them why they don't create more nodes and add redundancy to have a safety factor.

Why would a team agree to be lean if they are also worried that a single bad link in the chain will cause a problem. Either there's some kind of extreme budget constraint, or else this is someone who just read a Malcolm Gladwell- like pop book about "lean" and "Agile" and decided that's the shiny new management thing they just had to have.

Lastly, I'm not sure why "release date of a feature" was the example you chose to go with. This could be innocuous, but more often than not when I see people who think in terms of release dates and features, it's a huge red flag. Most teams need to actively constrain the set of features they agree to support, tell customers and internal business stakeholders "no" way, way more often, and address overall technical debt and architectural quality concerns far more than shipping features. If I was in an early interview stage and someone is already asking me how I make sure I always cram out all the features on time, that's a huge red flag of a dysfunctional process driven more by short-term business managers seeking bonuses that are tied to on-paper accomplishments (e.g. we shipped X,Y and Z) than the engineering reality (X, Y, and Z were technically delivered 'on time' but they suck and now everyone's asking for W which we can't even do because of how fragile the implementation of X, Y, and Z was to get it out the door on time").

Let me qualify all of this by saying that yes, absolutely, 100% this sort of detailed dysfunction can be inferred from very small amounts of buzzwordy HR text and job ads. I've seen it time and time again, and even been part of the teams responsible for drafting job ads and seeing first hand the thinking processes of HR as they inject all of this awful stuff into it.

There is even a major qualitative social science study about exactly how this kind of vague, symbolic HR-approved linguistic atmosphere is heavily, heavily related to the skewed ethical views held by executives and managers. I strongly urge you to read it if you have not already:

< [http://www.amazon.com/Moral-Mazes-World-Corporate- Managers/d...](http://www.amazon.com/Moral-Mazes-World-Corporate- Managers/dp/0199729883) >

I'm _not_ saying that this definitely applies to you (I don't know you). I'm saying that my experiences tells me that the odds are that the team you are representing to "move the ball forward" with a "lean" team that cannot bear "a single unproductive developer" is a very dysfunctional one, and that many of these buzzwords actually imply the opposite of the image they are invoked to create.

<comment><USER62> > _If the company embraces a "full-stack" "we're lean so everyone wears many > hats" attitude, it's an overt admission that the company couldn't give two > shits about what you're actually capable of doing for them, and instead only > cares that you do what they happen to tell you to do right now, even if it's > hilariously underutilizing you or is hilariously inappropriate for someone > with your particular skills, or is using in a way that fails to address > critical business needs you've identified._

Another possibility is that the value of shared context and mutual learning is seen as desirable outcomes, on par with production outcomes.

I'm not saying specialisation is unnecessary. But it comes with costs of its own, so some overhead from wasting the specialist's time is worth it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER63> "There were even a couple of cases where I had really strong internal referrals and the recruiters still didn't want to talk to me, which I found funny and my friends found frustrating."

This has to be a firing offense.

A recruiter's job is to find people the engineers want to work with and who the engineers believe could be a strong contributor. If the engineers have already found someone they want to interview, and the recruiters are saying no, the recruiters are just blocking the very process they were hired to facilitate.

</comment><comment><USER64> In interviews I actively try to down play the companies I've worked for and the things I've done with them. The reason I do this is that I don't want people to come in with unrealistic expectations and expect me to live up to them. I also don't believe in preparing for interviews. I'm ok with the rough edges I have. I want my imperfections to come through on some level. Yes I have a preference for certain technologies. I love what I do. They should be more concerned if I didn't have an opinion. It doesn't always work out in my favor. _shrugs_ Rarely, do I serve up great interviews back to back on different days. I'm an front-end guy because I love building them. That's all.

<comment><USER65> If you don't prep for interviews then how do you handle all of the arcane theory heavy questions that a company like Google or Facebook will ask?

<comment><USER47> Maybe you want to self-select out of companies who have questions like that.

</comment></comment></comment><comment><USER66> "Experience is too random, with payments, mobile, data analytics, and UX."

This one made me chuckle.

Same thing usually happens with my résumé: either one discards completely the part where I cite strong OCaml knowledge plus functional/logic programming interest and/or they discard completely the part where I mention experience with ARM PRU assembly and the fact that I ported an educational OS to MIPS during graduation.

It usually comes down to:

\- "So you are a C++ programmer?"

\- "Yes, I have a good experience with C++."

\- "Good, we'll like to hire someone with your knowledge, we have PHP and Perl codebases to maintain and your profile seems a good fit."

\- "...."

<comment><USER67> Sounds like you need to tailor your resume for each role.

</comment></comment><comment><USER68> I'm currently in the process of applying at Facebook (which I guess qualifies as a TrendCo that recently transitioned to BigCo). I haven't even got to the technical phone screen yet, but the recruiter tried to get me to attend an "interview prep session" and then sent me a pair of videos from it totalling 2.5 hours when I couldn't, which of course I felt obligated to watch on the assumption that all the other candidates will have.

Ridiculous enough. Then there's the content. The videos are a presentation by Gayle McDowell, the author of Cracking the Coding Interview. Lots of tips about interviewing, 95% of which were pretty obvious but most of which seemed useful enough, on the assumption that the process is a given. But McDowell would repeatedly say things like "most interviewers won't expect you to write perfect syntax on a whiteboard, but some will" as if this was perfectly reasonable. And she gave "if you're writing in Python, it's a red flag if you use ++ (instead of += 1)" as an example of something she cares about herself! So both the recruiter and McDowell recommended doing a number of pen-and-paper practice coding problems before your interview, specifically _on the basis_ that this is something you never do in your day job.

If I want to be charitable, this is Facebook trying to even out some of the biases introduced by their (apparently unchangeable) whiteboard algo puzzle interview questions, by ensuring everyone is prepared.

If I want to be less charitable, the demand for hours and hours of preparation is just (further) hazing to prove dedication.

In either case, I think this evidence that BigCos are not necessarily any more rational about hiring.

<comment><USER69> > If I want to be less charitable, the demand for hours and hours of > preparation is just (further) hazing to prove dedication.

Come to reddit's /r/cscareerquestions one day. Tons of stressed out 18-22 year olds practicing CTCI and LeetCode for hours just for a chance at passing the Facebook/Google hazing. Because these people are usually "high achievers" who spent hours in high school at SAT preps, this feels natural to them, which is why they'll give questions like this when they hire in the future.

<comment><USER70> I don't really see the issue with that. The benefits ($45-$51/hr internship salary or $110K+ starting) *outweigh the cost of preparation.

<comment><USER69> I don't see a problem with it for those kind of companies either. I'm just saying where the attitude comes from.

I do have a problem with it when it's for smaller companies that get 0.05% the number of applicants though!

</comment></comment></comment></comment><comment><USER71> Being in the IT job market off and on for the last 18 months and being interviewed at about 40 companies in one of the major tech hubs in the USA, gave me a similar experience as the OP. I came to several conclusions:

1) In my case trendiness is more valuable than the school you've graduated from (graduated from a school overseas that nobody in the USA heard of). I worked for one of the companies in the area, notorious for its difficult tech interviews and I got a bunch of calls from recruiters (including from Google) during my tenure there and immediately after I left. Two years and few short gigs at not-that-cool-companies later, I don't get that amount of calls.

2) Most of the "technical" recruiters have no clue how to evaluate technical candidates. For many of them the main (for some the only) way to judge about your skills is how much money you make/how much money you want. I'm talking about deep understanding what engineer do, I'm talking about basic stuff.

3) If you have 1-2 short gigs for the last couple of years you are under the suspicion that you can not be trusted enough to be hired as a FTE.

4) If you are unemployed at the moment of the interview - look 3) I believe now that hiring in the IT industry is somehow a stochastic process. I was hired and got offers from reputable companies and organizations and rejected even at the first round of interviews by no-name/less-than-mediocre-companies. Go figure.

</comment><comment><USER72> I completely agree with the article. I worked for EC2 for >3 years and consistently exceeded team expectations. I'd get pinged by recruiters all the time while at Amazon. Now that I work for smallish not-for-profit, no recruiter seems to be interested any more. What's interesting is that I'm more active in OSS projects, have far more experience than I had when I left Amazon. Totally weird!

<comment><USER73> consider adjusting your resume. could just be presentation. :)

Specifically, if it doesn't say AWS in the first sentence, you're doing it wrong.

</comment></comment><comment><USER74> Recognizing these difficulties and biases, and watching the swaggering, overconfident, surface-level way coworkers around me talk about their interview candidates as if they had awesome powers of judgement, my approach has evolved into:

Pick an LSAT-style logic problem. First just give the candidate the problem, and see if they can work it out. No programming, just simple logical thinking skills. Then get into writing some code (or even pseudocode) that can solve some version of this problem.

There will be some conversation after that, maybe about how you'd scale the code, and then branching off into other things. But mainly I just see if a) they could solve the logic problem and b) they could translate that solution into some reasonable code. I try to apply this consistently across candidates.

I was unemployed once, and I _knew_ that I know how to do this stuff. It was incredibly frustrating to me that the people interviewing me were holding me up to unreasonable and irrelevant standards. I keep that in mind and try to give people the benefit of the doubt.

<comment><USER75> Back when the web was still young and I had less than 1 year experience, I interviewed at IBM for a web developer position. They gave me an aptitude test, which they said I scored amongst the highest they had ever seen. This got me through several rounds of interviews but at the very end, I was rejected. When I asked for feedback, the hiring manager said that I didn't have enough experience. It felt like a complete waste of time, because they KNEW I didn't have enough experience from the beginning, so the entire process was really offputting.

<comment><USER76> I'm not one to believe the official explanations given. It is too easy to lie than to give the truth, even when that truth isn't bad. So I wouldn't put too much work into you being inexperienced. Instead, I would say that they had a different reason for not choosing you but that was the simplest lie they could come up with on the spot by looking over your resume.

</comment></comment></comment><comment><USER77> As I get older (I am currently thirty), this is something that terrifies me, mainly because it is something that I have experienced from both sides. I got a B.S. from a major CS university, then started on a Ph.D. in Astronomy. Due to my dissatisfaction with that program, the fact that programming is my passion, and various life events, I decided to leave after obtaining a M.S. and began to look for work.

I attended my university's CS job fair, only to find that I had become almost completely unemployable to tech companies (granted, I only had a 3.3 GPA in CS; damn you, WoW!). I ended up taking a tech support job with a scientific computing software company after I was promised a quick transition into development. However, that too evaporated, ironically due to the stigma of working in tech support.

After about 8 months, I interviewed for a developer position at a Midwest branch of a major tech company, but was again turned down. Luckily, I was instead hired to be a QA contractor on a different team, whereupon I quickly transitioned into a non-contracted developer on the original team that didn't hire me about a month before the company's new CEO announced that we would not take anyone with lower than a 3.5 GPA. I took the opportunity to mention this fact at every opportunity to one of my co-workers who had originally voted not to hire me.

After about a year, I started interviewing new candidates at this company. You would think that, given my prior experiences, I would be more forgiving than my peers in looking at past experience. While I didn't make any judgments based on school or GPA (in fact, those were filtered out before the resumes ever made it into my hands), I did turn down several candidates who were "too enterprisey", i.e. did not have experience or interest in whatever tech was trendy at the time. Granted, these candidates also had trouble understanding and debugging simple perl scripts I showed them, so I was already not on board, but when those candidates were borderline hires/no-hires, that was something that swayed me in the "no-hire" direction.

Now, as a married thirty-year-old with two kids and several non-coding hobbies, I have neither the time nor inclination to use my free time to learn today's trendy languages and frameworks. My work keeps me relevant for now, but if that ever changes and I need to look for work, I'm terrified that my experience and ability to learn quickly will be irrelevant to prospective employers, who will just want to see the right technologies appear on my resume.

<comment><USER78> Hello, just want to chime in and say that you shouldn't have to feel anxious about falling behind potentially if something new comes along.

Life is too short to worry about things that can't ultimately care about you (weird thing to say I know, but the interests that you care about, even if they are non-human, you fall in love with because they give you something back; and excluding the emotions of: the fear of missing out, the pressure to fit in, or the greed to get ahead).

I'll go out on a limb and say that most of the new Javascript web development frameworks are created by really zealous young people fresh out of school, eager to explore the brave new world of open-source and using Github as a medium to mark their mark (hence the reason for why there are so many new solo frameworks or fork, not enough collaboration); or by old-timers in that community who for whatever personal reasons really enjoy doing it and been doing it. Go to your local open-mic for poetry or music jam for a "In Real Life" representation of this phenomenon.

Speaking for myself, I am just not interested in learning arbitrary new frameworks that isn't intellectually interesting, that is simple syntactical sugar (remapping the textual receipe of rendering of a button from desktop development, to Web 1.0 to Web 2.0 to React.js) or doesn't open up a new outlet to other subjects that I want to learn about (e.g., machine learning, Bioinformatics).

Practically speaking, if it turns out in 5 years, all software companies mandates the banning of lamer frameworks such as PHP or .net and only Node.js/React.js/Flux allowed. I'll wait for the idiot crash guide for these frameworks and these frameworks to be watered for "plebes" like the rest of us and try to learn the keyboard remapping in a couple of weeks; I'll let the hipster kids on Github who "did it first" take the street cred; and hopefully then, I can still manage.

</comment></comment><comment><USER79> Grammatical and logical issues aside with, "we only hire the best," once you make it into TrendyCo or BigCo you're faced with the dilemma of Plato's cave. Here is a code base written by a group of average people with big egos whose reality is limited. Your perspective as an outsider to the cave are not going to be valued. Even in very open-minded teams I've found that once _the way_ is established people will struggle to keep it that way forever.

As a developer, trendy or otherwise, you take a big risk sitting down at the back of that cave and joining in the group.

<comment><USER80> There really isn't a way to avoid this other than only working in places were you already agree _100%_ with the way they do things. If you build your own company you will also have _your_ way of doing things that you will impose on everyone working for you and you will not change it because of some new guy. Not significantly, anyways.

<comment><USER79> There is a way to avoid it but I think software development is unique in that we haven't been able, so far, to establish what the _state of the art_ is. And so it seems like, as you say, every company is in its own cave and the only way to have the freedom to have your own ideas is to start your own cave.

It's a little bit backwards in my opinion. Instead of it being commonly accepted that we should be checking mathematical models of our systems we have "senior engineers," debating whether unit tests are a waste of time. We have developers either being trendy or forcing others to pretend they are. And trendy changes in each ecosystem (BigCo vs TrendyCo).

Companies can, and should, change. The AWS teams managed to see the formal specifications are a good idea and have been better for it since. You can be sure there were highly experienced senior developers who resisted their introduction with the best arguments they could muster. Even very smart people want to stay in the cave and watch the shadows.

<comment><USER80> > The AWS teams managed to see the formal specifications are a good idea and > have been better for it since.

Can you elaborate on that?

<comment><USER79> If you can spare an hour, I recommend Leslie Lamport's talk at React San Fran 2014:

[https://www.youtube.com/watch?v=iCRqE59VXT0](https://www.youtube.com/watch?v=iCRqE59VXT0)

Where he shares some anecdotes from Chris Newcombe about Amazon's adoption of TLA+.

<comment><USER80> I can't now but eventually. Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER52> I find that "how can he improve?" is probably a much better question than "Why don't you want him"? Ask the first - and you'll get real actionable items to improve on. Ask the second - and you'll get the recruiters equivalent of "you're cute, but I already have an imaginary boyfriend".

While a company might pride itself in hiring generalists and "we do a bit of everything", very often they're just looking for someone to fill a specific position for a very specific need. Those needs might change in 3 months, (and then they'll be glad you're a generalist), but they're hiring someone to fill the gap NOW. This is especially true for startups, who have limited funding, believe in "move fast" mantras, are afraid of hiring someone that might need to be fired, and are afraid to take time for ramp up.

<comment><USER81> > While a company might pride itself in hiring generalists and "we do a bit of > everything", very often they're just looking for someone to fill a specific > position for a very specific need. Those needs might change in 3 months, > (and then they'll be glad you're a generalist), but they're hiring someone > to fill the gap NOW.

So in other words: The startups present plain lies in their job requirements and complain that the people that submit an application don't fit what they really want.

IMHO the easiest solution would simply to be honest...

<comment><USER52> As far as they're concerned, these aren't lies. They just have a lot of different requirements, often conflicting

</comment></comment></comment><comment><USER82> AKA 'pedigree hiring'.

S/he must be good because s/he worked for X known company.

It's a pervasive bias, especially in tech where certain brands are lionised to the point of nearly becoming sacred. Brand association alone will get many a person through an assessment process with sometimes with the complete abandonment of any semblance of due diligence.

Remember the Scott Thompson scandal? Basic stuff like lying on your resume did not stop Yahoo! from making a pedigree hire. Must be good because PayPal.

We have to all work very hard to educate ourselves that we are all inherently susceptible to this bias.

</comment><comment><USER83> My favorite question from bosses is, "So, Napper, what kind of developer are you?". This is about the time I start listing all of my experience and they're just like...I don't know what to do with that. - I can do anything, just give me a check and I'll make you profits like a good ferengi.

</comment><comment><USER84> This practice of hiring for tech glamour is bubble behavior. I'm an old guy, so I remember back in 1999 some nitwit hiring companies were demanding five years of J2EE experience.

Don't worry; if the overfinancing bubble bursts, or even deflates gently, people with salaries and get-it-done tech experience from outside the Silicon Valley reality distortion field will once again have an unfair advantage.

</comment><comment><USER85> I think we're starting to see the need for 'laborer' programmers. There's a lot of relatively unskilled glue/laborious coding that needs to be done. When you need someone to hammer a bunch of code out for you, you don't need an experienced and flexible software engineer as much as you need a kid with a well-trodden neural pathway that lights up when they write code in your tech stack.

I think code schools are effectively training programs for this kind of work at the companies that use them as hiring pools. I would be surprised if these companies didn't influence the schools' curricula in some way. If they aren't doing this explicitly, they should, and they should absorb some of the cost that is currently being levied against the students. Right now, we're at this weird point where students are paying for their own training at these 3rd party facilities that more or less kind of guarantee them maybe a job at this list of very specific companies but no guarantee... Something feels a bit sleazy about it. I don't know how transferrable the education you received at a code school will be once you leave the company that hired you from it.

I think the field of software engineering/programming/whatever has broadened so much that you have to have some distinguishing, domain-specific feature to get a job somewhere--the distinguishing feature of the 'trendy' programmers is usually the tech stack alignment. Maybe general knowledge of writing good, maintainable software is moot in the face of an efficiently trainable workforce, short-lived code, and a diaspora of tech stacks.

<comment><USER86> > I think we're starting to see the need for 'laborer' programmers. There's a > lot of relatively unskilled glue/laborious coding that needs to be done.

I have a computer for that! Seriously, that's one of the things a computer excels at. This is what is so nice about a language with strong dynamic typing: it makes writing the sort of code which writes glue code reasonably easy.

<comment><USER87> How do you get your computer to solve the problem of "this text needs to be 2 points larger, a darker shade of red and 5 pixels to the right" without involving a programmer?

I've worked on the Avon AU website and we had a few hundred tasks like that. It's why (to link back to my current pet peeve) I'm upset that my relatives are unwilling to learn a tiny bit of web design because "it's too hard". There is a market for people who ONLY know how to do this. (There were two people in the company I was working for and my team only got access to them one hour every week - they were that busy.)

<comment><USER88> If this is true there's a serious mismatch somewhere.

There a lot of people who can do this work in the UK. Mostly they don't get paid very much at all.

</comment></comment></comment></comment><comment><USER89> I'm living this right now. I'm unhirable right now due to my salary requirements (having 13 years of practical experience means that I won't take a job for $60k), and I was turned down for an internal transfer because "you have the skills and experience, but your answer to the interview question was too inefficient."

That will teach me to not memorize algorithms I haven't used since college.

<comment><USER90> > having 13 years of practical experience means that I won't take a job for > $60k

Where are you based? If you're in the US and you have as much experience as you say you do, even if you're in places that aren't major tech hubs, you should be able to find remote work that pays more than $60k/year.

> That will teach me to not memorize algorithms I haven't used since college.

The debate about the merits of algorithm-driven interviews aside, the fact is that most companies still do this for their interviews. This is starting to change, but slowly. When I was last looking for a job, every company but one[0] asked questions about complexity classes at some point during the interview stage. Unlike the last time I was on the interview circuit, though, more than half had at least one question that was explicitly focused on something else - so it's changing, but still slowly.

So, while it may be information you never access again while on the job, if it's the knowledge that will secure you that well-paying job in the first place, consider it a worthy ROI.

[0] incidentally, the one I ended up working for

<comment><USER89> > should be able to find remote work that pays more than $60k/year.

Key word being "should". The "companies willing to take risks" from the OP don't accept remote people most of the time, and those who do allow remote frequently don't believe that people outside of SV are worthy of the payscales you see in SV (even after adjusting for the cost of living).

> asked questions about complexity classes at some point during the interview > stage

Yeah, and I am reasonably certain that I passed 3 of the 4 for that class of question, but I had forgotten the minutiae of Dijkstra pathfinding algorithm. As a result, my response for the 4th was O(n^3), but it should have been O(n^2). At least I won't forget that one again.

It was pretty funny in one of the interviews, where we spent 50 minutes going over a logic puzzle (the kind where if you don't know the answer, it's unlikely you'll figure it out in an hour), they then went on to say how the job was about creating an interface between a DB and RabbitMQ, and creating a common application framework for the rest of the company. We ended up having a good (but short) conversation about how to do exactly that, and those 10 minutes seemed much more valuable than the time spent on a logic puzzle.

I think that's the big thing: the existing employees who are drafted to do candidate interviews were themselves interviewed with this style, so it's how they go about it. They simply haven't stopped to think about what biases these interviews introduce, or think those biases are a good thing.

</comment></comment></comment><comment><USER91> Minor nitpick: how difficult is it to slap a date somewhere? Especially with this design it is impossible to tell when in the last 30 years this post was written (for the curious, it looks like it was posted today).

<comment><USER50> It may be published that way intentionally. Some people don't want their content judged by the publishing date.

</comment></comment><comment><USER92> "Contractors are generally not the strongest technically"

Nonesense. Contractors are actually much stronger technically because they usually come in to complete a specific task and are not usually trained by the company.

At least that is my experience here on the east coast.

<comment><USER93> At least at Google, it was almost impossible to hire an engineer with domain specific knowledge. Nearly everybody we tried to hire who had the domain specific experience our team needed didn't make it past HC due to some BS gotcha question in the interview. On the other hand, contractors were trivial to hire.

So in a sense, the contractors were not "as strong", since they didn't have make it through the absurd Google hiring process. As such, they were generally treated as second class citizens.

</comment></comment><comment><USER64> Success or failure of an employee is based on what the company does with them after they are hired. It doesn't matter how "great" an employee is when they come in. I've seen people come in as senior devs but you'd never know it. I've seen some employees hired and ran off when they couldn't clean up a hot load in record time.

</comment><comment><USER94> Then don't work at those companies. It seems there's always .NET jobs - I get recruiters all the time bugging me about those gigs, but I get nothing on any of the other languages I've worked with (and the .NET work I've done is a very small % of my career). Perhaps it's a location thing - Houston is definitely a .NET town.

<comment><USER95> Some areas are location specific. Richmond VA seems to be a .NET and Java town mostly. My team's stack is Apache httpd PHP and Java mostly on Linux. A little scripting in Python and bash.

<comment><USER96> It would be cool to have a map showing what stack/language is most marketable in what area, so that one can adjust time spent on learning new tools depending on where they want to go. But maybe these things evolve faster than the time scale involved in getting enough experience to be attractive for employers.

</comment></comment></comment><comment><USER97> I have been in a similar frustrating position. I have a degree in marketing. I taught myself to code and spent five years building a huge variety of native and hybrid Android and iOS applications. At one point I eould have rated myself as a 9/10 at iOS and Objective-C at a time when these skills were in severe demand. Unfortunately all recruiters saw is my marketing degree.

Part of me, a large part, wanted to simply tweak my profile to say "computer science." If I had done that I am certain I would have been making $150k years before I finally got there. No one would have known or bothered checking. I was able to blow through fairly technical interviews at smaller companies who weren't as picky including answering all manner of algorithms, data structures and sorting questions on the whiteboard. I actually bothered to back fill on all the knowledge I had missed by reading college text books in my own time. Yet...marketing degree. I was even told that I wasn't technical enough after absolutely acing a particular interview which blew me away.

The filtering system is corrupt and broken, if they are going to discriminate against me based on wrong indicators, why should I have to play their game? Unfortunately my feelings of ethics prevented me from doing what seemed logical. I made it on my own time the hard, boring way. Maybe I am the dumb one for not cheating.

<comment><USER29> Just remove your education from your resume. I'm only a high school grad so Im kind of in the same position. The moment I started leaving my education off my resume, no one ever asked about it again.

<comment><USER98> Bingo.

I did the "some college" thing - so no one asks.

</comment></comment></comment><comment><USER99> Overall, I get the gist of the article, and it makes sense. Some counter- points:

> Mike has worked on systems that can handle multiple orders of magnitude more > load, but his experience is, apparently, irrelevant.

Did Mike build/architect said system, or was instrumental in said system reaching massive performance? As an MSFT contractor, it seems doubtful. Our team had a "Principal Architect" that did that sort of heavy lifting.

> (3), combined with (1), gets at what TrendCo's real complaint with Mike is. > He's not their type.

Generalizing isn't good, but in my experience as a former MSFT contractor, there is a lot of stigma on A- employees, deserved or otherwise. Part of it happens because FTE's that are let go for performance reasons, end up rehired as contractors by shops like VOLT. These folks know the ins-and-outs of MSFT, and the bar for hiring contractors _is_ much lower.

It's super easy to apply for jobs--just click a button, and you're applied. My last open rec receieved over 100 submissions in less than a week. As a hiring manager, I need to quickly go through those submissions and get back to the candidates I want to speak with. For better or worse, I've come up with filters that I use to quickly sort candidates into reject or contact bucket.

I'll definitely contact non-ideal candidates, but your resume should give me an indication that you're worth considering if you don't fit the standard mold of:

"Worked for a solid tech company, familiar with recent tech stacks, has some sort of successful side project, has a 4-year CS degree."

If you don't fit that mold, but are awesome. Great. Prove it (on your resume plz).

<comment><USER100> > there is a lot of stigma on A- employees,

FYI, contractors are v-.

<comment><USER99> They're both.

a- for agency employees (working for companies like Volt). These are contingent staff (CSG), usually hired to augment teams of FTE.

v- for vendor employees (like nvidia). These are typically are partners working along side MSFT to accomplish a shared goal.

From my myopic viewpoint vendor employees seemed to get more respect than agency employees.

Regardless, I did think it was generous of MSFT to allow contractors to partake in the free soda system.

<comment><USER100> I have not seen a single a- but I have seen plenty of v- from agencies. You may have outdated information.

Edit: And I'd think that partners from other companies would be given b-es, which is for "business guests".

<comment><USER99> Fair-enough. This was back in 2011, so things certainly could have changed.

Blue Badges were FTE Orange Badges were A- Yellow Badges were V-

</comment></comment></comment></comment></comment><comment><USER73> A lot of companies founded by young people, hire other young people and believe the best tech is what they learned in college: Command-line python, javascript. They don't realize that teachers teach python because it's easy to teach, rather than because it's the best language for the real world, or that tools make people more productive in the real world (where they can be afforded).

<comment><USER101> Hell, at this point I'd be happy with "command-line python". I've seen a few- too-many "Rails, but only in RubyMine" devs.

</comment></comment><comment><USER102> Being a self taught programmer with no formal education (but ~20 years of relevant experience by now) I can relate to this. It can be hard to get hired since companies may have crazy requirements. But on the other hand, you don't really want to get hired by those companies anyway. My experience is that great companies recognize great people regardless of background.

</comment><comment><USER103> It's not about trendiness. It's about valuing experience with a specific stack out of all proportion to what that's worth - perhaps because it's one of the few things that's easy to measure.

I've looked at going in the other direction - onto .NET. There's a lot to like about the framework. But I can take a job on the JVM and be paid like the dev with 7 years' experience that I am, or I can take a job doing .NET and get paid like a fresh grad, despite the two systems being about as similar as it gets.

And I've watched plenty of people in suits be hired at trendy startups. Maybe the bar will be a little hire, but it's not an instant firing the way wearing a t-shirt to many companies would be. A lot of tech companies really are better at this kind of thing than other companies; there is always room for improvement but there's also room to celebrate the things we do get right. Stop listening to DHH.

<comment><USER104> I interviewed at Loopt (sama's YC company) 4½ years ago. When I went out to lunch with their tech guys, they joked about a guy who had come in before me in a suit, and how that really hurt his chances to get the job. Though I knew enough to dress casually, I was coming from a company in the midwest where I had to wear a suit every day. Both extremes seemed absurd to me.

I eventually turned them down in favour of another offer.

</comment></comment><comment><USER105> I interviewed at Pivotal labs and I'm pretty sure they rejected me because I use the Colemak keyboard layout and because I wasn't that great at foosball.

<comment><USER62> Studies show that Colemak reduces foosball efficiency.

</comment></comment><comment><USER106> > Anyway, (1) is code for "Mike's a .NET dev, and we don't like people with > Windows experience".

To be fair, this is legitimate although poorly phrased. A more correct version might read: "We're interested in folks who have more experience with GNU/Linux and open technologies."

</comment><comment><USER107> If you're a startup, and you (the founders) have any sense at all, you will _screen out_ candidates from "top 10" schools. As a startup, you have absolutely no business competing with Google / Facebook / et al engineering talent. This isn't even approaching anything like moneyball, it's just common sense. The idea that where someone went to _school_ makes two shits of a difference in job performance is ridiculous. Job performance in technology is mostly about a collection of other soft skills in addition to grades and technical ability (communication, willingness / ability to learn new technologies, ability to work in quickly adapting work environments, etc).

</comment><comment> arunk-s _A lot of people treat employment status and credentials as measures of the inherent worth of individuals. But a large component of these markers of success, not to mention success itself, is luck._

This is one of the most accurate lines I've seen on a technical blog.

</comment><comment><USER108> Related anecdote: a good friend of mine works at FB, and pushed and pushed and pushed for me to be okay with him passing off to a recruiter. Finally I said yes, and after much ball dropping, they rejected me without even a phone screen. I don't mind, but related to this - my background is odd, yet pretty strong: YC co-founder (Corp acquired by Google), top 5 in country PhD, bootstrapped several businesses, lead several concurrent teams of developers, strong ability to ship, among the top iOS BTLE developers in the world, etc. I just don't think I fit their mold, and told my friend so before he even tried. Guess I was right.

</comment><comment><USER109> This is the problem with overfunded startups.

You have engineering managers in charge who are too inexperienced to really have a good instinct for talent. So they just throw all of their investor's capital at a very narrow range of candidates - basically people who remind them of themselves.

This will sort itself out. Companies like Google and Facebook will continue to bloat themselves up, just like almost every single conglomerate in the history of business. Their products quality will start to deteriorate because their cultures are more interested in status signifiers than they are in great work.

</comment><comment><USER110> One of the best threads I've read here in recent times. Wish all developers, managers, and HR folk would read it. Can't say that I read it word-by-word so apologies if I missed, but are there any tech startups that provide tools and resources for pursuing such "open book" coding interviews? Or is there a business model here - think "reCAPTCHA for hiring". Solve stackoverflow bounties. Fix bugs in OSS projects. Everybody wins. Questions get answered. Bugs get fixed. Programmer candidates prove their mettle. Good candidates are identified.

</comment><comment><USER111> As a candidate I'm looking for an employer that wants me (or that has a real urgent need or want for a good candidate). This is usually evident at interview or before. You can tell they really need someone, rather than having to grow for the sake of spending their VC money.

As an interviewer what I'm looking for in a candidate is someone who really has enthusiasm and passion and wants to work for me. It's less important how they look on paper, I want to know how much they want to work with us.

<comment> FLUX-YOU >rather than having to grow for the sake of spending their VC money.

Please forward all jobs to me, as I am happy to take their money.

</comment></comment><comment><USER112> My team and I at Workshape.io are working hard to build a hiring platform for software engineers that addresses some of the various shortcomings in this space.

We have noticed over the past few weeks that interviewing techniques and hiring standards have been a hot topic on HN. We are interested in finding out from the community what your limits are when it comes to interviewing as we feel there is little understanding of this - We all have our opinions on what is effective but it would be incredibly useful to identify trends across different demographics in our industry.

We have created a quick survey [1] (that is anonymous) to help us gather information so that we can produce a report for the benefit everyone. It shouldn't take much longer than 10 minutes to create. We'd be incredibly grateful for any contributions. (The survey has been designed with attention paid to a survey designing guide from Harvard [2])

[1]: [https://workshape.typeform.com/to/SGxTdw](https://workshape.typeform.com/to/SGxTdw)

[2] : [http://psr.iq.harvard.edu/files/psr/files/PSRQuestionnaireTi...](http://psr.iq.harvard.edu/files/psr/files/PSRQuestionnaireTipSheet_0.pdf?m=1357530492)

</comment><comment><USER113> "When I started programming, I heard a lot about how programmers are down to earth, not like those elitist folks who have uniforms involving suits and ties. You can even wear t-shirts to work!"

This alone dates the author to beginning in the eighties :D

Today, you basically must sport the "lumberjack" look to be cool :D :D :D

But seriously, yes, now as the industry matured, there is a dress code. It might vary from area to area, but it's there.

</comment><comment><USER114> A friend of mine experienced something similar to this. She was advised to find a small upcoming startup and join them. "You need a win," was how one of her mentors phrased it. This did not necessarily mean a win for the company as much as it did mean a win for her and her career. I would strongly advise a similar approach to getting your leg in the door at TrendCo.

</comment><comment><USER115> The abundance and heterogeneity of various technology stacks, frameworks, methodologies and whatnot fuels this hiring mess. Twenty-five years ago, nearly everyone who called himself a programmer knew C and an interviewer could judge the relative strength of two candidates by really examining their programming skills and not some trendy keywords.

<comment><USER116> This sounds like a falsehood, brought about by the belief that the past was somehow simpler, because the relics from the past that survive into the modern day are few in number.

I doubt that everyone knew C. Lots of big firms extensively used COBOL. Fortran was important in science/numerical computing. Pascal was popular. The list goes on.

Need I mention that for decades, there were lots of competing assembly languages, and that only in recent years we've converged on three? That Harvard Architecture and Von Neumann Architecture competed into the late 70s? That compiling a program on a machine with particular hardware could be seriously difficult? The conflict between big-endian and little-endian systems? Computing has always been full of heterogenous, competing technology stacks, frameworks, methodologies, etc. Why? [https://xkcd.com/927/](https://xkcd.com/927/)

And in the 90s in particular: do you really think that designing software for this so-called "internet" and newfangled HTML and JavaScript was free of trendy keywords?

<comment><USER115> Indeed there were lots of competing standards and technologies, but C was still the kind of "lingua franca" among most (professional?) programmers. Many people used to write really intricate programs in it without relying on anything but standard library functions. It was about raw talent and people used to take pride in the way a program was written and not just what its effect is.

And yes, it all started to change in the mid 90's with the advent of Windows and the web.

</comment></comment></comment><comment><USER117> > who was tragically underemployed for years because of his low GPA in > college.

Is this really a thing? Just don't list your GPA...

<comment><USER118> Sometimes they flat out just ask, though. When I interviewed at google, they asked me my college GPA. After telling them I left college before getting a degree, they just repeated the same question. Silliness.

</comment></comment><comment><USER119> I've given perhaps 50-100 interviews and I'm not sure how many I've been on the other end of. I still believe interviewing is hard.

One of the things I typically told my employees and coworkers to do was to avoid psycho-analyzing someone based on small wordings and behaviors in responses.

Really, hiring is imperfect - I did try to hire people who were high energy, friendly, and not likely trying to suck up or B.S. through an interview - <USER3> there's a lot of things you can't really tell.

Many interview questions - such as targetted selection - can find negatives to not hire someone, but are easy to bypass if someone knows how those questions work (always give answers that cast you in a favorable light, etc) and are good at interviewing.

I agree that a lot of places do screen too much on cultural fit, but on the other hand, people want to work with people that will be good to work with - and they will have a LOT of time to spend with these people.

In days where we so closely identify with our work, I can see wanting people who could possibly become friends.

This becomes dangerous when it trends into ageism, or reduces the ability of very well qualified people to get a shot, and I've seen firsthand this result in some places hiring a lot of young folks that THOUGHT they knew a lot, but were really at a sophomoric level of experience.

Really good products come out of a diversity of experience and technical backgrounds. However, if someone is going to clash with the team, it's somewhat also better for them to not be working with that team - sometimes - but sometimes it may also work out great.

There's really not a good answer here, only tradeoffs.

People are squishy and complicated.

I tried to limit psycho-analysis and culture fit to "are these good, honest, and mostly friendly people".

I also believe smart people can learn almost anything, and often technical criteria or even small tech preferences that are not clear-cut can be used as code for really not hiring someone for culture fit.

Sometimes I feel a greater danger in interviewing is not allowing the interviewee a good enough picture of what is wrong about the company they are joining - often, interviews feel like sales pitches at the candidate, or focus primarily on the candidate's abilities and background, not hitting most of the things that will really say "will they be happy here".

</comment><comment><USER120> I have seen this effect in action and it is why I don't have trouble hiring quality engineers in the Bay area. Of the last 15 or so people I've hired I only had one not work out and that was due to their extended family situation making actually working really really hard for them.

That said, it can be ridiculously hard for a lot of recruiters to figure this out. I have worked with good ones (who seem to be formerly technical), bad ones (who seem to be "people persons"), overworked ones (who seem to operate much like a random decimation of the input stream would work). Another comment here on HN identified jobs as a 'matching market' which is a thing I had not heard of before. I've started hunting down good references on how folks analyze such markets.

<comment><USER121> Russ Roberts has a great podcast about matching markets with Alvin Roth [http://www.econtalk.org/archives/2015/07/alvin_roth_on_m.htm...](http://www.econtalk.org/archives/2015/07/alvin_roth_on_m.html)

</comment></comment><comment><USER122> I tend to agree with most of this (university, GPA, subject, blah blah blah). Bits of paper that are signals of arbitrary things (family standing, ability to take on debt, country of birth).

Anti-Windows bias doesn't really feel like an example of 'pedigree' to me, though.

I can't imagine programming on Windows. I can't even imagine using the OS. I moved away from Windows ~a decade ago and haven't looked back - it seems to be getting worse every year (the business model for W10 appears to be surveillance?).

Anyone care to chime in? What's the appeal of Windows in this day and age? To me it really feels like 'big companies use it so their programmers do'.

<comment><USER81> Things that I love about Windows programming:

\- IO Completion Ports (IOCP): [https://speakerdeck.com/trent/pyparallel-how- we-removed-the-...](https://speakerdeck.com/trent/pyparallel-how-we-removed- the-gil-and-exploited-all-cores) (to quote slide 40: "What works well on UNIX _isn 't performant_ on Windows[;] What works well on Windows _isn 't possible_ on UNIX").

\- native support for fibers (CreateFiber etc.)

\- binary compatibility for GUI applications over decades (try to get to run an application that was linked against GTK+ 1.x under a current GNU/Linux system)

\- I personally prefer the Visual Studio debugger by far over gdb (but YMMV)

\- there is exactly one way to write GUI applications against (WinAPI) - <USER4> other libraries as MFC, WTL are just wrappers for it. Try writing an X11 app against XLib or xcb and you will find out why Windows is better in this point.

\- the same holds for other GUI functionality as clipboard and drag & drop (OK, admitted, it is a PITA under Windows, but far worse under GNU/Linux/X11)

\- When developing GUI applications under Windows vs. say Gtk+ oder Qt under Linux: If there is some functionality, which is very low level (say, support for multiple mice): Under Windows for this there is Raw Input and under X11 there is XInput2. While the Raw Input feels integrated quite well into the style of the whole WinAPI, using XInput2 when developing using Qt oder GTK+ feels really foreign and I always fear that I will break something. In other words: When developing for Windows the APIs often look much more homogenous than under GNU/Linux where I personally feel that there are different libraries with different styles (but you might feel differently)

\- I find the MSDN documentation much more helpful than man pages, but this might be my personal preference, at least I feel that when under Windows something is documented it is nearly always documented really well, while the quality of documentation varies a lot under GNU/Linux and is (for things that change more often) often outdated

\- Also I consider it as a bad idea that many Linux devs consider code as documentation if by default most "user-centered" GNU/Linux distributions will not install by default the source code to any installed package.

\- I personally prefer the slightly "overengineered" style of the Windows API instead of having to hack something (sometimes ugly) together if the API will not provide what I need; but this is again a matter of preference.

<comment><USER123> that is a great presentation. the degree to which everything is asynchronous in NT is awesome. it's a shame techies don't engage with it or dig in to it and just say that linux is better because it has a better shell.

<comment><USER81> > linux is better because it has a better shell.

Are the usual GNU/Linux shells still better than Powershell (being better than cmd.exe is trivial ;-) )? I'm really interested in a serious evalution from both Windows and UNIX nerds.

<comment><USER123> well they're more familiar ;)

it also comes down to explorer vs anything else. I'm a huge fan of NT, but everything else is kind of mediocre. using someone else's windows computer recently I had the awesome experience of running an installer, being told I needed to install the ".NET 2.0 runtime", so I go to the control panel and select "remove programs" then select "add programs." why is add programs behind a button that says remove programs?!

the criticisms of the technology are skin deep but when you're using the system, you're interacting primarily with the skin, so...

</comment></comment></comment></comment></comment><comment><USER124> > _Sometimes people don't agree (e.g., it took months to get the non-version- > control-using-team to use version control)_

There's an easy way to stop that sort of attitude. The next time that a bug occurs, you tell that team that they must restore the code back to what it was previously, and provide diffs that show what they did so that you can review their rollback.

When they say they can't, you tell them that's their problem as they haven't implemented version control because they believed they didn't need it, and they need to go do it anyway. After they go through this exercise, you then offer to help them to implement version control.

<comment> jon-wood That's not actually going to achieve anything other than making an already stressed team more stressed with a side of hatred for you and your pointless request.

In this day and age I'm not sure how you do persuade a team to use version control other than mandating it and sucking up the hostility while they settle in, but taking the opportunity to make a smug point while a team is firefighting isn't the way.

<comment><USER124> Oh yes, _truly_ pointless. Much like their insistence that they can get by without version control really. The team has already pushed back on something that no professional software development team can get by without, and even the _most_ amateur of software projects use. I mean, you need to ask yourself why they are so stressed and you know they aren't using version control?!? Cry me a river!

</comment></comment></comment><comment><USER125> And the thing that sucks is that a lot of the best places to get started as someone out of college is a .NET or otherwise boring shop. Not everyone who is talented and intelligent has been programming since 7th grade or went to a brand-name school.

Unemployment after graduation for CS majors is one of the highest because a lot of times they aren't ready for the real world. They get started in a .NET shop and grow in to better developers. I think we can all agree that if you consider your self good at this it's mainly because _you_ had to or wanted to do it for real and thats where they get the experience to be on their own.

</comment><comment><USER126> Please apply at least a bit of css like this website: [http://bettermotherfuckingwebsite.com](http://bettermotherfuckingwebsite.com)

<comment><USER127> I find that site a bit misguided. Any amount of CSS might still break, for example, w3m. It seems more sensible to have pure HTML sites with client-side styling within the browser.

</comment></comment><comment><USER128> I think cold hiring is dead: draining exchanges of info lead too much too often to nothing and leave both parties dissatisfied. Referrals are the easiest way to go.

<comment><USER50> The industry seems to be trending this way, but I think that is a very bad thing that should be fought at every stage. It is leading to ghettoization of talent and the perception of a talent shortage that probably doesn't exist.

</comment></comment><comment><USER129> What does a "trendy" resume look like in 2016?

<comment><USER130> If you have a resume you're not "trendy". You're "trendy" if you have a github account full of projects in Go and Node-y stuff, a twitter-stream with a few thousand followers, some medium rants and (maybe) a linked-in profile.

eta: ... and 10k+ karma on HN and SO ;)

<comment><USER131> Oh yeah, also lots of talks

Most of those are not as 'intellectually stimulating' let's say but it might be interesting to have something there

</comment></comment></comment><comment><USER132> I think this is a symptom of SV not pursuing "hard" tech. They dont want or even need greybeards to build most of the products they make.

</comment><comment><USER133> Someone needs to make a job site that filters out recruiters. I am not sure how that would work, but it was save us all a lot of time and energy.

</comment><comment><USER134> > "Experience is too random, with payments, mobile, data analytics, and UX."

this is typical HR bs. If you have more experiences it is positive, not negative.

</comment><comment><USER135> So you're telling me, that as a well-performing senior engineer in SV making 155k/year I should be actually making much more?

Damn glassdoor...

</comment><comment><USER136> I'm 50 years old and my day job is teaching teams how to perform better. I still code - love coding. But several years back I decided I could do more good in the world by helping multiple teams at a time than simply coding.

My "real" job is, of course, startups. I save for a while, then work on various startup projects. I'm learning a lot.

So now that my latest startup project is coming to a close, I'm thinking of where to go next. Instead of hands-on teaching, I'm seriously considering getting back to coding. Sit down, make something happen, look at a job well done.

The problem here is this: all I know how to do is make solutions happen for people in a dozen or so different technologies. I haven't spent time trying to keep up with the cool kids. C++? Sure. STL? Not so much. All the basic web tech (HTML, CSS, Javascript, etc)? Sure. Angular/Meteor/etc)? Nope. F# and OCAML? Love me some functional programming. Haskell/Erlang/etc? Nope. SQL Server, MySQL, some Oracle? Yep. NoSQL, Cassandra, Mongo? Not really. Once I knew enough to get the work done, well, I just got the work done.

There's a difference between coding to get things done and spending time with toolkits and frameworks because they're popular in the market. Back when I was a senior programmer, one of the most important things I did was try to guess what the cool kids would be doing in 3 years -- then study that and get some experience. This paid off over and over again. As somebody who just wants to make things happen, that's not a priority.

This leads me to my second observation, from sitting on the other side of the table looking for developers and working on staffing models. The dirty secret of the tech industry is that nobody has any idea how many developers they actually need. There's so much variability in teams, and you can break the same work down so many ways....there's a lot of risk. (Yes, there are several heuristics you can use. Insert long discussion here about how they're only heuristics.)

So at the end of the day, you have a lot of companies that want to be trend- setters chasing after what all the companies think are the cool kids -- the trend-setting hires. I remember sitting down with a SV CEO a while back talking about his 100-person shop. Everybody in the place had some cool-kid story attached to them. The place was a mess, but it was a _trendy_ mess.

At times, I am not convinced that these companies would do much better with some kind of "sweep the street" approach to hiring, vacuuming up a huge number at a time and taking them through some structured filtering/training process. I've even thought through how such a model would work. Haven't found anybody willing to experiment with this yet, though :)

As arbitrary as the system is, I'm not sure its any better or worse than any other system. And the simple fact of the matter is that buzzword-based, trendy hiring has been with us for decades. I doubt its going anywhere soon.

<comment><USER137> > At times, I am not convinced that these companies would do much better with > some kind of "sweep the street" approach to hiring, vacuuming up a huge > number at a time and taking them through some structured filtering/training > process. I've even thought through how such a model would work. Haven't > found anybody willing to experiment with this yet, though :)

Didn't IBM and a few other big iron shops do this in the 50s/60s with secretaries? iirc, they could apply to be programmers and would get trained.

</comment></comment><comment><USER138> I don't like it but I do understand it from the employers perspective. Most hiring is done to avoid risk. Went to a top school, working at a popular company and already using the tech we use? Come in for an interview. Missing one of the three? We'll phone screen. Missing two out of the three? Not worth my time.

<comment><USER101> The OP's point is that "This only works if you pay the appropriate amount". If you go with that process, but discard the "money" variable, you'll only interview the people who got rejected from every one of the well-paying companies.

<comment><USER138> I read the article why do you feel the need to summarize a part of it? Geez.

</comment></comment></comment><comment><USER139> The solution found by these companies are h1b. That is trendy since no normal developer is good enough for trendco.

</comment><comment><USER140> My experience is that cultural fit is important but more important is attitude. There's a set of can-do attitude that will almost always fix the cultural issues unless it's a very distinct cultures. Most cultures are just about being open, etc. But so few are actually hungry and have can-do attitudes.

</comment><comment><USER141> I Just read this article and am in a similar situation right now described. I tried to do a startup and it didn't work out. I'm in the job market now. In India it's a lot worse because some of my friends tell me, you've been out of a job so long it might be difficult to get a good package.

</comment><comment><USER142> Over time all the complex approaches boiled down to: * Smart * Not an Asshole * Enjoys programming

</comment><comment><USER143> I think of this as "Hiring natural selection". If they don't hire you because "we don't like windows people", or "contractors are dumb", or <insert excuse>, then you really didn't want to be there either.

</comment><comment><USER144> How many of you guys continue to interview when you sense that you're either being insulted or your interviewer acts like a jackass and thinks that he's God's gift to this earth? Has anyone politely walked out?

</comment><comment><USER145> How are Microsoft technologies not trendy?

F#, Reactive Extensions, Xamarin, Typescript, etc.

</comment><comment><USER146> Run this js if you find it hard to read the site:

        document.head.innerHTML+="<style>body{margin:40px auto;max-width:650px;line-height:1.6;font-size:18px;}</style>"

</comment><comment><USER147> There are individuals who are undervalued by the market. One should find them, hire them, create a consultancy and make a bunch of profit from it.

</comment><comment><USER148> Do people really discriminate against a suit and tie? I've dressed up for every interview I've had and nobody seemed offended.

</comment><comment><USER149> You can replace "trendy" with "good cultural fit" in many places. Cultural fit is arguably the most important factor in hiring someone. From my network, I see a hugely different culture at Microsoft and Google. Just saying.

<comment><USER81> If this is so important: why don't they specify the desired culture values beforehand in the job ad so that people who don't fit don't have to waste their time applying for the job?

<comment><USER150> Because writing "young white men only need apply" is a fast track to a lawsuit.

Its obviously OK to implement it, plenty of examples of that, just not OK to talk about it in public.

<comment><USER81> What reason does the company have to think that young white men fit the job better? I can imagine that there are properties that these kind of people have that makes them a better fit, but why not advertize these properties instead? This should probably not lead to a lawsuite.

<comment><USER151> I think it mostly boils down to the "people like us" effect.

</comment></comment></comment></comment></comment><comment><USER152> Great article with a lot of good points. Enjoyed the read.

Having said that though, the first paragraph or so made be choke. In the "hypothetical" case of Mike, who after being layed off from Microsoft finds himself a little shocked that his "skills and experience" are not valued in the real world ... well, its really hard to have any sympathy for him.

Hiring on merit is one thing, but there also has to be some weight added for a candidate's integrity (or total lack thereof, as in this case.) These Microsoft folk will never understand how much damage they have done, and how deep the resentment against them runs. Its not even worth trying to explain to them.

For another example, lets consider the hypothetical case of "Gavin". Gavin is someone with brilliant skills in say - early childhood learning, adminstration, media relations and marketting skills. He applies for a job as a senior admin at a childcare centre. The application is rejected !!! Gavin is appalled at this blatantly unfair treatment, so decides to investigate further and marches into the office to demand an explanation.

Anyway, as it turns out, Gavin proudly made full disclosure on his CV about a number of recent highlights in his career, including filming and marketting child pornography, collecting healhly organs from child donars for resale in the Middle East, and also the collection and hiring out of particularly talented children to both the Catholic Church, and the Freemasons.

"Gavin" sees these activities as mere expressions of his brilliance in the fields required. He is at a complete loss as to why all the staff / parents in the childcare centre are "discriminating" against him, and some are even casting unfair daggers in their eyes. He cant understand why ???? Perhaps they are just inferior to him.

I dont see this as being any different at all to the hypothetical "Mike" situation. Seriously - Fuck Mike !

To anyone recently layed off from a job at MS, who thinks they can jump bandwagons onto the next "trendy" thing in software, I think the most humane thing to do would be to tell them the rotten truth right up front .... "Just Fuck Off, and get as far away from software dev as you can. Get a job pluckng chickens, or collecting broken glass, or whatever pays the bills ... but whatever you do, keep the fuck away from our computers. You are NOT wanted here, and we all have excellent reasons to hate your guts with a passion and intensity that you are too selfish and narrow minded to ever comprehend."

.... but they would still think this was unfair ! Ridiculous.

</comment><comment><USER153> Loved this article. Over a year ago, I decided to leave both my technology stack (in which I had 8 years experience), and the big corporate employment record behind. I had about 10 years of industry experience, and considered myself a generalist - capable in many technology stacks, and highly capable of learning and quickly becoming effective in a new one.

Also, I had a nice comfy savings account, so I decided not to work for 6 months while I focused on me-time and learning NewTechnologyStack. I fell in love with it, and havent looked at OldTechnologyStack since. I wrote many demo apps, started making open source contribs, and engaged with NewTechStack communities online. Damn that was fun! I joined local meetup groups and other communities to fill my sponge-like passion for NewTechStack to the max.

Let me also state that with OldTechStack, I never, ever had a problem finding a job - really, it usually takes me about a week to land a new job somewhere else in my bustling tech-hub city. My resume with OldTechStack was, well, very trendy. I could often tell in interviews that people were going to hire me based on my resume before they even spoke to me in person, and that the in- person resume was just to reassure themselves that I wasnt bullshitting them. Dont get me wrong, Im a great programmer, but I know I was hired because my resume was nice 'n trendy (with the OldTechStack culture).

So, once I started looking for jobs in NewTechStack culture, the reality of the superficial hiring process really set in. Firstly, NewTechStack people have a cultural internalization that OldTechStack really sucks. Mind you, I am _not_ referring to technical folk, but HR people, recruiters, entrepreneurial types, etc. Secondly, I had no idea that taking time off from work made me look really bad to most folks at the base level of recruitment. Because I was not currently employed, I was not making it past many screening interviews. Thirdly, there was this magic phrase, "x many years of _PRODUCTION_ experience in NewTechnologyStack..." that was really screwing me over. Despite the fact that I am proficient in 4-5 major programming languages, and have experience in several more. Despite the fact that I have lots of demonstrable work, both public open source, and my own creations (living at live URLs). Despite that my career experience has given me challenges that are scaled many-powers-of- ten beyond what your rinky-dink logistics app's customers demand. Despite that I interview wonderfully, am willing to do programming challenges for free, and usually deliver above and beyond expectations... Despite basically being a wonderful candidate from your engineering team's perspective, I found myself being rejected for these and many other superficial reasons.

Right now I am elated that none of those companies hired me, as I found my way via freelance contracts, and my life could not possibly be more well balanced and I have never been happier in my career. Right now I also work on about 7 different NewTechnologyStack production websites with relatively complex e-commerce and marketplace challenges, as again, I handle generalism well, and well adopt AnyTechnologyStack much better than your "senior dev" with a whopping "5 years production experience."

Guess what? Every single company that I interviewed with about 9 months ago is _still_ hiring for the same damned position I applied for. Some of them have even reached out to me on StackOverFlow or other career sites, like a zombie, unknowing that theyve already interviewed this candidate...

Why?

Because theyre obsessed with an irrational, non-science based, peacock-dance, superficial standard for hiring people, specifically with standards they are not at all knowledgeable of, that they somehow believe will lead them to "hiring the best" and becoming the next Google (with their rinky-dink logistics app with about 4K customers).

I am not suggesting some "science based" checklist system take its place. I do think the peacock-dance, and other completely inauthentic behavioral checks, need to be removed from evaluation. Dont get me started on all the dinosaurs still relying on "technical tests" that throw college-level abstract puzzle games at you, which have been scientifically proven to produce false positives as well as false negatives.

Pro tip: copy and paste documentation from YourTechnologyStack official site to your blog, write one sentence saying, "please leave a comment below!" and youre instantly more hireable (to recruiters at the screening level) because, well, youre a blogger, and youre clearly engaged in the community.

Companies are so obsessed with "hiring the best" that they basically buy a "hiring kit 'n a box" and hope it automates itself, when all theyre doing is creating an absurd gauntlet that rejects lots of great candidates, and leaves them without any hired candidates 6 months later. The "rockstar" programmer, mythical though she/he may be, is still the goose that lays the golden egg and turns your company into NextGoogle.

The level of absurdity with the hiring process as a software engineer is obscene. For people who spend most of their professional time dwelling in thought-realms of pure logic, getting hired is a maddeningly illogical process.

</comment><comment><USER154> This is a great post!

</comment><comment><USER155> Yeah, this really affects old non-degreed codgers like myself. I find it difficult to get "a foot in the door", but luckily my performance always leads to comfortable retention once I do. As I get older though, that's going to get much more difficult.

</comment><comment><USER156> Greybeards do not mix with the hipstor kids well. In the other news, the Pope is catholic.

<comment><USER157> And both groups do a disservice to each other when they cannot work together. There are a lot of new ideas that we greybeards can learn from the greenies and there are a lot of tested foundations of which the newer generation is often unaware of, especially those that were taught to not worry about resources.

<comment><USER156> > And both groups do a disservice to each other when they cannot work > together.

Why? What's the point of doing anything at all with the hipsters? They're irrelevant.

> we greybeards can learn from the greenies

Of course! But there are fresh engineers and there are trendy hipstors. They've got nothing in common besides their age.

</comment></comment></comment><comment><USER158> You need to be a highly skilled wage slave

</comment><comment><USER159> tired of software engineers getting shit on...the only reason that software engineers can't make large amount of money is the company suppresses the wages.

all you need is someone business saavy, partner up with them while you offer technical know how to realize the vision. For me, this is the much easier and better rewards. My odds are better in this environment because I'm naturally inclined to danger, the unknown, and creatively approaching problems that have only come by trial and error.

whenever I read articles like this, it makes me glad I chose entrepreneurship over 9-5. With rise of deep learning, as you've recently witnessed with AlphaGo, relying on salary as part of the cost operations part of a business doesn't have good prospects into the future.

its time engineers began looking outside the well but I fear my advice will largely be ignored and scoffed at. Entrepreneurship? Sales? Business? These things don't matter in a world of commoditized open source software?

Surely, one has the wisdom to know the pitfalls of narrow mindedness past late 20s.

</comment><comment><USER160> I couldn't stand the wall of text on such a wide screen that I have. But the TLDR seems to be not to hire based of trendy skills, which I agree with.

<comment><USER161> "Wall of text" is usually reserved for people who don't use paragraph breaks; such a complaint is unfair on a perfectly well-formatted page. If you want it narrower, maybe make your window smaller?

<comment><USER160> IMO, it's almost impossible to stay focused when the text is poorly formatted as it was in this article. With just a couple of lines of CSS the readability would increase tenfolds.

I shouldn't have to make the window smaller in order to be able to read the authors post. If people find the formatting too frustrating, it's their problem as they want to convey a message to me, not the other way around.

<comment><USER162> I feel that's more a problem of the browsers not being adapted to simple text anymore that the fault of the author sadly.

Personnaly I use that bookmarlet that help greatly for such pages (found it on a thread here on HN) :

javascript:(function(){var a = document.getElementsByTagName('body')[0];a.style.maxWidth=630+"px";a.style.margin="auto";a.style.padding="0 15px";})()

</comment></comment></comment></comment><comment><USER86> Well, I personally would have a lot of caution inviting in someone who is familiar with .Net, out of concern that he would be a Trojan horse. He would be more familiar with proprietary than free software, and hence when confronted with the choice to either bring in what he knows or learn something new, under pressure, it's likely that he would try to bring in something from Microsoft or another proprietary vendor.

No thank you. Free software is better for developers, better for my team and better for our company. Yes, rarely it's missing a necessary capability, and sometimes it's missing a nice capability, but it's normally quite as effective and, y'know, _free_.

I share his surprise about the concern over someone with too varied experience. In my own experience, that's generally a plus, since such folks often have surprising depth along with their breadth.

I also share his surprise about the concern over someone who's been contracting. I've run into contractors who basically just fill in the same template at every job, granted, but I've also run into contractors who are _sharp_ and have — again — an amazing breadth and depth of experience. You just have to spend some time interviewing them to find out who is who.

But, again, I'd have huge concerns about bringing in someone whose experience has been with Microsoft or Oracle or IBM. I'd be very concerned that he was just a glue monkey assembling bits & bobs of proprietary software and not an actual developer.

<comment><USER163> That's an incredibly naive filter. I'd estimate the vast majority of developers don't care too much about whether their technology stack fits some arbitrary ideal. A good interviewer would focus on gleaming out a person's understanding of the fundamentals, and more important, actual instances of problem-solving, creativity, and learning.

> I'd be very concerned that he was just a glue monkey assembling bits & bobs > of proprietary software and not an actual developer.

You can remove the word proprietary and apply that claim to a significant number of developers, regardless of their chosen tech stack.

> Free software is better for developers

Citation needed.

<comment><USER164> > > Free software is better for developers

> Citation needed.

How about Joel Spolksy[1]?

        Any Windows developer will tell you about the time they spent four days tracking down a bug because, say, they thought that the memory size returned by LocalSize would be the same as the memory size they originally requested with LocalAlloc, or some similar bug they could have fixed in ten minutes if they could see the source code of the library.

[1] [http://www.joelonsoftware.com/articles/Biculturalism.html](http://www.joelonsoftware.com/articles/Biculturalism.html)

<comment><USER165> And on the flip side, I've had potentially hours of source dives (because, spoiler alert, I have the .NET Framework source code on hand and have for a couple years now) made unnecessary because the MSDN documentation, which was made because they would like programmers to be productive, explained an edge case before I stepped on that rake. Compare to _plenty_ of other environments where the source dive was the only option because the documentation was an atrocity.

It's not nearly as cut-and-dry as you want it to be and you will be better at your job when you internalize that environments _you don 't like_ have pluses of their own. I choose to use Unix for my own projects because it makes sense for the projects I'm working on (the stray game-development project aside), but I have declined to participate in the epistemic closure of those who think Windows and .NET have nothing to offer or to teach.</comment></comment></comment></comment>