Hiring Is Broken – My interview experience in the tech industry (opens in new tab)

Hiring isn't broken, dude. You just don't interview well, and you seem antagonistic even to the idea that your cachet and skills, insofar as they exist, aren't useful to the market. That's a problem -- for you.

Interviews exist because employers need a way to quantify and qualify your ability. Typical computer science problems are a (flawed, but concrete) way of doing that. No reasonable interviewer expects you to recollect breadth-first search flawlessly, on demand, onto a whiteboard. But they do expect you to be able to reason from a problem statement to something approximating a solution. That's fundamentally what programmers do. You should have the chops to think in this way, and you should be eager to try. Emoting "what the fuck?!" and claiming you can't, or won't, because you're not a recent graduate is an excuse and a cop-out.

A few popular open-source projects don't necessarily speak to your talent as a programmer. A 960 day GitHub streak is trivia, not a signal of anything useful. (If anything, it marks you as a target for burnout!) A few Hackathon wins and a couple hundred GH stars are the artifacts of a successful hobbyist, not a proxy for professional ability, or a gateway to employment.

It took me a year to find a new job. I got rejected from on-sites 8 or 9 times, a few other rejections before that. I've been through everything the OP has and more. I was once forgotten in an interview room while my interviewer played foosball and then went home. I've managed to pass all rounds with "positive feedback" only to get rejected three days later. I've swam through rivers of aerated bullshit to find a new job and it sucked - but I never once believed that I was a bad engineer. Hate the game all you want (and I really do hate it), but you have no choice other than to play it or have an extremely strong network.

I didn't even want to go to the interview which landed me my new job. In my previous phone screen they were looking to hire a single person.The perfect fit. Probably not me - what the hell do I know about video players? And it's one of those interviews where they'll boot you to the curb if you do poorly in the first half. Whatever, I'll go anyway. And as luck would have it, I didn't get booted. I did damn well. And in my final phone screen with the CTO, I got asked how to find the Nth last spot from the end of a linked list.

I really wasn't good at interviewing for a long time. And from the outset, I didn't know everything I needed to get the job I wanted. It was consistent studying and a buy-in to the bullshit that interviewing is that landed me a new job.

There's selectivity, and there's courtesy and respect. Companies are entitled to be as selective as they like, and if those are the kinds of tests that yield the people they want to hire then good for them. On the other hand courtesy and respect would demand that you're clear with the candidate about your expectations and requirements, that you don't waste their time, that you respect the investment of time by communicating after the interview to let them know how they did, and perhaps even that you let them know up front what areas you expect to cover. Otherwise, as was noted in an earlier comment, it really is just a lottery to see if you happen to be fresh on whatever thing they happen to ask you.

There is another side to this which leads me to ask why companies feel they have to be so defensive? My wife is a registered nurse on a cardiac critical care ward. If she doesn't know what she's doing actual people can actually die, something that is a rare outcome for even the worst software developer. Nevertheless, she has a BS, and work experience, and when she interviews they don't require her to stand up at a whiteboard and prove she's a nurse all over again. They respect her experience, and the questions are more about process, work habits, personality, etc. In the software development world we appear to have zero respect for experience, and I wonder why that is? Have employers been burned so often? Or is this more of a geek cred gauntlet thing?

I'm torn.

On the one hand: the interview processes this post describes are hilariously broken. Stand up at a whiteboard and implement breadth-first search from memory! You know, like no programmer at their desk staring at their editor ever does. I think "that's the one where you use a queue, right?" is a fully valid and complete answer to that dumb question.

I also think you're within your rights to demand that your interviewer implement Kruskal's minimum cost spanning tree from memory at the same whiteboard before you have to do BFS. That's an extremely simple and important graph theory algorithm that nobody memorizes either.

These interviews are nerd status rituals. Really good candidates know this and game them. If you know anyone like this, ask them for stories. I've heard some great ones. But obviously, this isn't a good way to select software developers.

On the other hand...

The idea that "front-end developers" shouldn't need to be able to implement a BFS (at all) bothers me a lot. If you're a software developer, you should grok basic conceptual computer science. You should be able to work with a graph. If you're doing web work, you're working with graphs all day whether you grok that or not!

I've been doing front-end work for the past month, and I've had to do more low-level profiling and performance work here than in the previous 4 years of low-level systems work.

Technical interviews became 10x easier when I realized that most companies aren't necessarily looking for the right answer as much as they are trying to look into your mind.

As a self taught programmer things like binary search trees and linked lists are a foreign concepts (especially as a self taught frontend developer). When I am asked to solve a problem in a way I've never encountered before, people are pretty open to explaining how the problem works.

I don't get frustrated if a problem seems arbitrary or obscure because that's typically not the point. The point is, if you're going to join my team, how do you approach a difficult problem; do you get upset? do you clam up? I don't want someone like that on my team. I'd say most people would prefer a teammate who is resourceful rather than one who only wants to solve problems they're comfortable solving.

The OP is describing the new grad tech hiring process. It looks like an exam because it's for hiring people straight out of school.

For experienced people, it's not what you know, it's who you know. You tell your connected friend that you're looking for a job, he tells you who's hiring and gives you a recommendation.

You still have an interview, but it's no longer adversarial, it's a formality, it's friendly, it's just a screen to make sure you're not faking it. One of the people on the other side of the table has seen your work before, so is on your side. So when you get those stupid questions, it's a joke that you all laugh at. You handwave at it, and it's enough.

There are obviously problems with the above process -- it leads to hiring friends rather than the "best" candidate, but I'm surprised that we've moved so far away from it that the obviously well-connected OP is having so much trouble.

I interviewed with Netflix for a front-end JavaScript position a few years ago. I had two technical phone screens. One with the engineering manager and another with a senior engineer on their team.

Those went smoothly so I was asked to fly out to Los Gatos, CA.

On-site I was supposed to talk first with the senior engineer I had already interviewed with over the phone. He was out sick so they changed at the last minute.

In walks a guy in a fedora with full tattoo sleeves. He glances at my resume and laughs saying he hasn't looked at it at all and really knows nothing about me.

He proceeds to ask me detailed questions about Node.js. I told him that I was very clear with them on the phone, that I've played around with Node, but I hadn't used it to any serious degree (at that point in my career).

He continued with the Node.js questions for a while, some of which I knew because they were the same as the browser (console) some of which I wasn't familiar with at the time (EventEmitter).

He then asked me some simple JavaScript, Backbone, CSS questions all of which were easy. He then asked me a C# question and I knew that too.

We shook hands and after he left, the engineering manager came back in and I was basically escorted out. He said I was good but that I wasn't what they were looking for.

I've had some retarded interview experiences but that one took the cake.

I hired Sahat as an intern three years ago while he was an undergrad. It was one of the best hiring decisions I have ever made. He was productive immediately and our (small) team felt the loss when he went back to school. This guy is good and gets stuff done, ask people who have worked with him.

I wish Sahat had reached out to more of his network before responding to random recruiters. Tech interviews as Sahat experienced them are broken, but tech hiring is slightly less broken especially when you leverage your network.

Google and similar companies aren't for everyone. They're looking for people on top of their game and willing to go the extra mile.

> To be fair, I already knew about Google’s idiotic interview process that is optimized for hiring book-smart academic candidates who know their algorithms and data structures cold, so my expectations were rather low to begin with. I also did not get much sleep that day, so my problem solving skills weren’t at its peak.

The author is already annoyed, antagonistic, and planning for failure. He knew what he was up against, but didn't adequately prepare to succeed by studying. And didn't sleep the night before.

And none of the reasons for not succeeding are the author's fault, in his mind.

You can claim that the screening process is dumb, and in some ways you're right. But at the same time, this process does select to some extent at least against the people who make excuses instead of bringing their A-game when it counts.

If you want a job at a place like this, you can do it: commit yourself to a plan of action for success that involves real work and preparation. Wanting to change the industry practice of the top tier firms is interesting and all. But if you want to get in, work and preparation will reap more rewards than complaining.

What frustrates me about this is not even these questions, specifically, but which companies seem to use them.

If Google wants to ask crazy algorithm questions, that's at least sort-of reasonable. There's at least a hypothetical chance your work will involve that knowledge.

But I've interviewed at companies who's entire tech stack is a simple CRUD web app, or a simple RESTful mobile app, who's so-called "big data" is less than a few gigabytes in total, and they still want to throw algorithms and brain teasers at me. These same companies then post some inane blog post about the "developer shortage" and how "we can't find talented people".

If these companies could actually find the candidate they're testing for -- this hypothetical hyper-intelligent developer who had a IBM-Watson-like memory of every CS algorithm and it's application in every language, that person would get completely bored working there and quit in 3 months or so. These companies could never retain the type of person their own hiring process exclusively selects for

---

Hiring doesn't need to get fixed, companies need to get honest about what they are and what they actually want. To restate this in 1-10 scale : Many companies delude themselves into believing they are a 9 or 10, and are trying exclusively to hire 10's (and hypothetical 11's that don't exist).

When in reality, most companies are in the 4 to 6 range, they only need people in the 4 to 6 range, but are rejecting 7 and 8s type candidates, because they aren't a 10.

This process itself isn't broken, so much as the businesses holding the power in the process are delusional about...everything (what they are, what they need, who could provide that, etc).

