It is utter voodoo.

I came up in the late 80s. Interviews were maybe 2 hours long. You might be handed a piece of paper with a problem to aggregate some information distributed in a few different arrays and print them out. You know, write some for loops and a few logic statements.

Then you talked about the job. This is the job. Do you want to do it? What do you have to bring to us? Do you have a lot of experience and want to lead, or not a lot and want to learn - we'll adjust position and salary.

And you put a team together. Some were great, some were okay, some needed to be let go. In total, all sw people had a job.

Contrast that with today's voodoo, where proxies are weighed more than on the job performance (the only thing that matters).

In the end, you put a team together. Some are great, some are okay, some need to be let go. In total, all sw people have a job.

It's all exactly the same, except the absurdity of interviewing by proxies. It's simple logic - he average of everything is average. Why have we abandoned logic?

So many things matter more than remembering red-black trees from your midterm (I'm 49. I TA'ed a graduate level algorithms class back in the day, but I don't happen to remember it. That's what books are for). Like being able to run a project. Being able to write documentation. Being able to enter a room with a combative and upset client and keep the business. Being able to mentor your colleagues. Taking ownership. Leading by example. Ability to learn. So many things that are not even discussed in the current interview environment.

I've watched companies spin their wheels for months, rejecting perfectly good people, looking for that mythical person with exactly the right, esoteric combination of skills, who, for some unknown reason, wants to stall their career and get hired into a position where they learn nothing because they are expected to know everything already. People that are eager to learn? No, sorry, not rock-star material. All these prior successes mean nothing, no one could possibly learn a technology or new algorithm, right? And, more than once I've had people get downright snide about it. I'm sorry that you misread my resume, contacted me, and I didn't have that absurdly specific combination of skills. My fault, right?

Y'all have lost your minds. :) Which is okay, we're an eccentric bunch, but jeez, let's inject some reason and introspection into it. The faces are different, but the talent is no different than the 70s and 80s. There's zero evidence that any of these interview techniques are reliable. There's tons of evidence that interview techniques are horribly biased in many ways. Just stop.

What disappointed me was, 3 of the interviewers had no idea about my background and weren't able to extract my strengths. Even though I am a new grad, I have interned for 2 years as an app dev and learned a great deal about design, code quality, testing and etc...

I have read Effective Java, Clean Code, and Head First Design Patterns. I'm reading Java 8 in Action now. I have not memorized them page-to-page and still need more experience to master them, but at least I know some of resources I can go to for more answers. I have participated in code reviews and enjoy them. I can implement LLRBT and many of the algorithms you can expect a new grad to know but I have not invested my time on hacker rank and uva.

I don't know what SV or big tech companies are looking for. I constantly hear interviewers say they want good engineers but fail to capture the essence of a potential good engineer well. What benefit is there in hazing anyone with problems many engineers don't deal with without the tools they use every day, and with an absurd time constraint. Kosaraju didn't come up with SCC in 30 minutes and he had a PHD. Sure I can spend hours studying for whiteboard questions but to what benefit. I am sure anyone of you can come up with a whiteboard problem you can't solve in 30 minutes, but what does that say about you.

Don't complain that interviewers haven't read your resume; it is your job to tell the interviewer about the relevant parts of your resume and why they matter for the job you are applying to.

I disagree. If you're going to interview me for an hour, the least you can do for both of us is to take 10 or 15 minutes ahead of time to familiarize yourself with my background.

it is your job to tell the interviewer about the relevant parts of your resume

Again, I disagree. A resume is only a very cursory overview. You can use it as a starting point to probe me about it, to at least determine if I've actually done what it says or if I'm just a buzzword bullshit artist.

IMO it's very shortsighted for someone to ignore a resume before conducting an interview.

The bigger point I'm trying to get at is the following: do not expect the interviewer to discover how brilliant you are on their own. Being smart, hard working, is not enough -- you also need to tell people about it.

I will be more proactive on my next interviews. I did have my github on my resume; I will add more projects to it and get involved in OSS.

https://en.wikiquote.org/wiki/Albert_Einstein

There are also and other things that are in the periphery of what I need to know, but can look up easily when necessary. These include things like my mother in law's mailing address, my coworkers' phone numbers, my wife's phone number, the population of the US, how to rewire a plug socket, and the recipe for Belgian waffles.

Each of those things would be good to know, but we can effectively offload it to external memory.

They become annoyed during interviews when they are asked some concept and suggest "I'd just look it up on Google", which is fine for matters of programming syntax, but not fine where it reveals that a developer does not understand an important concept.

Yeah, all that stuff is stupid. Who the fuck cares what the capital city is for each of the 50 states? That's what atlases used to be good for, now it's an almost instant search in Wikipedia.

I've had a few folks that I've had to let go folks, including folks in .gov with union contracts and motivated defenders. It is doable.

End of the day, don't be a wuss. Setting up some hunger games "audition" is passive aggressive bs. If you're nervous, hire a contractor and get them on the payroll later. Or just hire the person, and give them a months severance. Problem solved.

It's an at-will state so you can leave without notice and be laid off without notice. It seems that would cover the majority of circumstances and protect both employee and employer, for better or worse.

The other reason is the company is not really looking to hire, just placate their current employees - "yes we know you are over worked, just hang in there while we hire someone to take off the load".

Which may be why people that are below par haven't been let go? A need to throw bodies at a problem rather than step back and give it some thought / work it out.

The CEO of one of my past clients, a consulting company, always said: "You can teach everyone to be a great programmer". And he put his money where his mouth was: He hired people with no programming experience (even with no university education) and personally trained them for several months. Also, senior people in the company were encouraged to also help them and guid them.

He had to fire some of those people later, mostly because they were not a good fit for the company. But some of them became great programmers and software consultants.

"Hire only the best" is really only half of the battle. Give people an environment where learning is encouraged and failure is expected. And help them wherever you can. Most will learn and enjoy it.

Flat out dead wrong. If you hire "anyone" and try to teach them to be a programmer then you will probably fire them.

This is the sort of attitude that leads companies to outsource their development overseas: "Our programmers are people hitting keys. We'll get overseas people to hit keys and overseas people hit keys for less money.", cause, you know, anyone can do it.

Programming is VERY hard and it takes a huge amount of motivation and hard work to become any good at it. Sure you can learn how to do simple stuff without any serious interest, but to be beyond ordinary it takes enormous work and time and research and Joe Schlepp off the street is simply not going to do that.

If you want to hire people and teach them then you need to look for these things: enthusiasm for computers and programming, demonstrated willingness to learn, energy and effort. You should value energy and effort more highly than anything. Those are the raw ingredients for trainees, and people with those ingredients are far from "anyone".

My experience would support this. You need a mindset keen towards rigor, and motivation. Given those, and guidance, anyone can learn to program - at least in limited contexts.

Programming isn't just about writing the code itself; in many ways, that's the easiest part. It's about identifying and solving problems, many of which aren't actually your problems, meaning you have to have the ability to step outside your own frame of reference to understand the problem in the first place and continue doing so in order to work up a solution. Even for a junior developer, those skills can be a huge boon.

Learning, say, Wittgenstein's philosophy regarding grammar and language [1] gives an interesting insight into how humans express ourselves and delves directly into the heart of modern programming, IMHO. Rarely do we software developers write low level algorithms anymore, but writing consistent and complex API's is crucial and shares more in common with be conversant with large volumes of philosophical treatises.

Based on that, it makes sense many philosophy students would have successful careers – being able to reason and solve challenging problems is always key point in making good money. :)