After reading author's post I've a feeling that its not the programming skills that the author has issues with, but instead the attitude, stress durability, expectations to the world around him. True, hiring can be broken, it often is, but as with everything, the persistence usually allows us to find the proper company with proper hiring process. He's getting frustrated pretty quickly, complains when is asked to perform math-heavy coding, complains when is asked to do proper front end coding, so on and so forth - this type of people are not very pleasant to work with and very often their feelings, unability to adapt to difficult situations and attitude is very visible, putting off the recruiters. That is, of course, my personal feeling after reading that piece and I might be completely wrong.

Honestly, I believe the industry is cannibalizing it self, and this sort of practices is pushing out more and more creative and capable people. When I have to make a choice of whether to practice my algorithms or work on my open source project, is when things are going to start blowing up. This industry is built by people with passion and dedication, some of the most powerful and defining projects were built by individuals who sacrificed their spare time to build something useful, now they will sacrifice that time to practice... Algos? C'mon!!! I think our industry has passed the initial honey moon period, when crazy and beautiful solutions crystalized in garages and basements all across the county and the world, and we're headed for a bumpy landing were big corps control open source and the crazies that made them possible are pushed out. This is not sustainable on the long run, and pretty soon were going to be regulated to oblivion. Bye bye innovation.

Ah I interviewed with some of these companies a few months ago and had the same experience. Unlike you though I didn’t find this frustating but rather hilarious.

For example, Lifion interviewers who wanted me to write fibonacci couldn’t tell me what the sequence definition was, they ‘taught’ me that C++ classes default visibility was protected or that REST was a protocol, they didn’t like when I said they should use a relational database if mongodb lack of multi documents atomicity was such a problem. That was so mind blowing that I started writing down on my phone all the stuff they said.

I might write an article about all that too actually.

When I was an undergrad, my team won the Facebook Hackathon at our university in 2011, so they gave each of us job interviews. None of us got an offer, but the irony is that one of my other team members went on to work at Instagram, which was then acquired by Facebook less than a year later. I'm pretty sure that was about the most expensive way FB could have hired him.

During my interview, the interviewer asked me where I was getting my CS degree from, and I replied that I wasn't getting a CS degree — my major was chemical engineering. He was silent for a few seconds, so I'm pretty sure that wasn't the answer he was expecting.

What I remember about the interview process is that I was asked to implement some kind of odd search/sort algorithm. I remember thinking "why would I have this memorized off the top of my head when I could easily Google the best algorithm suited for the task?"

In high school, I don't think there was ever a chemistry or math exam that I didn't get a perfect score on, but I would also take much longer to finish than the other students. I frequently ran over the allotted class time and worked well into the lunch period (luckily, I had nice teachers who allowed me to do this). In college, I remember perplexing the physics professor, because I got 70s-80s on the quizzes throughout the semester, then I got a 113 on the final exam. I told him the only difference was that I was given 20 minutes for the quizzes, whereas I had 3 hours to complete the final exam. The extra time made all the difference.

So I wonder if a lot of companies are missing out when they look for 1) people who have a lot of simplistic CS algorithms memorized and 2) people who can work quickly on the spot. I may not be able to write a FizzBubbleRedBlackSort algorithm on a whiteboard in ten minutes, but give me a week and I'll have you a parallelized implementation of quantum monte carlo that runs on a hundred thousand cores.

Yeah, it's broken.

Google studied their own interview process, according to Lazlo Bock, examining tens of thousands of hiring decisions. The study concluded that their process was no better than random chance at finding good candidates. They continue with that process nevertheless.

I have a rich network of Silicon Valley connections, built over 29 years of working for Valley companies. What I hear time and again is that many highly-qualified and productive people have a terrible time finding work.

Simultaneously, Silicon Valley companies testify before congress and complain to the press that there is a serious shortage of technical hires.

If companies can't find enough good candidates, and good candidates can't find enough offers, and one of the most prosperous companies in technology, with the most famously rigorous hiring process in the industry says that their own process is bullshit, then yeah, I'd say that hiring is broken.

Of course, if you happen to be prospering, then it doesn't look broken to you. You're prospering, after all.

And of course, if some joker comes along and says that the process that hired you is broken and gives results no better than random chance, of course you aren't likely to agree. After all, if it was luck that gave you your prosperity, then luck could just as easily take it away again.

The story we like to tell is that the technical interview screens out bad candidates. It's just a story, though. Google's research says it doesn't.

Is that such a big surprise, though? How many times in my three decades in software has a product launch depended on someone being able to solve a brain teaser in front of a critical stranger? Zero. How many times has a company's success depended on someone writing the right code on a whiteboard? Zero. How many times has the bottom line depended on someone coming up with the right algorithm or data structure off the top of their head in a conversation? Zero.

Technical interviews, if they measure anything at all, measure things that don't have much to do with technical jobs. So it shouldn't be a big surprise that they don't do better than chance at predicting someone's performance.

If technical interviews don't work, why do we still use them? Why does Google still use a hiring process that its own research says is bullshit?

Maybe it's because we don't have anything better.

I think it's because on some level we realize that we don't actually know how to distinguish good candidates from bad ones, but we don't want to admit it to ourselves. We want to think that we can pick the right candidate, because it can be so costly if we don't.

So we ritualize the process. We rely on a bullshit hazing ritual. We wave a dead chicken over it and tell ourselves that we are screening out bad candidates and hiring only the best.

Only we're not. If we were, then maybe companies would still have a hard time finding enough candidates, or maybe good candidates would still have a hard time finding jobs, but not both at the same time. And the company with the most 'rigorous' hiring process in the industry wouldn't be concluding that their own process is nonsense.

Yeah. It's broken.

I interviewed at 17 companies before finding one that fit me. It's more of a persistence game than anything, and I began to realize that a lot of companies were just testing the waters, only willing to hire someone if they really blew them away (obviously this is hard to do under interview circumstances).

Once I found a company that actually _needed_ me, the experience became a positive one - they went out of my way to make me feel comfortable.

I wish there were a way for candidates to pre-screen companies, rather than the other way around. It's a waste of time on both parties if the company isn't actually in need of a new hire, but just dabbling in the option pool.

One possible reason is that the brony thing on his github might be a legit turnoff for employers. It's silly, but it's possible. The two people I talk to more than anyone else in this world are bronies (to the extent of going to conventions and whatnot) and have similar issues. Hell, I still don't understand it and find myself irrationally judging them for it, and that's even after daily exposure to it.

Tokenadult isn't around to chime in here, so I'll take his place today. Hunter and Schmit did a meta-study of 70 years of research on hiring criteria. [1]

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).

This alone will get you > 65% hit rate. [1] http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...

Hell one of these companies should hire me to do data driven recruiting.

Is it even just hiring?

Every employer I've worked for has made the experience farcical. If not at the start, then over time. You interview for one job, and eventually end up doing something else.

A full time career that doesn't pay enough to buy a home. And they say software developers are overpaid.

I think the end-game for me is to just go camping with a laptop or something. I'll code for fun, rather than trying to meet this 'market demand' which provides people with studio apartments, temporarily, in exchange for ~all of their productive hours.

The purposes of these interviews is not (usually) to see if you know the answer. It's to see how you problem solve.

If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown another question that they hope you don't know.

When interviewing, the thing I want to see most is how someone works through a problem: can they solve from first principles? do they go via trial and error? do they ask for a computer to google things up/a book?

Picking raw CS problems is an easy option, as its something that you should be able to solve, and it means I don't have to require you to know Angular/React/Flavour of the month (new tools are easy to teach the right candidate).

You're not going to immediately know the answer to everything that comes up in your job; so evaluating how you solve the unfamiliar is very important.

Fancy moving to the UK? :)

Seriously there's a job with your name on it if you're interested.

When I interview candidates I sit with them for half an hour or so to get to know them. Then I give them purposely broken, poorly written piece of code which I tell them to pull apart. This proves incredibly effective as even if they miss some of the more obvious errors I can at least point them in that area and then see if they can see the problem on their own. There are about 100 different things to talk about so it really gives me an idea of the level they are at, and also the type of programmer they are; passionate, lazy, smart, meticulous, inexperienced, confident etc. Then if I feel they are worth a second interview, I get them back to sit with me and my team for the day to see how they fit in with the team. Then all being well I offer the job.

Considering that it's our fellow programmers doing the interviewing, I'd say we're failing ourselves here. I'd wager that in almost all cases, those doing interviews have had zero training on effectively recruiting anyone (let alone other developers). An effective interview requires preparation - and I bet the majority of developers do this right between saying "fuck, have they arrived already?" and starting the interview. Is it any wonder it falls back to the standard approach of "Google does it, it must be good" or a dick swinging contest trying to prove how amazing your team is, because "fuck yeah, we all write search algos every fucking day - it's why our product is amazing."

Front-end lead here, building large desktop apps for my company's internal use.

I've never had a web-app that failed due to performance. I can't recall any that ever have, except Facebooks' attempt to use HTML on mobile.

UI performance has little to do with algorithms, and only occasionally requires opening the profiler to hit 60fps with some tweaks to bone-headed nested loops. Or maybe reconsider your use of Angular!

Front-end apps fail because long-lived mutable state is a powerful engine of complexity, and algorithms do not solve complexity. I am constantly telling my team (CS back-enders prepare yourself!) to ignore performance concerns. O-whatever has zero-impact on delivering simple, extensible, bug-free web apps that please its users.

But admittedly, crafting good software isn't as objectively clear as implementing a mathematical function that makes your server code perform. The proliferation of front-end frameworks and compile-to-js languages indicates that writing FE software that works remains a far greater challenge than writing FE software that hums.

To that point, maintaining a popular github repo for a library or app that demonstrates your ability to write, maintain, and extend FE software is still the best sign that you know what you're doing, and that you like what you're doing. Conversely, knowing a lot of algorithms as a FE candidate tells me nothing about whether your first PR will be your last.

On a happy note, Netflix didn't ask me a single question regarding algorithms! Their interview's focus on OOP made sense, even if it didn't fit with my own focus on ClojureScript and FP.

I think it's important when interviewing candidates that he/she can demonstrate fundamental CS knowledge. In any software project, you may be working out very complicated features, and CS knowledge is often the common language for conveying complex and subtle ideas.

That said, it's perverse that there's a cottage industry around software engineering interview training on both sides of the table for the crazy questions that are being asked. No one wants this, but sadly, once you're in the door at these places that do these sorts of interviews, the motivation to affect change approaches zero.

There are some companies that have tried to make this a fairer assessment though, e.g. Foursquare http://engineering.foursquare.com/2016/04/04/improving-our-e.... Putting this sort of effort into an interview process is time-consuming, but if the software industry is going to make its interview practices assess candidates more fairly, it's going to take effort.

The problem with interviews I am having (I am about to graduate and have not got a job yet) is that the whole hiring process is too one-dimensional. Some companies only care about algorithmic coding competition skills that you can only achieve via competing in some sites like TopCoder, CodeChef and some other companies only care about how many years of experiences you have - does not matter what you have learned from experiences, it is just how many years that count.

Coding contest skills are very unfair to senior developers because they are out of school long time and do not have the time or motivation to engage in coding competition. And this also creates different incentive models. I have seen people who flunked very elementary CS courses (OS, networking etc.) to spend more time coding competition to get hired in big companies. This is really weird because they have to learn these things to become a real developer and they are gonna learn these things in company's time which they should know already. That being said, I personally think, problems like maze solving and inverting binary tree are fair questions. These are not exotic DP problems, these are just simple problems.

OTOH, the whole years of experience thing is unfair for new developers who do not have the experience but smart enough to learn and outperform many developers with experience who just memorized APIs over years of experience. There must be a healthy compromise between these two types of hiring.

The examples that always come up of "stupid interview questions" in this kind of rant: Implement a breadth first search, or reverse a binary tree, or write FizzBuzz. Are these really such difficult things to whip up, off the top of your head? Is it really that unreasonable to want to hire someone who can do so?

Yes, if you need such a thing and it's not immediately obvious how to do it, off to StackOverflow you go to find some example code, but these are basic "do you understand fundamental data structure / control flow" type questions. It's not like they're asking you to implement a theorem prover or something.

The author claiming he'll never need to do a BFS, and thus does not need to know it is kind of funny to read. You should never be proud of your ignorance.

Oh, you think you're a front-end dev and will never need to do anything else? What happened to striving for growth (personal and professional)? Why not learn how to write a BFS instead of writing a rant about your pride in not knowing it? Are you really just proud of doing your one thing, doing it well, and have no interest in ever branching out? If so, it is not surprise nobody will hire you (who needs a single-use tool?). If not, then also no surprise as you've shown a complete lack of desire to learn (who needs an inflexible employee?).

I am further sorry to tell you that your github history is irrelevant. I've seen _my_ code on github under 10 names. None of them mine. I'd never trust anyone's github profile - no reason to believe they wrote the code, they did it themselves, and how many attemtps of guess-and-check they needed (or not). You know what I do trust? Your ability to prove your "skills", in person, under realistic pressure, on demand, and on a schedule. You know, by solving a problem perhaps a bit out of your comfort zone. Maybe a simple maze?

Why don't companies who ask these kinds of CS questions in interviews just put in the job ad something along the lines of "if you pass the initial filter we'll invite you for an interview. We'll grill you on some data structures & algorithms & give you some whiteboard challenges".

Which is absolutely OK. If that's what you're going to do - regardless whether it's sensible or not - then potential candidates can either ignore your ad, and save everyone's time, or apply to you knowing what to expect. If a large enough number of desirable companies do this a candidate might decide to brush up on CS 101 and interview practice.

That's honest and courteous, instead of ambushing candidates in the interview stage - when they've taken a precious vacation day and taken the time flying out to see you. And it saves you time - any candidate you get should know what to expect.

Don't get hired then. Just freelance and be done with it.

I as a developer can't understand why anyone skilled wants to be employed.

I was employed for about 7 years and now I'm a freelancer. I don't have to discuss with my customers that I want to work from home, I just do it. I get more money than before, I spend less for health insurance and taxes, I start working when I want and not when some manager wants me in the office. And job security seems a bit odd considering that everyone is searching for devs and the demand seems to increase every year.

And the best thing is, I don't need to do dumb interviews anymore. When I freelance people just ask me for solutions and give me money for them. When I look for employment for doing exact the same stuff I do as a freelancer, suddenly they want to know the weirdest stuff and ask me to do dumb tests.

I'm sorry, but breadth-first-search is a simple and fundamental algorithm and straightforward to write if you understand the concept and have decent coding skills. You're just visiting a level of the tree at a time: stick each level in a list, iterate over it, and append the next level's nodes to the next list. There's no trick to it.

Not being able to do write a basic BFS algorithm suggests a) you didn't do any interview prep and b) whatever you've been working on hasn't involved any non-trivial algorithms.

It doesn't mean you're a bad programmer but if you can't answer a basic BFS algorithms question I wouldn't trust you to touch code with any non-trivial algorithms in it.

I recently wrote a post on designing better tech interview questions. [1] But one thing i never see interviewees do is outright ask, "Wait, what does this question actually tell you about me?" I find myself asking it in nearly every interview i go to.

If you ask and your interviewer gets glassy-eyed or gives you the laughably generic "it shows how well you think algorithmically" you know that you are being interviewed by someone who has little clue what they are doing. It is a great way, from your side of the table, to understand if your time is being wasted right out of the gate.

1: http://blog.benroux.me/4-steps-to-making-your-interview-suck...

While I do agree with the OP that the tech hiring process "might" be broken, I noticed a pattern in his interviews: it seems to me like a self-fulfilling prophecy. From the get go, he already considered the interviewers as enemies and went in with a mindset that they are out to get him. That wouldn't probably help calm those nervous nerves, neither would it show your prospective coworkers that you are someone they would enjoy working with(which is a fundamental part of the interview, I believe).