[1]: http://plato.stanford.edu/entries/wittgenstein/#Gra

Don't take things too literally. What he basically meant was "anyone with appropriate aptitude and intellectual maturity" -- like you yourself said later on, pretty much.

Which may or may not be entirely correct, but is far from "dead wrong."

BTW, please be careful about referring to foreigners, in any context, as "monkeys."

I just got back from an business trip spanning 3 cities and 5 flights. The self-loading cargo in the airports, jetways, and boarding the plane could easily have been described as monkeys. I was literally called a monkey by a colleague for absent-mindedly and needlessly blocking a sidewalk in the parking lot while waiting for someone to pay for parking. I took no offense, of course.

My point is that if you do not understand that programming is highly skilled work (and many companies think this) then you might think you can get anyone to do it for a similar outcome and therefore it is a commodity and therefore the only thing that matters is price.

Just that even analytical people tend to think "associationally" when they see certain keywords -- and one has to keep in mind that not too long ago, people in many of the countries that software development is frequently outsourced to were, in fact, thought of as monkeys, pretty much (or something on the human-monkey spectrum).

So whenever I see associations like that creeping into my own writing, I try to dial it down.

http://theconversation.com/the-ape-insult-a-short-history-of...

And we keep going around and shout that and other people believe it. And in turn we are being taken advantage of with long hours, unfair compensation for our contributions and the worse of it all? Ageism in our industry is rampant.

I look at physicians, surgeons, accountants, lawyers and others with envy, because in those professions, the older you get, the more esteemed and valuable you are. We peak at 30.

A critical problem that exaggerates the "ageism" is people who sit in the same corporation for 15-20 years, get laid off because companies change, and haven't refreshed their skills for many years. I saw my spouse go through this last year. She got laid off from the company where she'd worked in a variety of roles for 13 years. Her field toward the end was product management/ownership, and she liked it, but she didn't like Agile - she'd had bad experiences at her employer with careless engineers using "agile" as an excuse to have no process and no oversight. She had also spent many years developing deep domain experience in a narrow specialty (international e-commerce). She could find generic PM jobs easily enough, but they didn't exercise her domain experience and they didn't want to pay her what she'd been making just to be a generic PM. It took her six months to find a new job that uses her domain expertise (educating herself about Agile along the way).

For people less determined and hardworking than her, the problem can easily be much worse. If you've done nothing but Microfocus Cobol for the past 20 years and suddenly have to find a new job because you employer finally ditched that antique piece of crap, and you aren't interested in learning how to do something modern, you're in a world of hurt.

Some people stay in a job for 15-20 years. They are a programmer for maybe 10 of those, but over time they grow into a niche, the company grows, and that becomes a job title.

Maybe they get called a project manager, or a product owner, head of QA or engineering or lead architect. Either way they aren't a programmer any more and they mostly manage something instead of doing - manage people, contracts, processes, customers...

And that's why programming has a pay ceiling - careerist programmers become something else, and footloose programmers become consultants and contractors and leave the regular pay figures.

The value of a good programmer probably becomes diminishing returns after a certain point. The best programmer in the world can't raise the sales of your web app past a point - if they do what it takes to do that they become something else, like a product manager. That point depends on the technical difficulty of the task and the size of the opportunity, but most code needs a good coder, not a great one, and beyond that it's all product fit, sales and luck.

I'm footloose too, and I'm noticing as I get older that the people interviewing me have often been in their job a long time. They bet on the company and became less flexible in the general labor market in return for better opportunities internally.

Honestly, when I work for them, I'm usually surprised how many normal things they don't know. Maybe they've never seen proper unit testing, or don't know what ITIL is, or think linux is still an immature product and you should stay safe with a microsoft stack.

But they know why the code is the way it is. They know what was tried in the past, and how it failed. And their boss has seen what they do in a crisis, which is much better than trusting someone unpredictable.

My suggestion to someone young, if you have the temperament, is to stay for up to a decade and grow into a new, higher value role. Then learn that until you know it well enough to get a job elsewhere and move before you stagnate.

Note: government is not one of these industries. Developers are underpaid but the job security is real.

Do you mean something like "net value to company"? Then maybe. Another way to say that would be "you start to get paid what you're worth after 30 or 35."

For example, the lawyers I know are now making partner in firms, the business majors getting percentages based on sales and earnings.

I'm looking to become a consultant but the very idea of increasing pay with experience is foreign in the tech field, but standard in other professional trades. I believe offshoring, H1Bs, and lack of a professional association (AMA, bar, etc) is to blame.

At 30 I was just getting started. If you feel you peeked, find some new jobs and technologies that you'd like to have on your resume and find new jobs. How about java and distributed systems at a place like google or facebook, c++ on a major database? Look for those things.

The question is: you've been doing higher level work, but has your compensation flatlined?

I left one of the big internet superstars, and tried a startup. After a year I decided it wasn't going anywhere, so I went to a medium sized company that is really growing. I make slightly more in salary than i did at my internet superstar company, and more $ value in stock grants. My new company is growing so the stock should go up, but its less certain too. My job title looks good, so I will be able to use that in my 'next' job, if there is one; maybe I'll stay here forever. My goal is $400-$500k per year in salary and stock, over a 5 year average. Say you get about 200k in salary, and you get an initial 4 year stock grant, and each year they give you another 4 year one, so it takes several years of that to overlap.

I guess I can say I'm in Seattle.

I was more than 10 years at Microsoft, mostly IC and some lead work, and then back to being an IC at the internet giant, then lead at a startup, now mixed design and dev at the new company; i was hired on dev skills plus experience.

$150k in stock and salary is reasonable for an experienced dev, say 10 years. At the startup we paid mid career good devs 150k in salary, plus worthless options. A typical deal for devs with 10+ years who can do c++, java, distributed programming is 150-175k in salary, a couple 100k in stock, paid over 4 years, plus new grants each year. 2 years ago when twitter was doing better I got almost 200k in salary, plus double that in stock, payable over 4 years.

The unadorned "developer/engineer" role[1] -- that is to say, not CTO or even Lead Engineer -- itself seems to tap out after 8-10 years, in terms of both salary and respect.

That is, in the average case, anyway. There are of course companies which pay upper-tranche (in terms of salary and respect) for very highly talented programmers who aren't in leadership or crossover roles. But these are a comparatively rarified stratum; by and large -- for the great majority of companies out there -- the "Senior Developer / Engineer" role definitely seems to plateau within about that timeframe.

So if you don't find yourself drawn to that category of engineer (and to those kinds of companies -- many truly gifted programmers I've known still pull down decidedly average salaries) -- and you find yourself wanting more salary (or respect / responsibility) -- you better start thinking of something else.

[1] Leaving aside distinctions between "developer" and "engineer", as discussed elsewhere recently, for the sake of simplicity.

Then in my 40s I went back to being a dev and learned a bunch of cool stuff at one of the amazons, googles, facebooks of the world. Now I'm 50 and have another great job, get tired of replying to recruiters.

Look for jobs that teach you great stuff, expand on the important tech skills you don't have, pay well, and look good on your resume.

It's so rare to actually use something made by someone in their 20s, that it is a noteworthy event to mention their age.

I'm not a 10x programmer by any means, but I was able to write and sell non-trivial software in middle school, with little more than a pirated copy of Delphi and a book.

Most of the difficulty that does exist has more to do with bad engineering practice and poor documentation than anything else.

If you choose to read my comment that way then you are choosing to hear the message that you want to hear, which is a reflection of you and your personal issues.

My comment in no way suggested that overseas developers are incompetent - in fact whether or not a developer is competent has little to do with where they live - although economic opportunity is part of the equation. Great programmers create themselves by hard work and that has nothing to do with location.

I do agree with you however in that there is a difference between greatness and adequacy

   "You can teach everyone to be a great programmer"

You can train most people to do most tasks. With a modicum of natural inclination, competent. With a bit of interest, good. With a willingness to work hard, very good.

However, you can't ever train greatness. You can't make it by any method - only they can.

Your broader point is good though. The most predictably effective way to end up with top talent that works well in your structure is to help it develop.

What's desired is that our company have the best talent, but that someone else develop it for us. We'll pay the maintenance fee at a high level but we won't actually invest in it.

This is a simple problem - we know the cost of everything but the value of nothing. And then we begin to redefine "best" down to make it easier to measure.

You will not meet such people very often unless you are in a truly extraordinary situation, which means you may well never work with one.

My argument is that such people, whatever the field of endeavor, do not ever become great through training alone. You can only develop the conditions for people to reach their full potential, and hope that some (small number) of them truly become great.

You've not really solved the problem by stating that, all you've done is swap one subjective term (great) for another (better).

FWIW, I don't think everyone is naturally suited to programming, but I do know I've met a number of people, with a diverse range of backgrounds, who I am confident would be employable as programmers with the right guidance. The two biggest traits they all share is attention to detail and an openness to learn. I'd argue that's all you really need, everything else is just a matter of effort and experience.

But I believe you are being obtuse here. I've never met a large group of programmers who wouldn't have rough consensus on their "better" colleagues. Begrudgingly, perhaps, but it is there. Human beings naturally self-organize this way all of the time, the metrics are definitely imperfect but pretending they don't exist or are somehow meaningless is just perverse.

Nothing I said claims that diverse people cannot become perfectly competent programmers, this is certainly true.

The claim was more that "greatness" in part, at least, necessarily comes from within.

That goes into the whole nature vs. nurture debate, and you can probably find arguments for both. Playing Devil's Advocate, I'd suggest there are traits that help you become a great programmer, but those can be learned traits. For example, "thinking like a machine". You're a much more effective programmer after you can build a mental model of how the programs you write are working at a lower level of abstraction than the one you're programming in. That's something it's undeniably possible to learn, the main barrier for most people is a lack of interest. You have to be prepared to learn a bunch of supporting material that may not pay off in the near future, but will help you in the long run. That's my experience of what it takes to become good/great/better at nearly anything.

https://en.m.wikipedia.org/wiki/Arete_(moral_virtue)

We do have a college intern and hire program, but it's very rare for a new college hire to have the same ROI as my best experienced colleagues.

My big issue: Startup hiring kids to do work that should be in the hands of lawyers. I've seen interns redlining contracts and social media directors heading compliance teams. Some expertise cannot be developed in-house.

Is that true? Maybe for a subset of people, and (union) a subset of the skills. But one can surely improve their knowledge in an environment where there is nobody able to teach him. The environment must support a few failures, because they'll happen, but it is possible.

Most times, the premise of a start up is that 2-4 people with well developed non overlapping skills get together and build something with each being such an integral part that they are worth a good chunk of equity. Perhaps 5/6 is a CS person that you train as OPs / Dev on the side. But most companies don't have the time or man power until the team gets into the double digits.

On the other hand, if you want to build a pipeline to solve tomorrows hiring problems, go out and interview unskilled people that want to do the job you have. There's some wash out but generally you can make a pretty good batch of people. I've done this in a couple places and it can be very rewarding not to mention as they start to develop and move out to other teams they are often willing to spend some time giving back to the program that helped them up on the ladder. Which means that you have more eyes and hands helping develop people and more time for coffee.

Most of the code I've written, even the best of it, is long gone. The company died, the system eventually got replaced, the business needs changed. I've debugged some epic problems through herculean efforts, but in retrospect most of those problems shouldn't have even existed; bad work process created bad results. I created some great system architectures, but technology advances so rapidly that the great solution of 10 years ago is now sadly out of date.

But getting some non-developer hooked on development? The shine on that doesn't wear off. Taking somebody who's struggling and helping them become a solid contributor? I'll always be proud of that.

The best organizations "grow" their talent in addition to "finding" it.

Talent is not a resource which merely exists out in the wild like some kind of unicorn. Talent is DEVELOPED in the right environments with the right team and the right resources.

Large companies especially, need to take a bit more responsibility for cultivating talented people instead of merely project-managing "resources" ad-nauseum, and then finding increasingly elaborate ways to find and recruit talent.

Both ways (grow and manage), though, I find the notion of "find the best, set them free, done" is insufficient.

They tried this during the dot-com boom of the late 90's... I don't think it worked out too well.

They hired just about anyone and paid crazy rates. You could point them out for showing up their first day carrying a "learn ASP in 24 hrs" book.

Fortunately, the dot-com bust weeded them out. Most of these people went back to sell cars or whatever they were doing before while we had to clean out their messes.

And IT in general was much more slow-moving since then -- even companies with lots of technical staff couldn't (easily) find people to adapt to the crazy quilt of languages (and yes, paradigms) that burst onto the scene.

So if you had even the slightest idea how a website worked -- your were like a gift from high heaven, and treated as such.

These days -- especially in larger cities, near everyone has social contact with some of the programming persuasion; many have dabbled in some form of scripting, at least, themselves; and you can't walk into a coffeeshop or ride a subway train without being immersed in techspeak.

So things have changed quite a bit, and correspondingly, the bar has been raised.

I don't think this proves your point. Just hiring someone to do a job does not equal teaching them. Teaching means not only practice, but also well constructed feedback and sufficient time and space to learn, and to learn from ones mistakes.

Kludging an ASP application together after reading "learn ASP in 24 hrs" does teach something, but there is so much noise that you need expert guidance to interpret the results correctly and point into things that need improving.

It's hard to even describe what a change in productivity all this stuff was. Using an ORM to get data from a database and dumping it into html tables, and there was a browser that could format it all for display with nothing but some tags that were generated on the fly? Amazing!

I taught myself html, because there wasn't anyone to teach me. I taught myself server-side includes and cgi - no one to teach me. I taught myself Java. Etc. And I still do this today! If someone can teach you how to do something, it's already mainstream.

"If someone can teach you how to do something, it's already mainstream."

I don't think collaborative learning should be undervalued, though. There are several colleagues without whose example and input I would be a much worse programmer. Not in technical details, but harder to define things, like attitude that leads to success and how to make designs simpler.

'Mainstream' does not mean obsolete. Reading and writing and Roman alphabet have been mainstream for centuries, yet people utilize them with an amazing variance of productivity and value.

Then again, a person with whom I went to college is a recognized expert on Oracle performance. I find it keenly interesting that such a role even exists.

I look at startup-ey, Webby looking job postings and it's like the qualified people drew to several consecutive inside straights just to have the right buzzwords on their resume. And it's a different set of inside straights than it was six months ago. And it's different yet from firm to firm.

See there how easy it is when you don't know what you're talking about? :)

OTOH, I recently had an interview at a company who have quite a bit of groth and scaling problems right now (but probably not Silicon Valley level), and they still said: "We constantly have to learn new things, so the most important thing a candidate has to have is they have to enjoy learning new things".

AND: there are quite a lot of companies who are in the stable / profitable / predictable growth category and could afford to train/develop their people - But don't.