I have actually noticed that most tech companies(at least they ones I've had to deal with, namely Facebook, Google, Amazon, and Microsoft) are doing all they can to take the guess work out of interviews with training sessions, resources, etc...

All the OP needs is to change his attitude from cynical to optimistic and I promise, things will change for him.

Also, BFS (and DFS) are as basic as you can get with algorithms. Either of them is not longer than 10 lines of codes; just remember that BFS uses a Queue and DFS a Stack...

I am a VP at a medium size company and I do plenty of interviews. I usually talk about what people are interested in and then ask one question:

"You are in front of PC/Mac/Mobile screen, type www.cnn.com into browser, and press enter. A fraction of a second images show up on the screen... How? What happened? Tell me all you can from key press interrupts to underwater fiber cables".

This question never failed me. It always shows how deep does one go in their computer science adventures.

What worries me a lot is the proliferation of these puzzle solving interview sites which waste candidate's time and prove almost nothing except that the candidate can solve high school olympiad problems.

Many companies require this as a first step, before even talking to the candidate.

Apart from the problems being totally unlike what your future work will be like, the time constraint proves .. what ? That a candidate can "think fast" ?

What about code quality, architecture, design patterns, build systems, concurrency, etc ?

Here's what I've decided to do when they reply with a coding interview task:

I charge my clients 50 EUR an hour. If you want me to spend 3 hours on a coding interview as proof that I can code, then I'll expect you to pay me 150 EUR as proof that you can pay.

I think this is fair. Otherwise, I'm going to knock on someone else's door, were I can talk programming with an actual person, share "war stories" and get excited about building something cool together.

"I could feel my frustration rise as I am struggling to come up with a solution on a whiteboard....yep, I am definitely not going to pass this interview. I ran out of time before coming up with a working solution."

Instead of standing there with nothing its better to be straight up and just say "No idea mate" and then name reasons why that is but how you'd solve it in a normal situation. It is a lot about human psychology, showing them that they want/need you, not vice versa.

Sometimes all it takes is balls and a good amount of "I don't give a fuck" attitude.

I wouldn't let anyone treat me like Sahat got treated.

> From this moment on, I would rather be unemployed and homeless rather than do another tech interview. Enough is enough.

God, happened to me this year, highlights:

    - "Do you like to wear a tie to work?"  
      (perhaps because I'm 40-ish)
    - "Tell us about your worst boss."  
      (from three guys with frowns and folded arms)
    - "Do/talk through this sorting problem on the whiteboard/webpage..." 
      (With people watching, clock ticking over $100k in suitcase, gun to head)

I gave up as well, am now writing a book on software, unsure it will sell.

Yep, the interview process is pretty broken. It took me 5 Google phone screens before I got invited to an on-site (although one of those phone screens had the technical phone interview waived due to the team's familiarity with my skills, but I still got rejected amusingly) - the only reason I made it was because I failed & learned from each of the previous phone screens enough to pass.

This is an absolutely awful way to interview. However, the author should learn some patience & attack the problem. You deal with the cards you're given - it took me 2 1/2 years of applying to jobs before I lucked into get a job in the tech industry after grad school, and lots of wtfs in many interviews after I entered tech. Learning how to take it on the chin and keep going is an important skill for success - he could learn something from sales in that respect.

As someone hiring right now, I feel your pain and, while I hope I compare favorably to the interviews your describe, I wish I was better.

My one piece of advice: read Nick Corcodilos's Reinventing the Interview:

http://www.amazon.com/Ask-Headhunter-Reinventing-Interview-W...

The basic idea is demonstrate you can provide value to the company, and you have the skills to do the job. If you're stuck with a disinterested interviewer asking irrelevant questions, make it about the job you'll do and your ability to succeed in the job. He has concrete suggestions. I say, if they're not open to that and it is clearly not working, tell them you it is not going to work out and stop the interview rather than enduring another miserable experience.

Its ironic that I would have done better in these hackerrank type challenges straight out of university, even though the code I write now is way better.

This story serves as an interesting counterpoint to Haseeb Qureshi's interview experience (https://news.ycombinator.com/item?id=11552780). I think some discussion about how he and Sahat's experiences contrast would be useful.

I almost want to joke that it's Sahat should have done a bootcamp, since that seems to have been Haseeb's advantage; he learned everything about CS very recently and freshly, in an environment where he would be absorbing material that's tech interview fodder. Coupled with Haseeb's intelligence and quickness in absorbing said material, he must have impressed his interviewers. Whereas, an experienced developer like Sahat is worse off- ironically, by not being new to the field, he lacked the advantage of seeing like a fast learner. It's almost like ageism but specific to how long one has been programming.

And on the subject of hacker bootcamps- I've heard a lot of them not only teach programming, but how to optimize one's interviewing skills. If bootcamp graduates are doing well because of that, does that mean there should be bootcamps for experienced devs who want to switch jobs, just so they can ace interview questions? And is that really what this industry has come to? Memorizing algorithms and strategies for passing data structure logic puzzles in cram schools just to get a job?

I've had my fair share of bad interviews too. Just recently I was interviewing for a full stack position with a company that tried to get me to recite "what happens when I type google.com into my browser". I asked them where they had gotten idea from and showed them this: https://github.com/alex/what-happens-when. They decided ask me another question soon after.

Sometimes the questions aren't even related to data structures or algorithms. I'm OK with those because at least you can somewhat prepare for them. I've once had an interviewer ask me obscure questions about Netscape 6 (this was 2016 btw).

> I much prefer “homework” projects, even if they involve me working “for free”, because I feel like they ask for actual programming skills rather than the “guess the algorithm” lottery of phone screens and whiteboard coding.

Me too but when you're interviewing with 3+ companies at the same time while working at your current job, it gets difficult. There was one time where I had spend my Saturday afternoon maybe 6-8 hours completing their "homework" project. I got a call back from them a few days later for a follow up interview and they flat out didn't even bother to ask about the project I had completed for them. What was the point?

Tech interviews suck.

Why bother applying at those super fancy companies. There are loads of medium-sized shops with a friendly work atmosphere and reasonable hiring practices.

Vimeo, Facebook, Google, ... they hire elitists and those design the interviews. And honestly I doubt their work is at the end of the day more efficient then that of most other "regular" companies.

I feel like it's a little weird that one of the author's big examples of a difficult algorithmic question is breadth-first search. While I agree it's not something that's very likely to come up much in real work (especially for a front-end dev!), it's also... not actually hard? You check the current node for your truth condition, you add its children to a queue, you pop the queue and do the same thing for that node. If the queue is empty, you return false.

Experiment : hire 10% of candidates without conducting any interviews. Use Machine Learning to quantify internal or external candidates' code quality. Use that model to score candidates' GitHub. Hire them.

Well, OK, throw in a sociability / not-a-psycho score using LinkedIn or twitter or whatever.

I'd outsource this to gild.com who seem to know what they're doing.

Methinks management will be surprised at how well these 10% do despite not passing the usual "What happens when I flip all the color bits in a red-black tree" or whatever shibboleth is being used these days. Admit it : most work, even at Google, doesn't involve knowing how self-balancing trees work. On the other hand, getting things done matters everywhere.

The good news is there are plenty of shops that don't ask these types of questions in interviews. Most of the companies you mention have a technical reputation as being elite, and as you say they can hire or interview as they please.

Everybody can't work for Google, and there may be some that could work for Google if they were better at interviewing the way Google does (and these other companies do).

The author harbors some hostility towards the recruiters that have landed him these interviews. I'm a recruiter, and I too harbor some hostility towards recruiters when they behave badly.

The recruiters in all of these situations seem to have done the author a service, and there are no explanations of the recruiters behaving badly (other than the going silent/no feedback scenario).

Telling recruiters to "F* OFF" is just blaming the messenger. They didn't design the interviews, they didn't conduct the technical interviews being complained about, and they didn't make the decision not to hire. They simply facilitated the process and relayed the message.

Blame recruiters when they behave badly. Lying about salary ranges, 'bait and switch' jobs, etc. Don't blame them when they do their jobs, just because you didn't like the outcome.

So there's really no hope for the self taught without formal algorithm training. I can start from an idea, build an entire site from the ground up, including hardware, OS, programming environments, mysql/oracle/rethinkdb/mongodb/arangodb + all their query languages, backend nodejs/php/python code, all custom frontend css/stylus/vuejs/js/responsive, domain / dns / hosts, email servers, deployment and administer the entire stack. But I guarantee I'd fail every single one of these tests.

I guess I'll go back to building my own projects, because none of this sounds enjoyable.

I have been on the other side of the table and I'm sure I came off as indifferent. The problem is, I have been thrown into the interview as an interviewer multiple times with about 1 hour notice when I have many other things to focus on.

It is definitely a broken process in many companies.

I sympathise. I have not agreed to tech problems in interviews for years. In my experience I get more job offers for more $ if I refuse to do them rather than answering problems either rightly or wrongly. Either makes no difference. I have even turned offers down because of the stupidity of the interviewers. Stop doing silly interview questions professionals should be above that.

Yes, hiring is ridiculous at big tech companies that everybody wants to work for. Asking a ton of CS questions is justified if the job is actually CS heavy, but most front end jobs aren't. The dentist analogy is spot on.

My recommendation is to apply to smaller, lesser known companies. Much much less bullshit and time wasting. There are enough jobs out there that you don't have to deal with this bullshit.

Time spent on learning extraneous knowledge solely for the purpose of passing interviews for jobs that don't actually utilize such knowledge is a massive waste of society's resources.

"Programming trivia" style interviews are the bane of our profession. They serve primarily to allow the people doing the interview to feel clever and superior when they discover that the candidate can't implement a red-black tree from memory on a whiteboard. They tell you little about whether the person is a good candidate.

There is a school of thought, baffling to me, that suggests that knowledge is mere rote memorization of facts, so the best way to test people in anything is to check their memorization of the relevant material. This interviewing style derives from that school of thought.

This is, of course, utter bullshit, especially given that the details of the topics chosen are almost entirely irrelevant to the actual job of a software engineer. A working programmer who re-implements a red-black tree from scratch is almost always doing it wrong. Someone has already built that and debugged it and optimized it, and you should be using that implementation, not redoing it from scratch yourself. The "programming trivia" interview style is like interviewing an architect by handing them some iron ore and asking them to smelt high grade steel out of it. That's not what architects do. They buy premade steel smelted by experts, then use it to build other things.

The solution? Real-world programming as an interview. Either give them a toy problem, or pay them to do some minor bit of actual work on your system for a day or two, if that is feasible. Then get out of their way. Give them a laptop and the Internet, leave them alone for a few hours, and see what they can do.

Afterwards, do a code review. Then discuss their programming and engineering philosophy.

Why don't people do this? It takes a lot longer, and requires the interviewer to think more. It's much less cognitive load for the interviewer to memorize some obscure data structures and ask candidates to recite their construction.

And of course we then will have to hear the sad stories of companies saying "they can't find talent"

And that's not even going into the salary/H1B issue, the problem is much deeper than that.

- I was an advocate at first, but take home exercises are pretty much useless. Because they at best won't fail you. And of course you could have written a new sorting algorithm that works on O(n) but what you'll get back is a complaint about coding style

- Having a github might be nice but as the article says it seems to be also in the category "won't fail you". It seems to barely matter

- And of course companies like Google ignore everything and make a test out of your interview, fail/pass grade, period.

People are probably missing an empathy component or working outside of the "SV tech clique" where if you don't code for 12h per day and doesn't know all libraries and algorithms by heart you're not even considered

WOW. I thought I was in a weak spot by being self-taught and scattered.

So just who the hell is passing these inquisitions? What's really necessary?

I'm currently considering jobs directions too and finally have a name for what I'm experiencing. "career interview fatigue", it's probably similar to whatever performing elephants in circuses experience right before they snap.

I think it comes from a decade of experience of being asked to jump through increasingly ridiculous hoop sizes over time, and complicity cooperating with this nonsense system in an otherwise analytical logical calling.

In jobs or sales or relationships (which is ultimately what this is: interpersonal relationship dynamics), the best outcomes are effortless. If there's too much friction, it's probably not going to work out. The best job/deal/friend/partner will simply fall into your lap, and you'll wonder how it can be so simple.

The challenge is finding these. Careful filtering can help, but it seems to be largely a numbers game.

This becomes increasingly difficult, as more companies are infected with these faddish processes every day.

And there's a cost, of time and money and contentment. To help reduce this, consider spending increasingly less time on opportunities you deem unlikely to work out, based on past experience.

I often prequalify jobs--sometimes companies respond, sometimes not, but that also provides me with useful information.

Most people are commenting about the technical nature of the interviewers, but the communication between company and applicant is often broken as well. It's the difference between not getting an offer and then (a) hating the company or (b) supporting it and recommending it to other potential applicants. Companies underestimate these effects.

Once you bring someone in for an interview, you owe them a phone call, with email as a backup.

It's unclear what sort of prep work the author put into each interview, but interviewing is nothing more than a sales pitch and a "game" to be played.

I'm 100% self taught, having never set foot in a CS classroom, and this is what I do for every interview process: 1. Find everything you can about company and their interview style; 2. skim over Algorithms in a Nutshell; 3. Take an hour to refresh Big O notation; 4. Read up on "best practices" for the technologies the company uses.

Finally, after the interview always follow up -- say something nice and memorable, be humble and express interest in learning their technology stack _before_ your first day on the job.

I find it takes 2-3 company's before I hit my "interviewing stride".

Didn't care to read after first rant about hiring process. It just seems like you are not a fit for Google. People always try to find company which "culture" fits them, but it also works the other way around, even if you wish to work for Google, maybe just for the salary or other benefits, if you are poor fit for the company culture then you are a net loss.

>>"The first round started with introductions, followed by a coding exercise — write a maze solving algorithm. What the fuck?! Seriously?...I am not a recent college graduate anymore"

I wonder if just writing a brute-force maze solver, and then explaining that you are aware better solutions exist...but that you didn't have any memorized, would have sufficed.

TLDR: Doesn't know computer science fundamentals, doesn't get hired in a role that requires computer science fundamentals.

Is this Hacker News or Script-Kiddie News?

You have to go with the flow. Unfortunately.

They treat you like hobo that came to their kingdom begging for a cookie.

They are the kings and queens and you are nothing just a pathetic beggar.

It's really exhausting and painful to go through it again and again especially when you know that most of the companies are just wannabe hipsters or the same corporate hellholes.

They pretend they are on the same level as Rob Pike and alike but what most of the people do is they write shitty code, shitty UI and shitty everything.

Google is definitely worse they cannot really make a compelling product that would DIRECTLY earn them money .It's all about ADS.

I disagree.

A typical adult has the spare time to study 3-5 algorithms prior to an upcoming interview, and the algorithm question lottery has room for several hundred.

This means that the practice of trying to stump them with algorithm questions provides a strong benefit to hiring managers: can this candidate read my mind even before I've decided what it is I will ask of him?

They're selecting for psychic powers and do-what-I-want-ness. Which is what most management in the United States (elsewhere probably, but I'm an uncultured redneck type... wouldn't know) values.

Completely agree with all of your points. I think I'd do horrible in most on the spot interviews, but give me an ide with intellisense and a book of advanced algorithms and I'll complete what ever you want. I understand the most common algorithms but I don't use them hardly ever in all the work I have done over the past 10 years. Am I implementing a big data search engine, no. So why would I know all the specifics to that, but given an hour or two of reading I'd be up to speed and be on top of things.

I have a job at a startup as a software engineer. I waded through dozens of interviews like Sahat's. "Do whiteboard problems," "solve this benign algorithm problem."

The two job offers I did end up getting went something like this:

1. "Show me a project you worked on. Tell us about it. Tell us about future features. Okay, implement one of those features right now."

2. approaching me after an event I spoke at "Hey, are you by chance looking for a job? We'd love to have you with us." at "interview" "tell me about your past experience, some projects you worked on, and how you learn new things."

I feel like both of these "interviews" tackle two very important things as a software engineer--can you use what you currently know to add a new feature? And if you don't currently know it, do you know how to find it out?

I didn't know a lick about React, SVG, animation, databases, lodash, es6, or trees, before I started working at my current job. But because they were able to see how quickly I could learn new things, I started as a contractor (to "test the waters" so to speak) and impressed them by proving them right.

And I think that's exactly what companies should strive for--hiring people who can pick things up quickly. Of course, consulting firms may not have this luxury, because they need to deliver now now now, but for SaaS companies, I don't see why this method wouldn't work.

You're looking in the wrong companies. Based on the things you're solving you'd be good for smaller companies or even the startup world. These usually look at your experience more, and pay more attention to what you've done. Bigger companies don't care about you, or what you did as much. They want to test you right there. Bottom line, a smaller organization will value your open source work more, if that is what you're looking for.

I think this boils down to just knowing what you are. Are you a computer scientist or a programmer? These are two very different things - as much as many people like to think they are not. To be a good (or very good) general software programmer you need about as much math and physics as someone who has completed 9th grade.

Some areas of programming will require specialized math knowledge of course i.e. basic linear algebra for general game programming, and various algorithms depending on your specialty. But in any programming field you will almost never be expected to research new algorithms from scratch - this is the job of scientists - and your job is just to implement those, and know enough to choose the right one for the job.

This is just a long winded way of saying, I think a lot of HR departments need to clear up for themselves what it is they are trying to recruit. If they want people researching, you are going to need the algorithm/math/physics chops inside and out, but if you are building 98% of the not so super theoretically revolutionary products out there in the world, you really just want to hire people who know how to pick the right tool and then use it i.e. code with it. And to know how to pick the right tool, you do not need a PHD in CS.

I've been doing a little interviewing at my company, hiring engineers. I tend to avoid the pop quiz questions because I, having been asked them in interviews before, can't imagine they're that valuable, and, considering our field has plenty of introverts and autism spectrum-types, it's probably not representative of their abilities in a real work environment.

HOWEVER. One candidate had a PhD and was very agreeable, had lots of experience in other companies in our field. So I skipped the programming test, since I figured a PhD with loads of experience must be able to code...

A colleague of mine saw the candidate as they were leaving and ducked. I asked them why. "Well, I personally lead to them getting fired a few jobs ago." Turns out Colleague worked very closely with Candidate and Candidate can't code worth shit: Colleague ended up personally redoing a ton of Candidate's botched work, Boss noticed Colleague working way late for no good reason, and after several chances, had to let Candidate go since they couldn't do their job.

Anyway, I've come to the conclusion that I need to ask in-depth technical problems, but I'll phrase it like this: "I'd like you to describe an A* path-finding algorithm the best way you can (pseudocode, diagrams, assembly, whatever). I'm not looking for a 'correct' answer, or syntax or class diagrams. I want to watch how you solve problems of which you only have a vague knowledge. If you'd like to refer to some resource, feel free to ask, and I'll tell you if I know, or I'll find out."

I suspect this is the point of the technical question, but it's hard to tell what interviewers actually want.

I agree with the most part of it, some of it doesn't seem quite right. For instance, where author mentions he is a front-end developer and doesn't need to deal with algorithms, and data structures -- it only gives a (false?) sense that he doesn't want to deal with the problems. I agree with the "take-home problems and submit solutions", idea to assess the candidate (or an alternative solution could be -- work at their own office, like how you would if you were an employee on the given problem) This basically strips away the unnecessary pressure.

Now, about the real problem -- It has to be solved by both the parties, for instance, somewhere in the middle of the article the author mentions he was asked to write the BFS algorithm. In this particular scenario, the interviewers should NOT expect the candidate to actually remember the algorithm and write the solution right away like a bot (or a human who has used it very recently) would. Here the interviewers can be more humble, more human. They should check whether the candidate holds the problem solving skills which is what is essential and NOT whether the candidate has a computer-memory. Here, they could explain what BFS is, how it works, and then give the candidate some time to come up with a solution.

Again, interviewers shouldn't expect a correct solution for the problem, it's the attitude of the candidate towards the problem, and the way he/she thinks about it -- that should be enough to give some idea about the skills he/she holds for problem solving.

The idea is simple. Don't just drop some Dothraki (or some language the candidate does not know) algorithm names, and ask what it is instead, skip the names, explain the problem in simple words and ask for solutions.

OP, it sounds like you work by looking up and remember solutions, and assume everyone does the same. You're saying the questions are BS because you haven't seen the solution in a long time (or ever):

> it has been a long time

> I vaguely remember

> this would have been a trivial problem to solve from memory, but that’s besides the point

> Do I remember how to implement those algorithms? No

> I am not a recent college graduate anymore who has breadth-first search memorized

> I haven’t implemented BFS in years, there is no way I can come up with a solution right here and now

> If, and when [...] I will go look it up

I normally wouldn't point it out since it sounds really condescending, but after https://news.ycombinator.com/item?id=11554894 I don't know what to assume anymore:

They don't want you to remember or memorize solutions, they want you to be able to implement it given just an informally explained approach (which you may also be responsible for coming up with).

Converting ideas into code without having seen the code before is a realistic, desirable and not at all uncommon skill.

I don't think it's unreasonable to expect a candidate to be able to write code given the description "These objects have a value and links to similar objects. We want to find a certain value by first looking at all our nearest neighbors, then at their nearest neighbors, then at theirs, and so forth.", even if they had never heard of graph theory or BFS, or seen code for it before.

I don't think the specific interview questions are all that y fair. BFS, shortest path, etc, are building blocks of computer science and familiarity with them is a good signal someone has a thorough education in algorithms. If you're hiring an engineer and he's not familiar with the Bernoulli equation, or a lawyer who isn't familiar with Marbury v. Madison, that'd give you pause too.

The real issue is why is a front end developer expected to have an education in algorithms? Part of the problem is that programmers doing the interviewing like to show off, instead of focusing on the requirements of the position. I remember the first time I interviewed someone. His resume said he knew C++, so I asked him about the intricacies of templates. That revealed that his knowledge of C++, like that of many people in the early 2000s, extended only to "C with classes." Gave a negative evaluation. But in retrospect, all our code was C with classes so what did it matter? I was really just showing off that I had read TCPPPL.

One of the fundamental principles that's coming out of a century of hiring research is you have to evaluate candidates on the same basis - any other approach is an invitation to bias and subjective decisions.

If you evaluate two similar candidates, candidate A on their github and candidate B on their performance on Hackerrank then it's incredibly hard to fairly compare those two candidates without adding subjective bias.

In practice what happens is the company goes "oh well the person with a github clearly has more initiative". But is initiative part of your evaluation process ? - have you ensured you've fairly allowed all candidates to demonstrate it, or have you ended up evaluating candidates unfairly on totally different metrics.

If you're hiring you can vastly improve your hiring process by doing two things: (1) Adopting a standardized structured interview where questions map directly to your needs and (2) using a work sample test (getting candidates to do a small piece of work that resembles real-world work as closely as possible).

Not sure if it's accurate, but it seems like these inane coding challenges are more common on the coasts. The only time I've experienced any of them was at an interview with Amazon (for an Email Deliverability Manager role, of all things...).

I've been tested on code, but it's never been these inane tidbits everyone went through getting their CompSci degree. Anecdotal, I know.

I think it's perfectly reasonable for interviewers to ask scientific and "non-practical" questions.

1. If they just went by open-source contribution and prior experience, the pool of "qualified" people would be immense. You need some way to narrow them down, and it's fine for a company to pick their way, be it CS questions or how handsome someone is (joking) or how easy they are to talk to and interact with (charisma). It's not just about pushing code--lots of people can do that.

2. Questions like these are not totally unnecessary. Even though you won't be dealing with CS questions regularly at work, they still show that you put the effort in to learn them, and that you can think critically and on the spot to solve problems.

I don't think hiring is as broken as people make it out to be. Just learn the science and study up on it a lot before... I even bought a book that is a summary of common CS problems that interviewers ask. It's not a big deal for me to just read it up for a couple hours a day for a couple days before my interview. Good companies are looking for people who are ready to put a lot more effort in than just brushing up on Dijkstra's algorithm.

Note: One of the greatest things I learned from 5 years of undergraduate school has nothing to do with coding or science. It's the ability to just shut up and get some work done. Even if it's hard, unnecessary, or it's difficult to understand the motivation behind being assigned it, it's a useful ability (for growing professionally) to just crank out some work when you're told to do so. Many times, it takes doing the work to understand why you should do the work. Then that lightbulb turns on and you realize how much you've benefited from learning Dijkstra's algorithm and applying it to something; it's pleasant.

I sympathize with the author. I have been through this as well. I'm still going through this, really.

I've been rejected many times. And every time, I come away from the process annoyed and disappointed, but certain that I would have been useful to them had they hired me. I research companies thoroughly before going into interviews, and don't waste time interviewing for positions that I don't think I'd be interested in / qualified for.

I also have decent GitHub activity, handful of open source projects that demonstrate my abilities. When I started my new job search I assumed that this mattered, but in my experience it really doesn't. I still get asked extremely basic questions that I'd hoped my GitHub would eliminate. In some instances the company that rejected me had some open source projects, and it made me feel better about myself to see their poor code quality.

Nevertheless, I am also starting to have doubts about the industry. I've wasted a lot of time on take-home challenges, introductions, technical phone screens, on-site interviews, etc. to be rejected without explanation. As an introvert, it's all very exhausting. Why should I, as a computer programmer, have to be an amazing socialite that my colleagues would like to vape & play air hockey with? I just want to work on interesting problems. I'm not stimulated by extravagant team lunches or interrupting meetings to play with the company dog. I'm not stimulated by fancy windows and games and snacks and toys. I'm happy to have technical discussions all day long, but I really don't want to work in a frat house.

I feel like there's a lot of pressure from the industry to be someone I'm not. Also, it seems like the Joel Spolsky idea about only hiring exceptional programmers (at the expense of risking a merely /good/ hire) has seriously penetrated the industry, making the system highly risk-averse in terms of hiring. I feel like no amount of prior job experience or open source work will make a difference. Every time I interview, it's a clean slate, and if I don't nail _everything_ it's a certain no-hire. Even if I did well in prior interviews with the company, they simply won't risk it. I would really like to know what the reasoning is, but they never provide feedback.

I will say that I've been hardened by the experience. I'm better at pitching myself, making appointments, talking to people in a structured way, preparation. I think if any startup founders lack experience as sales(wo)men, there's plenty of opportunity to dial-in your skills by pretending to be a job candidate strictly for practice.

Whenever I interview someone, I try to follow these principles:

1) Simulate a real work environment. This means a dev machine with full access to the web. One thing I'm looking for is how good the candidate is a finding information they don't know.

2) Customize the questions for the job at hand. A software tools dev is a very different position a firmware dev. I wouldn't, for instance, expect a firmware dev to know much about regular expressions. And I wouldn't expect someone interviewing for a scripting job to know much about alignment on ARM.

3) Test your questions on coworkers and friends. You need to get a baseline. Is there enough time to answer the question? Are people coming up with wide spectrum of solutions, or do you keep seeing the same response over an over? Are there parts of the problem that people find unclear?