"Can you imagine if we train our employees and they leave?

Well, can you imagine if we don't train them and they stay?"

People would rather hire someone who has made mistakes on someone else's dime (another word for it is "experience").

http://devjourneyhomepage.azurewebsites.net/

Some people are not just hitting keys.

I've worked from outside the hull speed of several teams and gotten into places where being diplomatic about the sheer propensity to failure was a lot of what I ended up doing. And, frankly, I've just dropped the mic and walked off more than once, once I'd established that the team ultimately just didn't want to perform or had some horrifying external constraint that made the death march inevitable.

Say it with me: "I am powerless over the fact that I suck." At least you can work on the self loathing and make progress.

But seriously - get your ego out of it and life gets better. Let your ego free only when you are alone. You can't fix 'em all.

There are exceptions, where making it work is the hard part. Theranos is poised to fail because they can't make their medical test technology work. Cruise (YC 14) will fail if their autonomous driving doesn't stop crashing. Space-X lives or dies depending on how often their rockets blow up. Those companies need "the best".

Go down the current YC list.[1] Who has a hard problem?

Hard:

- 20n: A computational synthetic biology company

- Industrial Microbes: Upgrade natural gas to chemicals using synthetic biology

- Transcriptic: Access a fully automated cell and molecular biology laboratory, all from the comfort of your web browser

- Raven Tech: We are building the next generation OS (website sucks; all giant images, no info.)

Not hard to implement:

- Cleanly: Laundry & dry-cleaning delivered at the tap of a button

- GiveMeTap: Each bottle purchased gives a person in Africa clean drinking water for 5 years

- EquipmentShare: Rent high quality equipment at the lowest price, guaranteed

- Meadow: Buy medical cannabis delivered from local dispensaries

- Cinder: Notifications when food is done. All in a countertop electric grill.

If you're on the "not hard" list, you're probably better off hiring people who've done something similar but aren't superstars. Otherwise, you'll get overdesigned IT infrastructure, like Soylent. (Soylent does maybe two shopping cart transactions a minute, and boasts about how elaborate their systems are. They're bikeshedding. They're in the food business; IT is a support function.)

[1] http://yclist.com/

>This level of strictness always made me uncomfortable. I'm not going to lie, it starts with my own selfishness. I'm pretty sure I wouldn't get hired at big, famous companies with legendarily difficult technical interview processes because, you know, they only hire the best. I don't think I am one of the best. More like cranky, tenacious, and outspoken, to the point that I wake up most days not even wanting to work with myself.

Jeff Atwood has the self-security to say something like this publicly. It's really small-applause worthy in my book, since people will look for anything, especially anything unrelated to leadership, to tear a leader down[1]

As an aside, I think the political cost to admitting faults ties in roughly with the "Great Man Fallacy"[2] We're looking for an Iron Man to believe in, but when Tony Stark can't actually write a program to hack into a government mainframe in two hours, we get disappointed.

It reminds me very strongly of when Zuckerberg tried, for fun, to solve an engineering problem after two years of being the CEO of Facebook. He had a lot of trouble writing basic code; the engineers watching him struggle, who all thought Zuckerberg was this amazing super-genius who could do anything, ended up condescending him.[3]

[1] I do believe that plenty of so-called "leaders" are not actually good leaders. Rather that those people who grow to learn to be leaders, should not be detracted on certain details that are tangential to their business.

[2] https://en.wikipedia.org/wiki/Great_Man_theory

[3] There should be a specific term for "Gosh darn it, I may not have a billion dollars b-b-but at least I'm better at this thing in this particular way!"

It wasn't always a deal breaker, but it was very important that the team would be different after hiring someone. We hired quite a few non-CS grads, whether they came via a boot camp or were just self taught.

We ended up with a ragged team of misfits and it was awesome. I've never worked on a team that was so effective at challenging assumptions and biases and shipping features faster than anyone else. I'm convinced it wasn't through Herculean efforts by individuals, rather the product of clear communication and trust within the team.

Ive tried to explain why this worked. One observation: Very rarely did someone make implicit assumptions. Such assumptions are often wrong, but they happen because individuals are similar enough that extrapolation a partial understanding into a full one implicitly happens. We assume that since we got from A to B on the same path that the path from B to C is likely the same. On a team of misfits, you have to clearly communicate the entire sequence of events because everyone is on an entirely different page to start with. The result is that the final product is 100% on target, whereas normally there are a few deviations as the result of implicit assumptions.

"Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?" - from re:work

There's a great NYTimes article about it that looks at your hunch about the weirdness of the team members being the key to awesomeness. But Google ultimately realized that it wasn't so much about how different the backgrounds of the team members were, but was instead that that internal diversity could produce psychological safety.

http://www.nytimes.com/2016/02/28/magazine/what-google-learn...

Makes no sense to me. Why should the team need to be different? Why should the team need to be the same? This is Voodoo recruiting - some belief that a company has formed that really is meaningless but becomes an important part of the companies recruiting culture.

Will our team be different? Are they weird? Shake the chicken bones, dance around the fire and we'll get a good hiring decision.

The truth is, when it comes to building, maintaining, and supporting internal, line of business apps, management isn't even pretending to look for high end talent. They want predictability, reliability, and someone who will "fit".

I wonder how many people out there fit my profile. That is, they get excited by reading blog posts like these from some of the thought leaders, and desperately want to apply the thinking to their own workplaces, but then feel like we aren't really the target audience.

It may be counter-intuitive, but I find it easier to apply these types of articles to my non-programming work. My wife and I own a gym, and we need to hire personal trainers from time to time. There's a certifying body for that, so it's easy to know if someone is trivially "qualified" for the job. Are we trying to hire the top 1% of trainers in the country? No, we're at best a medium-sized location for our area. Largely what we look for when hiring is how they will fit in with the existing coaching staff, how they will fit in with our existing clientele, and how likely they are to attract new clientele (or bring with them).

And I was a developer but had to ask permission and make a case for every single program I wanted to install to help do my job, which isn't necessarily bad (there are understandable security concerns with downloaded software from the internet), except when Net Ops rates it a low priority and takes weeks to give you the permission. I eventually just stopped asking.

The atmosphere was also the most subdued environment I've ever been in. Most people not talking to or acknowledging each other unless their cubes were near, very few jokes, I almost got the feeling I'd get in trouble if I ever showed exuberance.

Not that I ever felt like it anyway. The lighting didn't help with that either, since we were in a room with very little natural light and soft florescent lighting that made it difficult for me to even stay awake there.

I did learn some new things there, and people were polite and friendly, so it wasn't all bad, but I'd never go back.

I know exactly what you mean! It is suffocating! Currently struggling with this right now. I can't stand it because it just feels so fake and phony. To me work is easier and more manageable when you are getting along with colleagues, not when it is overly formal, and corporate, etc.

Idk, that's just my perspective.

I don't even mind corporate necessarily, as long as it's relaxed. My current place people will talk about pretty much whatever, help each other out, tease each other about things, the boss will join us for lunch and talk about Star Wars and Deadpool, team leads are willing to admit that they can make mistakes, you feel like you can be more open and honest around your superiors, no one gasps or blinks an eye when you casually curse, etc.

And yet it's not quite no-holds-barred like a previous job that erupted into nerf gun battles and openly (but not seriously) insulting each other on an almost daily basis.

But I wonder who it is that sets the culture or tone of a workplace. Is it every employee in concert or more management / the team leads / bosses etc?

Why are they even called "consulting" firms? They are really just contracting agencies. And why are they so prevalent in the midwest and the insurance/banking/healthcare segments? Is it so that employers don't have to lay people off? Do they record the costs differently on their books versus full time employees? It just seems so obviously not in the interest of a company to use them with regards to culture, turnover, cost.

I've seen two reasons why mega insurance company inc brings in "consultants." One is the consultant is specialized in an area of tech that is completely outside of the companies expertise. I did some of this being in a niche area of enterprise security. While those contracts still suck they suck a little less because you are at least advising the company and getting them up to speed on something. The other type, and the most common type is the "staff augmentation". I've been on those projects too and its exactly how they seem. The company has some in house knowledge (say a manager of infrastructure and maybe one full time employee for that tech) but the rest is really about throwing bodies at a project. From the client's perspective its all about workforce flexibility and not having the expense of a full time employee on the books. Even at like 100/hr its cheaper I guess for them vs having a full time employee. Plus its not their "core business" although in 2016 I'd argue if you are running a company it's insane not to think of tech as part of your "core business."

Overall, between the unsteady work, travel, etc being an enterprise consultant sucks. Most people that I know go into it because the potential to make a bit more money vs a traditional job at mega insurance company inc is there and they don't like the idea of working for mega insurance company inc for years. However, I've been on contracts where the project is like two years long so you might as well be working for mega insurance company inc anyway.

For instance, you can be a "contractor" as a software engineer, where you sign an employment contract to work for 6 or 12 months at a client site, working through an employment agency. At the end of that term, either your contract is renewed or it is not and you're now unemployed.

Or, in the defense industry, you can work as a "contractor" where you're a full-time employee of some company (called a "defense contractor"). That company signs a contract with the government to do some work for them somehow, and you're assigned to do this work. Your work does not have a defined end date (like the 6-month contract you might get to work at some big commercial company), you're just a regular full-time employee, but you still have to track your time (so it can be billed to that government contract), and if something goes wrong with the contract (like it runs out of money), then you can suddenly, with little warning, be furloughed without any pay.

Of course, there's many other kinds of "contractors" too, like the guy you hire to replace your house's roof. And there's all the people who are full-time workers, but are given 1099 forms as classified as "independent contractors" so their employer doesn't have to pay FICA and unemployment insurance for them.

Now, as for "consultants", that usually seems to be pretty much what I described in the part about defense contracting: you're a regular W-2 employee of some corporation, but you're sent out to client sites to do work for them, though there's no fixed-term contract with the client usually.

I also objected to the idea that someone who directly generates revenue was being labeled a cost center. I left, as did my junior consultant, and shortly after the company failed to gain ongoing contracts at the very large financial services corporation they were trying to break in to.

My main problem with that job however, was that they recruited me as a greenfield .NET developer, but then had me analysing some 800 columns over dozens of tables looking for software errors that were causing incorrect results in the 401k accounts for which our client was the steward.

And I should mention that I've looked for other jobs in the area (trying to stay local because of family) - and almost no one pays as good as where I'm at. I'm making a bit above average according to Glassdoor (for my location).

But don't take my career advice. I only really know what not to do at this point.

I've worked in traditionally boring industries that treated programmers as resources to be allocated (healthcare, logistics). Sometimes it's still possible to make a difference. For example the logistics job I had, we were often the only development resources our clients had, so when they wanted to run a promotion or do something like that, our execution could literally make or break their business.

By using such automated tests, companies want to identify top talent by taking a shortcut and not investing any time on their side.

People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired.

Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't code a loop in the languages on their resumes.

I guess you can reach two conclusions from that:

1) A surprising number of applicants are totally misrepresenting their abilities – either through deceit or wild ignorance.

2) Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificial constraints, etc.

Certainly many of those applicants fall into the first bucket, but I'm betting a large portion fall into the second. So, you might reconsider whether the false negatives and highly unpleasant experience for many interviewees are worth the perceived value. Maybe there's a better way to get the same insights.

But then at the end of the interview I was given a coding challenge to do at home over the next few days. PHP and MySQL have good online documentation so I was able to knock it out quickly and I got the job. So, yes I misrepresented my skills, but I also knew I could live up to what I was claiming I could do.

Employer: First job out of school pay, requires four years of experience in our exact tech stack.

Candidate: Sure I'm willing to take first job out of school pay (BTW, just graduated in May). Yeah, totally have 4 years of experience, and what do you know, it covers exactly your tech stack!

Edit: exactly the point shawn-furyan is making.

https://news.ycombinator.com/reply?id=11224427&goto=item%3Fi...

I've worked with people who crashed and burned during the interview during nervousness and then went on to do okay afterwards.

I'm a believer in trying to make the interview process as close an analog of day to day work as possible and as low key as possible.

That means real, actually encountered problems (no fizzbuzz), and a progressive ramping up of the difficulty so that candidates with confidence problems can have a few easy problems to get over their anxiety with before getting into something meaty.

People that suspect they're in category (2) could come to an interview with some code samples. Personally, I'd even be OK if a (2) contacted me after the phone screen with some code samples and an explanation about what happened. Maybe we could set up another phone call and find another way to assess technical abilities.

Good development requires good communication and someone with the maturity to overcome that sort of problem will fit in well somewhere, maybe even on my team.

(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)

You're clearly getting a better caliber of candidate than those people are. That's great! And clearly, if that's the case, you should adjust accordingly. I think the lesson there is to tailor your process to the people you get.