... I really wish companies would be more transparent about their candidate rejection reasons. From this day on, I was even more disappointed — both with myself and tech hiring process — rejection, rejection, rejection. It honestly feels as if I am a complete failure and an unhirable[sic] candidate...

Companies simply cannot give a reason for rejection. It is a "fake/legitimate" legal liability HR says exists opening the door to discrimination lawsuits.

My advice is never interview at a company at which you do not have some prior professional introduction (network, friend, foaf, etc). These people will be able to give you the real feedback on why you were or were not hired.

Some recruiters with longstanding relationships at the companies they are placing at will also be able to find out, but may or may not be honest with you.

4 years have passed and nothing has changed http://www.unlimitednovelty.com/2011/12/can-you-solve-this-p...

Wow! As a person that interviewed other people for front-end developers, here in Berlin, I would say that I will probably offend half of the candidates if I ask them to code on a whiteboard.

Not to mention that I would feel offended if I'm asked by a hiring team to solve complex logic task while visiting an office for a first time.

Usually what I do as an interviewer is to select a bunch of questions out of [1] github frontend developer interview questions and make a productive conversation, by asking for opinion on different ways of writing front-end code.

1 : https://github.com/h5bp/Front-end-Developer-Interview-Questi...

“Never memorize something that you can look up.” - Albert Einstein

This is why I refuse to participate in tech industry job interviews. Thus far, I've managed to get enough work in a freelance capacity mostly through referrals and my personal network to avoid having to go down that route. I think it's the height of hypocrisy that tech companies complain that they can't find enough good candidates and how hard hiring is, yet the absurd processes they use actually turn off some good candidates who just aren't interested in playing the game.

Kudos to the author for being so forthcoming about his experience. Maybe if enough programmers start making a big stink about this problem, something will actually get done about it.

Interview questions are not pass or fail. They are just there to gauge you're ability to problem solve and function under pressure. I hated interviewing, but disliked conducting an interview even more. The problem is people act so antagonistic when an interviewer challenges their ability, but realistically your character is whats really under scrutiny.

Having a great resume and stellar github is why you get the call back, an inability to conduct yourself in a professional manner is why you didn't get the offer. Especially in newyork, a medium post from an employee could affect stock prices, you can't have a lose cannon working for you.

With some helpful nudges you should be able to do a simple BFS. Still, not a very fruitful interview question, IMO.

What's bugging me about the author is that he dismisses everything that doesn't have direct relevance to the position.

Projects get finished and you still want to work there. Projects get reshuffled and you're placed elsewhere. Your role in the organization changes.

If an interviewee showed such a myopic view of his future work I wouldn't be thrilled. He basically says "let me show you that I'm a one-trick pony", while the interviewer tries to ascertain his capabilities across several potential jobs.

I truly appreciate the OP's honest, detailed accounts of recent interview experiences. Thanks for writing this.

I think you may benefit from a change of narrative. Evidence from your interviews (specifically the Vimeo interview) suggests that your potential employers have a mixed perception about your skills and experience. I certainly believe you're capable of being a productive engineer that a company will value, but it still may take some searching to find the right fit. One of the benefits of leaning a little more on your network than using recruiter requests is that it increases the probability of finding the right job.

Life is a video game. Well really a series of minigames. Some of the minigames aren’t as fun as others, but you have to pass them to move on. Right now you’re on the ‘get hired as a developer’ minigame. You beat that minigame by memorizing things like Algorithms and Data Structures.

Yes it’s stupid. Yes it’s not something you’ll ever actually do on the job. No it’s not a real indicator of your actual programming ability. But it’s what you have to do to beat this part of the game and move on.

And, yes it sucks, but it’s not THAT hard in the grand scheme of thing. Basically what’s happening is someone is saying “we’d like to hire you for a job that pays significantly above the national average, is safe, low stress and generally pretty easy when you think about it. All we ask in return is that you brush up on some things that you have already had to learn anyway.”

I would also argue that it’s at least partially about seeing how driven you are. Everyone knows that you’re probably going to get asked Algorithm and DS questions in an interview. There are literally several very popular books entirely dedicated to that fact. So you can either have a self-centered, egotistical, “I don’t think I should have to know this and I know better than everyone else so I am not going to learn it” attitude, or an open, eager “I really want this job and I know they will probably ask me some of these kinds of questions, so if I have to take a week to brush up on these concepts I am more than willing to do so attitude.” Which do you think makes for a more attractive potential employee?