I often use CSV parsing, where I specify a function that involves a simple string and I want some natural parsing of that in your favorite language. A bonus point for starting with the observation we should use a library, then do it yourself. From there I can pivot into discussing what the correct output data structure is (especially if the rows do not all have the same size or the same data types), converting text into better types, whether or not you understand unambiguously encoding text ("how can you include a comma in your field?", and I'm not worried about whether it's a "standard" answer), UTF8 and other text encoding issues, computational complexity a bit (and while small, it's a very practical, day-to-day bit) and questions of memory efficiency, the question of streaming if the dataset is too big. I can also easily pivot into outputting this CSV file into an HTML table in your favorite language, getting into HTML template issues, security issues that can arise from that, dumping the CSV into a database, and I'm probably even forgetting some of the pivots I've done. (And the point here is that I can choose, not that I ever cover all of these in one interview.) This question template scales from intern level ("can you get this string into an array of array of strings?") to senior engineer ("alas, the text encoding is varying from field to field, now what?") quite easily.

I've phone screened with this in a shared doc, too, since I can copy & paste in the problem pretty easily.

I took one of these recently, and botched one of the tests. Within 10 minutes after the timer was up, I had restarted my solution with a successful answer and was iterating on it.

The idea that the pressure is the same doesn't seem to apply to all applicants. Doing work under pressure within set times has been a strength of mine(ex. playing chess against higher rated players or when timer is low). I've noticed, however, that my skills fall apart during interviews. Once again, totally different contexts where you're being tested.

I am so tired of hearing the refrain that "we want to see how you work under pressure". Anybody who thinks that all pressure or stress is the same and that you can translate performance in one stressful situation into any and every other one has no business being near a hiring decision.

Nope, we aren't even going to ask you anything about that, or let you open up your iPad and show us, here's a whiteboard, start writing up a recursive permutation algorithm (only ever had to do this in programming interviews) because we want to prove you know how to do recursive stuff (and then tell us why you should almost never use recursive solutions in our apps), oh, and how about a red-black tree (algorithms class ran out of time to cover, unneeded since), or how about coding this specific sort (heap, merge, whatever) that you'd almost never use in actuality because there are tried and true libraries that are already more efficient than you'd ever be doing it from scratch?

Ugh. Fine, you can do your test, but please don't ignore my prior experience or act like you haven't even given a cursory glance at my resume, or even worse, make a dismissive comment when I talk about it during the interview. It really is insulting. And yet half the interviews I've been in have been like this.

I know to get away from those companies and never come back. If our values differ so much at the interview stage, it won't get any better a few months from now.

However, what I cannot condone is wasting the time of 100 applicants. It takes the employer ten minutes to "sort by best" and start calling down the list.

You are 100% right about their time investment. They are saying their time is more important than yours. It is another layer that muddies the process.

The utterly meaningless "top 1%" metric always makes me laugh. By definition then 99 of every 100 engineers don't make that cut, which means, again by definition, your team has very few if any of them, no matter what hiring practices you employ.

Plus I've found that very often management uses the "oh we hired the wrong people" as an easy cover for its own failings.

Instead of spending money on needlessly complicated hiring processes, with back and forth phone calls, panel Skype interviews, foolish interactive coding exams, multiple on-sites, etc., you can spend that money on severance.

Use a cheaper and more straightforward hiring process. Talk to people, dig into their background and preferred working style a little. If they appear to be competent, then just hire them. If they are not qualified for the job or they are not a cultural fit later, just fire them.

Because you will have explained to them that their first month on the job is still part of the overall fit assessment, and that you value the risk they are taking by offering them severance to re-engage in a job search if it turns out you made a mistake by hiring them, you are not doing a disservice to the new hire. You're merely letting both parties gather more evidence about goodness of fit.

This is money well spent, and for most companies, 6 months of salary is easily affordable for severance. In fact, an unwillingness to offer at least that much to each new hire would be a huge red flag.

Automattic does something interesting from what I've read. They have you work there as a trial for 1-2 months while keeping your full time job. This is probably pretty stressful but you get the ability to work with the candidate while not asking them to sacrifice their livelihood if things don't work out. Needless to say, it seems a lot of people don't get hired after the trial.

Maybe, maybe not. If they are already on the job market, then they probably don't mind looking for a job. If they feel that taking your job and getting fired still leaves them financially covered for an additional 6 months of searching, then they may not care too much.

If that company becomes known for this, then being "fired" from them won't really be a bad signal on your resume (if you even want to list it on your resume at all, depending on how long of a stint it is).

I don't think my idea is perfect. No hiring method is perfect. But I think that businesses should take a perspective that's fundamentally more about investing in getting to know and support someone as they are on-boarded, instead of Spanish Inquisitioning them and if they don't run away screaming then rationalizing that you've hired the best possible person (who, surprise, leaves after 18 months anyway because you didn't assess their fit or how their aptitudes really match up with job needs, you just whiteboard hazed them).

It probably depends on lots of factors, but I do like the consulting idea better.

This is already caused as much by companies as it is by candidates who are job hoppers. When I see a resume with short stints, it basically has no effect on me any more. If the person is good and I do my job to make them happy to stay, that's the best I can hope for. Pretending like either I can predict who the job hoppers are in advance, or that I should only hire people who magically have some intrinsic desire to work for me no matter how I treat them are both fantasies.

It's only that, if one is on that position, there won't be much downside to take your offer. But if one currently has a stable job, there is.

If I am very good at this assessment, then this may work. However, if I trust my skills to assess someone accurately, I am unlikely to have a complicated hiring process.

If I am a company owner (or manager!) who is not good at assessing people this way, then wouldn't substituting my process with this proposal make me spend a lot of money twice?

1) Paying salary to more people than open positions (Because I don't spend money on a hiring process and rely on my assessment skills, I may end up with many not-so-best-fits)

2) Severance package to let them go

I am not sure I believe this. First, if you are aware that you're not good at assessing it, then have someone else in your company do the assessment, or hire someone who can (possibly on the advice of your investors or something).

If you can't do either of those, I am afraid your business just isn't going to work out.

So, almost by definition, the person doing the assessment is reasonably good at it. For otherwise, you won't be around very long regardless.

Also, if you find that you're hiring a lot of people who seem good, but ultimately are fired, maybe look in the mirror. Maybe it is that your expectations are unrealistic, or maybe you expect people to adhere to "culture" standards that do not support human flourishing.

Unless the tech problem you need to solve involves lasering in on a fleetingly tiny population of candidates (most don't), then a sequence of looked-competent-but-needed-to-fire people is probably more a reflection on the company than the candidate stream. It's unlikely that all of them were elaborate fakers.

The costs of (1) should be low unless there's a fundamental problem with the company (in which case the costs of (1) are way cheaper than hiring a management consultant to help you not fix it).

(2) is a real cost, and yes, some companies can't afford it (so maybe they scale back to 3 months severance? Maybe they add continued health coverage. Maybe they let you pick a foosball table to keep) ... but it is just the cost of getting useful information about an employee, instead of the not-very-useful info that most hiring processes generate.

If it'll be good or bad depends on the actual risk balance you create between those two processes. But if the idea that the hyper strict hiring process does not help selecting great candidates, a moderate increase on nominal risk on the hiring process will actually improve your odds there, and you'll gain both ways.

If you don't have the skills for that assessment, how do you know your complicated hiring process works?

This is the entire problem with the inability to hire the "best"; It's dangerous to try and fail with lawsuits, unemployment, etc. I personally prefer to work for companies that don't hold on to poor employees and have quit companies that do the opposite. If you want to "hire the best" you have to "fire the worst". I accept the risk that comes with this of course (and many others may not).

The costs of sustaining a job search after being fired are a bit different than the costs of living while you have a reliable income stream. The grossing-up part is meant to reflect a nominal amount of money to cover those kinds of costs, not just a virtual continuation of the salary-less-taxes you'd been living on while employed.

In my experience, severance and sign on bonuses are often grossed up, as are payments made for relocation expenses.

But there's no reason to be hung up on that part. It's perfectly fine to just offer a regular severance benefit without grossing it up.

If I pay relocation expenses, I require receipts (at which point, it's non-taxable for most situations, so doesn't need grossing up). It's not that I disbelieve the new hire, but rather that I have to make it accountable in order to make it non-taxable.

If I pay cash comp (whether as a signing bonus, periodic bonus, commission, in contemplation of on-going employment, or as part of a termination agreement), they're wages in my book and I've never seen them grossed up (unless more of the character of the gift card or Christmas ham variety).

This might be a deal breaker for me if I was interviewing with someone. It's not that I care about the accountability part, it's more that a ton of relocation costs are unforeseen incidentals, or are private expenses (like first month's rent ... it's not your business what I choose to pay in rent), that should be covered by just paying cash to the new hire. Making them track down receipts for all of it might work out to be more costly, in terms of time lost, than just bearing the taxes, and certainly might involve requiring knowledge of expenses the employee may rightfully prefer to keep private.

Usually, I expect that the company will handle almost all aspects of relocation on their own (e.g. buying plane tickets and hotel rental for housing visit, calling up and hiring the moving company to pack and ship belongings). The part that would be paid as cash would be the cost of rental fees, deposit, and first month's rent, as well as some small amount for incidentals, which should be grossed up.

On the other stuff I guess we just disagree. I don't view sign-on bonus or severance pay as wage pay, even if they are pegged to wage level. For the other stuff, I agree, it's just part of regular income and the employee should bear the tax. But for sign on bonuses and severance, I think it's fair for the employer to bear the tax in light of the purposes of those payments.

Sign on bonuses are very different in this discussion though, since not everyone provides them and the amounts can vary a lot and for low amounts grossing up can matter significantly, while for larger amounts, employees are usually happy to bear the tax cost themselves. I'm not so worried about what an employer's policy is for these.

It would matter to me to negotiate a specific value paid for severance, though, rather than "6 months' salary" which will then have taxes taken out. If an employer was put off by this, it could be a problem, depending on all the other aspects of the job. One way to avoid this is that if secretly what I want is 6 months severance grossed up, then I'll try to negotiate 9 months severance, without mentioning the grossing up part. It's less off-putting to the counterparty, even if it would be nicer if I could just speak plainly.

I'm just speaking from my experience as a candidate in previous roles. I'm sure everyone has different experiences.

I (and I assume most hiring managers) have broad discretion on the amount of a signing bonus. For an engineer I want, I will never care about the difference between a $5K and a $10K signing bonus (or if we're talking about bonus in lieu of relo, the difference between $15K and $25K). It's a one-time expense to me, comes out of a different budget, and yet candidates seem to really value them seemingly out of proportion to the economic benefit.

Some firms offer > $30k signing bonuses (some more than double that) independently of relocation. It's rare, but not exceedingly rare.

In interviewing discussions in places like HN, there is enough pushback against this idea, which is a bit surprising to me. I thought a few hours work was reasonable when I was interviewing. But my point is that just this small bit of work seems already too big for many people, let alone working 10-20 hours a week moonlighting. It's cool that they pay for it, but that pay is pretty insignificant in the overall scheme of things. (Also, now you're not really interviewing, you're doing client work. Different relationship.)

When I have tried moonlighting in the past I found the stress incommensurate with the additional income. So I don't think I would do it as an interview, personally.

It sucks that companies take a risk during hiring. But I'm not really interested in making that my problem, as a job seeker.

If I have to spend two hours doing made-up homework for you before you will even talk to me, I expect that you will then spend an equivalent amount of effort proving to me that your company is somewhere that I would like to work. If you are not willing to invest that amount of time, the whole point of the interview is to reach an arrangement wherein I give you time and you give me money, so you could pay me for those 2 hours instead.

While I don't necessarily walk away from interviews that turn me off, every warning flag does add to the minimum offer amount I would be willing to accept from the employer. If you don't treat me with professional courtesy and respect during the interview, I am silently adding numbers in my head. If you act like I am the one wasting your time, I am probably adding $20000/year to my salary expectations.

I would much rather moonlight for a few hours every week, while getting paid to do actual work, than spend even one hour doing a stupid toy homework problem that ends up being a great signal for the employer and a very poor one for me. It isn't a matter of whether the pay is significant for me, but whether the employer is making and demonstrating an effort to make the process an exchange between equals rather than a superior-inferior relationship.

Would I want my kids to spend their careers being put through the wringer of multiple high-stakes interviews or be forced to moonlight in order to get jobs, something that gets progressively harder as people reach their thirties and gain extra responsibilities? No. Rather stay away from the field entirely and look for a more stable career.

I am a 2nd year CS student looking for a web-dev job to get experience and learn new stuff and every ad I see requires a couple of years in the industry + knowledge of a huge amount of frameworks. From my viewpoint, there is no real need for beginner devs. Companies are looking for really experienced AND cheap programmers.

I prefer at least having a phone interview upfront, which suggests that the company is willing to put in some effort.

That's my inbox. Not too appealing.

No. Now, okay, if you are doing absolutely fantastic, ground-breaking work, and I'd be rubbing elbows with industry leaders, and I am not otherwise in the market or trying to do eleventy seven other things simultaneously maybe I'll carve some time out for your project to prove myself worthy. But, you know, most jobs are jobs. If I play the interview game I can have a handful of job offers in a week (maybe not jobs I want to do, but that's a different story). Your team might be doing it right, but do I have optics into that? Probably not.

If everything I've done in my life is not enough to convince you (generic you, not draw_down you) that I can program and solve your pedestrian problem, then I don't view me as being the problem here.

So, if your take home thing is a 2 hour project, and is in lieu of a whiteboard grilling, then fine, sounds appealing to me. But only in context, because it suggests that you don't actually have any interest in measuring my skills, which go far beyond writing for loops. So, probably not a job for me, no harm, but you know, not appealing. Sell me, I'm not a supplicant. We'll figure out if we are a good match or not, no biggie.

The reality is that the take home things are usually just yet one more requirement, one more hurdle, yet more time out of my life. And you do a few, it goes into a black hole, no one even responds, or you get a one sentence email from HR telling you piss off in the nicest way possible, and the motivation to do another goes into the toilet.

Or the reverse happens. You do really well, they bring you in, throw some brain teaser programming problem on a whiteboard, your mind goes blorp, and suddenly everyone is being aggressive and scowling, or staring at their phones, instead of talking to you. Oy vey. I'm sure it happens, but I have never had take home go well, where I didn't end up feeling like a piece of meat being graded by the USDA.

And I never thought, once, "this is a really good measure of me - good performance on this reflects my on the job performance". Yes, I can write for loops, and fix bugs, but if that all the job is it must be really boring. What do you do? Why should I want to do it? How can I help? How can I grow? How can I help you grow? I have some ideas, are you interested in them? Let's build something!

Nope, just for loops, and then iterate over this structure that should be recursed over (or vice versa) on a white board.

I program. I get jobs done, every time. The code is maintainable. I try to up the bar, not maintain the status quo. I can talk to you about all of this, and if you have a medium IQ you can tell I am not bullshitting you. What more do you reasonably want?

8 weeks of contracting. Burn your vacation. Don't talk to your kids or wife, I'm trying to get rich here off your back. Work for me! Moonlight, and risk getting fired! Prove yourself worthy, because I have no judgement, and I'm terrified of making a decision! I'll string you along for months when you have all these other options.

Nah.

If I do one two hour project, and either get an offer letter or polite refusal in response, I'd do it in a heartbeat. But no one does that. They would be fools if they did.

So in order to work on an audition project, I'd have to be unemployed already.

But specifically if you were taking an interview rather than working a side job you could make the argument that the clause didn't apply in any case.

It all comes down to how much you pissed off your ex-employer by leaving, and how much they want revenge. No-one is going to gain anything from suing you after you've moved jobs.

But my current work contract has an anti-moonlighting clause that could also be a problem. It states that I can't have other demands on my time that would interfere with my day job. Now, I interpret that as meaning I can do side projects that have no deadline and just be luxuriously slow and lazy at making progress on them. But for an audition project I probably wouldn't be able to take it that slow.

If they have neither, then it's absolutely fair to ask them to do a small audition project first. Otherwise how can you be sure they're competent?

Keep in mind this idea doesn't exist just in recruitment. It's basically recruitment's version of what's called a "proof of concept", which is proof that the party that is pitching/asserting something (i.e. their skill) can actually deliver.

In my past of applying for jobs as a designer, I had companies that would ask for take home tests. I always refused and of course didn't get the job. Conversely, other companies I worked for offered freelance positions (probation) before settling onto full time which I thought was far more effective and fair method at evaluating me as a long term candidate.

If the project is a couple hours, then sure, I have no problem with it. When it's an entire real project for the company, you're just donating a week's work to someone in the hope of getting an offer letter.

While there's always some bias, I think it shifts quite a bit once you move from an artificial "interview environment" to a work environment.

Plus as has been said, since they candidates are working with the people they would be working if hired and that relationship doesn't work out, then maybe it's better to keep looking for someone else.

A word to the hiring managers out there, look to the future, cast the vision, and onboard people who want to go there with you.

When someone says "We Hire The Best", ask them to quantify precisely what "The Best" means. They can't. They weasel around and avoid answering. And that is because they can't define in a tangible way what "The Best" is. And if you can't define it then how do you know you found it?

Assuming you can define "The Best", an even bigger problem is working out a provable mechanism for measuring - in a quantifiable way - whether someone meets the criteria for being "The Best".

And the final absolute ripper problem is that the more you strive for "The Best", the less likely tou are to find anyone so you'll spend months interviewing and hiring no-one until the boss decides to pull the budget for that position because you didn't hire someone and anyway the commercial opportunity that validated the hire is now evaporated because we couldn't get the code written.

My term for this is "Voodoo Recruiting" in which there are rituals and dances and songs and meetings and processes and tests but it's all just a magic show because in the end the decision is not scientific, it's a magical outcome based just on personal likes and biases. In Voodoo Recruiting a company forms a set of beliefs about its recruiting processes and practices that become sacred and magical - such as "everyone has to do our test, and it actually tells us something meaningful about the candidates and we know how to interpret the results in a meaningful way".

Here's a few posts I wrote on the topic:

I sent one of the best developers I know to a job interview, he was rejected. http://fourlightyears.blogspot.com.au/2014/12/i-sent-one-of-...

Employers don't want great developers, they want what they want. http://fourlightyears.blogspot.com.au/2014/12/employers-dont...

Is your developer recruiting process just stroking your company ego? http://fourlightyears.blogspot.com.au/2014/12/is-your-poor-d...

And employers want what they think they want. I've been forced to (inadvertently) undermine the Great Developer too many places to think otherwise.

Lest ye think otherwise, I'm not that good. I'm just rigorous but I can switch modes and hack like a shameless... hacker.

My current company doesn't hire the best, but instead focuses on people who enjoy making impact in a small team, share the same vision and have a bit of an entrepreneur in them. We don't quiz people or give them tests. We just sit down with them and start talking tech. The results are really amazing and make for a great place to work because everyone feels like the project they work on is their baby.

There is no definition for "the best" beside a "well balanced human being"...

I have been researching this exact space for the past few months (www.developersjourney.info) and am now more and more convinced that once you reach a technical-threshold, in order to close onto "better-developers", you need to hunt for the 3-C-values: create, care and criticize. A balanced team should be a patchwork of cultures, backgrounds, desires and skills. But I think the drive toward those 3-Cs isn't optional...

Plug: This is very much an ongoing thoughts-process for me. If you have further input for my DevJourney Project and/or want to appear on my podcast on this subject, please contact me!

From the perspective of a subordinate doing hiring, raising the bar makes perfect sense. You don't want to get blamed for a risky hire going bad, so you optimize for making your choice defensible rather than good. Non-hiring is also risky - it's just risky in a way that damages the company rather than the person doing the hiring.

"What do you pay?"

"Market Rate."

"We hire only the best"

"What do you pay?"

"Between 10 and 30 million USD per year"

(I know, I know, it was a terrible joke.)

There are three attributes you need to select for to identify performing employees in intellectual fields.

  - General mental ability (Are they generally smart)

  - Work sample test (NOT HAZING! As close as possible to the actual work they'd be doing).

  - Integrity (The first two won't matter if the candidate is a sociopath).

I don't want to work in Sillicon Valley, even if the work is interesting. I live in Scandinavia and for me scandinavian countries are the best to live in the world.

You're used to that, and in a "measurable" way, it's semi-objectively true but it's not for everybody. I think it mainly was that I missed the sheer insanity of America where it is insane. It's something akin to codependency.

And given all that, I'd rather live in a Scandinavian country than SiVa.

Sweden for example has more billionaires per capita then the US. Norway have so much money in their oil-fund that they could pay every Norwegian 1 million NOK and still have money left. We're safe from any storms, earthquakes and basically all natural catastrophes. The most dangerous animal is pretty much the moose. Environmental issues will hit Scandinavian countries very late compared with the US.

1. The study about blind interviews in orchestras mentioned in the article. Think about it, most people in symphonic orchestras have a university education, and often with more years of education than your average engineer, they learned all about critical thinking etc... They are artists, whom are usually considered more open minded (ok debatable). But, they as a group, were able to acknowledge that they have strong biases to the point of trying (and eventually adopting) blind interviews. This, tells me that these people have a strong sense of the fact that they are aware that they biased, and able to admit it, and aware that it might influence their interview process, yet, the experiment showed that they were not able to see passed gender! This has seriously made me rethink about my beliefs about being conscious of my own biases.

2. I have worked for company A, which hired only the best (besides me I guess ;-) ) pretty much as described in the article, I have recommended people I had worked with previously and whom I knew were amazing, but they didn't get hired. I was seriously surprised, but you know the "it's better not to hire one of the best than err and make one bad hire". Ok.

3. I then worked for company B. I recommended somebody who was hired at company A. That person was not a friend, but somebody who passed all interviews with flying colours at company A. I worked with that person and they are extremely smart. Everybody at company A was amazed how smart that person was, even after seeing them fly though all the oh-so-though interviews. Working for close to a year with that person, and everybody was still positive about how smart and good that person was, so they aren't just good at interviewing. That person was turned down at company B.

PS: Yeah, maybe I just need to stop recommending people, I now realise I'm the common thread in people not getting hired in my story!

Now you've got to spend time optimizing your interviewing team. What if one guy just says yes to everything? He might as well not be there but he's still a weight in that decision. What about the opposite where he says No every time? When do you decide he is actually going to say No every time and not worth being part of that decision process?

The more people you put on this decision table, the lower the chances that any one candidate will make it through. But there's an opportunity cost of time/money to that, so you've got another thing to balance.

I think it would be really, really hard for one person to simultaneously impress 10 people beyond a doubt just because of how many people have to reach consensus. And can you imagine the stress of knowing one dude with a nitpicky attitude (that none of the others know about yet) could sink your chances?

I've worked with people who were A players, hired into a new firm, and quickly spun out. Other people were C players, found a new job, and quickly became A players.

If you're a company who's great at training people, you can hire for energy and eagerness to learn. If you expect people to know everything on day one, hire for experience. The same people who succeed in one of those companies will fail in the other. A big part of hiring is knowing yourself and knowing what makes people successful.

"The most significant shift we’ve made is requiring every final candidate to work with us for three to eight weeks on a contract basis. Candidates do real tasks alongside the people they would actually be working with if they had the job. They can work at night or on weekends, so they don’t have to leave their current jobs; most spend 10 to 20 hours a week working with Automattic, although that’s flexible. (Some people take a week’s vacation in order to focus on the tryout, which is another viable option.) The goal is not to have them finish a product or do a set amount of work; it’s to allow us to quickly and efficiently assess whether this would be a mutually beneficial relationship."

The people who will go through this either a) really want to work at your particular company (in which case, great, but unlikely), or b) are desperate for a job because they've been turned down several times.

And... Interviews are awful. Seeing how someone work is even better. This is one reason why employee referrals are so important, and audition or temp-projects a good second-best method.

In the end I think it's a Fools Game though - someone who is best in one environment may not be that great for the next. Managing people post-hire is something that can't be avoided.