"...almost as if they were looking for a reason not to hire me"

Essentially that's what is going on. Easier to exercise your biases when the default is "don't hire."

When I interview people I usually ask what they have done and let them explain to me why some things were done in a certain way, what alternatives they had thought about and so on. When I can have an intelligent conversation the candidate usually is a go, otherwise not. I just want to know whether they can think straight or just repeat memorized stuff.

If you know your stuff you usually can separate bullshitters from good people.

This has worked pretty well for me so far.

Couple of years ago one of London companies did it well IMHO, after little chat about few technical things (which looked more like Friday night chat in a pub with colleagues than anything else) they said there's computer in the corner, here's a problem (it was to use macfuse to implement in-memory virtual filesystem with basic file ops) - I was left with computer, with internet connection, I could browse whatever I wanted, nobody was looking over my shoulder etc. Even though macfuse was a bit crap at that time (kernel would sometimes panic so i had to reboot machine few times) and I never used macfuse before - it still felt like there was no pressure. After that quick chat about written code and next meeting was with CEO about the salary etc, all smooth.

Since then I think one of the best approaches is to come up with work related problem, leave person to solve it with computer, keyboard, internet etc. with no time limit (if candidate can't solve the problem, they will give up and just say it after 2h or so). Quick chat about the code afterwards will tell you in 1 minute if person understands it and didn't copy pasted solution etc.

Kind of tangential, but I'm wondering: if he is unable to implement BFS in a reasonable time, how was he able to implement Math.pow over the phone? Would this have been a Math.pow that didn't account for fractional exponents?

I spent a few minutes trying to recall how it would work and I couldn't, and it seems like a fully working Math.pow is a little complex for a gatekeeper question – or maybe I just forgot the trick.

I dunno... it's frustrating, but really, you can learn some valuable stuff during those few hours. I have had some interviews that certainly haven't been positive, but they have been instructive or rewarding in some way. Not necessarily even relating to code. It teaches you something about them, the industry, and more importantly, about yourself.

>If you are going to test my knowledge, at least ask relevant questions for the role.

Even for a front-end developer, I think that algorithms matter, because developers have to understand what they do.

And the OP's solution in O(N2), as well as the other one with hash maps, seem quite bad (it can be done trivially in O(Nlog(N), and optimized to reach O(N))

I think that the kind of interview you get tells a lot about the person that is interviewing you. I have been interviewed by professors and PhDs, and I have worked with them too, and never they expected anyone to remember some specific knowledge from several years ago. Hell, I spent more than 5 years working on Kalman filters and I don't think I could code the algorithm without having a look at wikipedia (I always forget the formula for the 'K' matrix). I remember taking Udacity's course about robotics and when Sebastian Thrunn appeared on the video and said he always forgot the formula too a tear dropped from my eye. If someone makes you that kind of specific technical questions my guess is that they lack enough qualification to better assess you, I don't care if they work in Google, Facebook or whatever.

I don't want to pick on any individual response, but the amount of close-minded - and arrogant - replies on this thread is pretty sad. The OP has many valid points. I've interviewed hundreds of candidates - some well, some not so well - and been interviewed many times. I've had four offers in my last five interviews, so I'm not bitter about the process, but I do think most interview processes are far more amateurish than the people they're trying to weed out.

Interviewing should be about finding a fit between a worker and work that needs to be done. The best predictor of that is past success doing similar work. It's not about imitating Google's process, and except in increasingly rare situations, it has very little to do with academic computer science.

And there is never a need to treat anyone rudely. So don't.

I'd rather solve programming puzzles all day long, but every time I do an interview I get asked incredibly specific questions about a particular technology that can only be remembered by rote memorisation and can easily be Googled. That is, if I even get to the technical interview part.

What kills me is when you go to the trouble of interviewing , do ok, don't get the job and then... get called to interview for the exact same job 1 year later! I mean.. something must be wrong on a (recognizable name) company that does not fill a position for 1+ year..

If a 960+ days GitHub commit streak doesn’t prove it, then I don’t know what will.

    crontab -e

    30 9 * * * cd /mycode && git add . && git commit -m "Woo!" && git push

    service crond restart

Ta da!

I share a lot of the author's sentiments and frankly a lot of the tech interviews I've had were terrible and I've also been on the other side of the table and made great hiring decisions based on conversations about past experience rather than grilling the interviewee. BUT at the same time, I think if we want to change the state of affairs software development and engineering needs to actually standardise what the body of knowledge that's essential to the job is, create a testable credential around it and make sure your candidates pass like in other engineering and tech disciplines. That's really the solution.

Ok, here's a pro tip: never go to tech interviews unless you know exactly what you are getting hired for. If the recruiter cannot give you this information, they you know this is what is in store for you. This is a game - some are good at it and some or not. If you are not good at this "puzzle" interview game, then simply don't bother since they are just demoralizing and a complete waste of time.

The best approach to getting hired (especially if you know you are good) is to reach out via your personal network. Get in via contacts and recommendations. Always keep pushing your existing coding profile at every point of interaction.

I interviewed for a different position at a company 2 months ago in Seattle. Had 3 phone interviews, then got called in for an on-site interview which I had to fly to requiring me to take 1.5 days off of work. I get there ask them if this goes well what are the next steps, they proceeded to tell me that I would need to do a take home assignment that would take a week to complete and if that went well another on-site interview.

Is that really necessary?

I was going to turn down the position in the end due to cultural differences. In the end I didn't get the position due to lack of technical proficiency though I was only asked behavioral questions.

Waste of time.

Tech recruiter in Chicago here.

So many factors go into hiring someone. Often it comes down to little things that have nothing to do with someones ability to do the job. Maybe a particular member of the team really didint like you or the manager and you went to the same high school and you have a connection.

It's crazy how often I will have a developer flat out rejected after a technical screening from one company only to go to another company who loves them and everything they do.

I believe the biggest misconception is that just because someone COULD do the job means that they will or should get the job. A lot of intangibles affect the final decision.

Context and disclaimer: I run a bootcamp for technical interview prep: http://InterviewKickstart.com.

Your frustration is understandable. But you also have to ask and understand how our industry has come to this point. There are concrete reasons for it, and despite this process not being the best, it's the least evil when hiring is done at scale.

The process is here to stay. If you want to work at some of those companies, don't overthink it. Just prepare for interviews. It'll also give you a refreshing perspective to software development.

I really do know the feeling of no feedback. I agree that hiring is really broken, only 2 months back I went on various interview rounds for a Front-end position and couldn't quite understand how an Algorithm would help one with CSS floats. I think I was lucky to interview with a Startup that really knew what they wanted and all I had to build was an app. I got the job and I love the job, I don't think I've ever been more in love with my job like this.

PS: The startup's not American, American startups have an inflated ego.

No offense, but not knowing BFS is kind of a red flag, even if its for a front-end position. It's the most basic graph / tree traversal algorithm there is. And you when you work with the DOM on a daily basis and use libraries that traverse for you its a good idea to have a basic understanding of whats going on under the hood. It's like saying you're a good programmer but not understanding basic concepts about memory management and whether things are stored on the stack or on the heap.

Here's an O(N) solution to the `findSum` problem in Ruby:

  def findSum(array1, array2, sum)
    complements = array1.map{|x| sum - x}.reverse

    i = complements.count - 1
    j = array2.count - 1

    while i >= 0 && j >= 0
      return true if complements[i] == array2[j]

      if complements[i] > array2[j]
        i -= 1
      else
        j -= 1
      end
    end

    false
  end

To be honest, your voice is a bit aggressive. I like open source as much as you do. Stars on GitHub repo does not necessarily mean we're skilled or clever, but it means that project is necessary to many people. You look for a job, but they look for the correct employee. I don't really like to interview with a company that I don't feel belong to. And if I do, I will focus my time on it

When you go on interviews you should be interviewing them as well. So for every question they ask you should ask them one as well. If they ask you to code up something them you should ask them to code up something to see if they qualify as a group of people you would like to work for. This might not go well at some companies which should be sign that you don't want to work for them.

I find it funny how many people dont realize the "your next interviewer is out of office so we are going to end early" is code for were have already decided to reject you so we dont want to waste any more of our employees time interviewing you. No company schedules a set number of interviews then decides to hire someone without doing every one of those interviews

I don't have any problem with coding question as I enjoy doing that. But what piss me off is that going into google with referral is a piece of cake and even if I do good in interview I can't get an offer. I know couple of guys who don't even do coding and can't write a BSF but they get into google apple and facebook with referrer. This referrer sucks.

The only way out of this mess is to start and bootstrap your own company. Hiring is broken, therefore hire yourself.

I see these same algorithms/concepts show up repeatedly in interview rants posted here. At this point, if I'm going to interview, I'm just going to cold memorize them over a week or so and then adapt to the specific interview questions. It's just a ritual that needs to be done at this point.

I am talking from personal experience here: Hiring is broken is a statement that is often the result of long intensive (and multiple ) interview processes which is met with sheer frustration.I went through that, cooled down a bit and came to a conclusion which I would like to share :

Hiring is Broken: Yes it is,but not the process,but the people. When you interview in a big company(especially a profitable one) you need to realize they are not looking for a typical skillset. Big (for profit) companies tend to keep their softwares behind closed doors. Hadoop was open sourced by google atleast a year after internal usage ,the same goes for Bazel(Blaze internally) .These were open sourced because they had much better versions of the same software that were consumed internally.When you reach such levels,performance factors are as important as

- ability to ship fast - writing clean/testable code - and all the other things that we programmers/coders are good at.

I am not saying that we aren't good at optimizing. But they are not really looking for the horde. This could also explain poaching college professors/PhD candidates for jobs.They need to people to push boundaries,not implement/build things from existing technologies.There is only so long that you can spend in a domain without having the need to extend that domain which you have been working in the past 20 years for.

Regular start-ups and other companies need a product.They need to make a mark in a field by pleasing the customer who would be using their products/technologies and who are looking for a service alternative mostly.

That is my justification for such interviews.This changed the way how I even handled interviews.

If I am asked these algorithmic questions,I generally smile and ask them if they want a Computer[1] or someone who can use a computer.I Immediately steer the conversation to what do they expect from me and explain to them what I can do.Often this clears the air and helps me(stress on the me) decide if I would like to join them. What you need to realize is that its you who is joining them.The impact that the organization will have on you is normally a much larger of magnitude in comparison to what you will have on the organization. The environment you end up working in will mould you in ways that you cannot anticipate.

PS: There are a couple of people who do the job hunting for the massive salary hikes and those sort of factors.I guess none of my arguments apply for them .

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

> When I asked the Vimeo’s recruiter for a feedback — no reply, haven’t heard from him ever again. Feedback is too much to ask for these days, apparently.

Corporate feedback is mostly BS. And the rare line from bozo recruiters offer little of substantive value. It's safer for him to say nothing at all.

I'll preface by saying I completely agree with the sentiment of the article.

However, I was taken aback by the author's refusal to try to solve BFS. To me, it feels like someone should be able to reinvent it relatively easy - that it's akin to a linked-list, palindrome or FizzBuzz question.

I always ask where they use those algorithms in their production systems.

The typical answer is that they don't :)

Hiring is broken , but not everywhere , its hard to set standard rules for technical hiring across different organizations , as every organization have different needs. I had similar experience in few organizations but not all organization are same.

I've been asked to solve such tough questions during some interviews. Getting asked to solve really complicated text search problems using suffix trees in a 45 minute phone screen for a junior Android dev position at a small startup lol

Just went through this process from the POV of employer.

The risk of choosing the wrong person is so great, that it's often better to not choose anyone. If there is any doubt what-so-ever, it's better to not make a a hire, it can be too damaging to a team, manager, company.

I've tried so many different "coding interview" scenarios. But I found the best one was a real task that a real staff member would be expected to do, extract it out into its own example, and before I talk to someone, they present their solution to the task, and the only thing we talk about, is their solution. If they can dissect and discuss their solution eloquently, and reason about trade-offs, short-cuts, talk about what they may have done better....

Of course, it can also be a simple case of, "is this person an asshole? are they going to rub my team up the wrong way? yes? fuck them."

This is just an indication of what will happen to you if you get the job.

Why don't more people do, "We're not 100% sure if you're the right fit, but we'd like to find out. We'll pay you to work with us for [2/4] weeks."

Wondering if the "cover your ass" is a factor in these hiring decisions. If you're the guy/gal who hire a new engineer, who turns out not to know their stuff, your ass is probably on the line. Making engineering candidates jump through hoops might provide them with a level of protection against future reprisals.

While I don't interview for engineering jobs, we do bid on municipal contracts which are dominated by this concept (cover your ass, hire the big guy). A different animal indeed, but in a employment hierarchy where employees are held accountable for performance of new hires, it seems similar incentive would exist.

"How many people can actually write BFS on the spot, without preparing for it in advance?" A lot of people. You should too, even if you're just a front-end.

Look for a job at a startup. Way easier to get in the door.

https://careers.stackoverflow.com/

"Write a maze solving algorithm" I just solved that in less than 3 seconds. Here is the solution in a Fiddle[0] and the discussion on Stack Exchange.[1]Sorry, I'm too busy solving problems which haven't been solved yet to bother with problems that have been solved.

[0]: http://jsfiddle.net/5g7se8qL/7/

[1]: http://stackoverflow.com/questions/16173259/javascript-maze-...

I wonder if this has to do with your personality, how you behave under pressure, and how you react to not knowing the answer to something.

You seem more than capable enough to get a good job but in my experience, interviewers are looking to see how you react to being stumped. If it's anger/frustration/clamming up then that's a turn off for a lot of employers. They're looking for more than the right answer.

I think this is the wrong sort of attitude to have towards hiring. Maybe interviews are suboptimal for finding good talent. Whatever. But if you want a job and you already KNOW the sort of tricks and games go on for these interviews, then why not just play the game? Do the adequate interview prep and land the job. It's that simple.

Rapid Development and Code Complete by Steve McConnell. Those books are prescient.

If interviews require this much effort people should get paid for their effort.

a quick fix would be to have feedback of your interview be mandatory if requested.. kind of like a FOIA request

I hired Sahat as an intern three years ago while he was an undergrad. It was one of the best hiring decisions I have ever made. He was productive immediately and our (small) team felt the loss when he went back to school. This guy is good and gets stuff done, ask people who have worked with him.

I wish Sahat had reached out to more of his network before responding to random recruiters. Tech interviews as Sahat experienced them are broken, but tech hiring is slightly less broken especially when you leverage your network.

*note this is the same comment I made in the other thread. I stand by it. https://news.ycombinator.com/item?id=11579757

I do not think junior people realize what senior people see when they look at your GitHub work. Without exception, the crappier the oeurve the more the candidate wants me to look at his or her GitHub.

Read a single user's Tweets going back a month and even your best friend starts to look a little nuts. Do it with their git history and you'll sometimes get a very different impression of their work habits, too.

In my experience, these services tend to make people look worse, not better. But I can't always give the benefit of the doubt when I'm making a critical hiring decision.

I've been in interviews where those stupid "I have three balls and want to guarantee the ball I pick is red" questions get asked, and what I've noticed is if they want to hire me, I can just take vague guesses and they'll help me along, but if they don't want to hire me, they'll sit coldly, watching as I flounder about. By the time I've sat down in the chair, a lot of times the person hiring has already made a choice. I'm not charismatic enough to reverse their choice, but I'm not antisocial enough to disqualify myself if they already like me.

The thing I learned about applying to jobs last time I went through this is that if your primary goal is obtaining a source of income, you need to send your resume to ~10 people a day, every day, and go on every possible interview, and do every possible thing people ask you to do.

You'll still lose a lot of jobs to these techniques, because they're effectively random, but since it's random, your odds of success increase with volume. Eventually you'll hit a position that you do just randomly happen to know the algorithm they're looking for, or they don't ask CS theory questions (I'm self taught, so theory is a weak point for me as well), and you can talk about/demonstrate your actual job qualifications, rather than some contrived talent that's entirely irrelevant to the position.

Tech hiring sucks, and the people who continue to do such a bad job at it seem to wear their behavior and tactics as a mark of pride.

There are a few companies that make it a point to mention they avoid the kind of interviews you've been getting. Perhaps try to seek them out rather than rely on recruiters

when they don't give you feedback, most of the time it means "you're great but we also found John OK for 1/3 of the price"

Hey Sahat, one problem is the small sample size any one person can get during the interview process, so I recently did this process and in one month I embarked on interviews with 15 companies and progressed to various stages. The recruiter was Hired.com and I wrote about it here:

https://gist.github.com/ericlw/16b55e038028e1e4768e

Because Hired.com prescreens companies and have a limited pool of both types of companies and types of candidates, it is easier to get a better sample size based on type of role.

I primarily talk about some of the arbitrary offers, instead of the interview process. But you might find it interesting too.

Not sure what is the problem. If you don't like the hiring methods of those companies (I agree those methods are retarded), then you are not their target. Look for something else. There is plenty of this for everyone.

If you don't like Google's hiring process, apply somewhere else. There's plenty of viarety among a whole host of different companies large and small. The reality is Google gets hundreds of thousands of candidates a year and has these processes in place for a reason. The interview machine at Google spans the entire company and everyone is expected to participate and give detailed feedback at each stage and "rank" a candidate on a 1-4 scale. You have to have some sort of normalization in place when you're interviewing at that scale, it's not enough to say "oh, this guy invented homebrew or this guy has some cool open source project, let's fast track him." It's unrealistic to think that. A lot of people complain that Google spends too much time on "things that don't matter like nuances of algorithms" but I'd disagree with that point. Google's not in the business of hiring "frontend devs" or "node js devs" theyre looking to hiring well rounded software engineers that would be expected to fit in any role given to them org wide. And honestly, it's not hard to pick up a data structure book and a "software engineer interview questions" book and study for a few weeks prior. You'd probably do pretty well.

HN doesn't bowdlerize, so the first thing to do with the title is take out the stars. But "Fuck you I quit" is linkbait of the kind that the HN guidelines ask submitters to take out of titles, so we've replaced that bit with a phrase from the first sentence.

When I hired a plumber for my heating firm, I put her through a hazing interview, tested her knowledge of Maxwell relations and thermodynamic equations. Oh wait, no I didn't. As she has been a plumber for years, so we recognised her skill and experience and cut to the chase.

When I hired a programmer for our doomed to die VC life support funded fart of a project, we put her through numerous rounds of comp sci bingo and algorithm hell. Why? Not sure. Everyone else does. I mean, hiring in IT is shit, why should we break from the industry norm? Why should we want to care about the candidates? Right? I mean if Google can do it...

You know what other type of people are not very pleasant to work with? Nerds who think they can trace a psychological profile of a person based on a blog post.