Tech Interviews Are Stupid

https://gomakethings.com/tech-interviews-are-stupid/

by tmfi • 5 years ago

68 156 5 years ago

westoque2• 5 years ago

The tech interview process is different for every company but it's definitely not broken.

As a CTO, one of the things I look for is experience. You can look up all the "basic shit" you want but if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem. If I'm interviewing a senior engineer, I want you to be able to show your seniority one way or another, if we talk about architecting something, I want you to be able to talk about why we want to solve it this way, pros-cons etc. Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key.

forbiddenvoid• 5 years ago

I'm curious about the reasoning behind these statements.

For example:

if we're talking about a specific problem, I want you to be able to give/walk me through a solution even if we don't finish the problem"

Why does this matter? Why do you want this? How do you correlate what you're stating you want here with actual job performance?

westoque2• 5 years ago

Why does this matter? Why do you want this? How do you correlate what you're stating you want here with actual job performance?

It matters to me because we want to be able to show that we can think through solutions. If we're building a feature that has something to do with streaming video, it would be a plus if you've shown that you have experience building streaming services or at least some knowledge along the topic. This should correlate with job performance because of the experience and working on this topic is already known. Now, there would be a case where we have 0 experience with this problem space but again it comes down to thinking through solutions and thinking about race conditions, side-effects etc and being able to identify these.

nowherebeen• 5 years ago

most tech role interviews involve some sort of coding challenge

He is talking about coding challenges specifically.

choppaface• 5 years ago

In the macro, there is a ton of demand for engineers yet short supply (particularly for universities). Thus the very high false negative rate observed at nearly every company indicates the interview system is broken.

What would help is more disclosure from hiring managers and interviewers about what they want and the success rates of candidates. That information is still largely today only available to hiring managers and executives. We need less information arbitrage for a more efficient hiring system.

duped• 5 years ago

More information just makes it more difficult to filter out the scripters trying to automate their job applications. That's the biggest issue I have seen, personally. There's too much noise on the channel, and giving any advantage to the CV spammers is not going to make it less noisy.

dahart10• 5 years ago

Thus the very high false negative rate observed at nearly every company indicates the interview system is broken.

What high false negative rate? Can you point to some data?

By "false negative", are you referring to rejecting a good candidate? Are false negatives (rejecting a good candidate) more important than false positives (hiring a bad candidate)?

We need less information arbitrage for a more efficient hiring system.

How do you define efficient? Whose efficiency are you considering, the company or the candidate? Why should efficiency be a primary goal of the hiring system, as opposed to simply finding the best candidates in a reasonable time frame?

throwaway744678• 5 years ago

The cost of a false negative to the employer is quite low (missing on a good candidate) compared to the cost of a false positive (hiring a bad one).

quickthrower27• 5 years ago

Engineers are of course not a uniform thing and every role is looking for different experiences and traits, so you’ll get a lot of good engineers knocked back from interviews who go on to get a job somewhere else. This might be trite but thought it is worth mentioning as what seems “unfair” can often just be this.

tchalla2• 5 years ago

Experience also shows me that it wouldn't take you a long time to solve the problem, and in our industry, at least my experience in startups, speed is key.

If you feel that way, here's a viewpoint from Derek Sivers which talks about "Idea being a multiple of execution" [0]. If you genuinely believe that "solving a problem within a few minutes" can be reached, I'm going to ask you - What problems are you asking people to solve in a limited time frame?

[0] https://sive.rs/multiply

beebmam• 5 years ago

In my experience, speed is the opposite of key for longer term success. Speed is how my companies have ended up with designs and implementations that weren't maintainable and/or had big gaps in them.

I'm sure the usefulness of speed varies by context

gizeta• 5 years ago

I worked in a company which was hiring tech folks without coding interviews.

I am glad I left.

wdb4• 5 years ago

The company didn't use the three or six month probation period?

obviouspenguin• 5 years ago

In my experience, getting a bad hire is worse than not hiring at all. It takes a huge amount of resources to properly onboard a new team member, and then if they are not performing well the work they were doing ends up becoming a liability instead of an asset to the team.

handrous5• 5 years ago

I think part of the problem is that places with coding interviews usually pay better than those without, and the ones with the really painful, idiotic, grueling interviews that everyone hates offer the top pay, so the system ends up sorting all the worst candidates to the companies that don't do "normal" coding interviews.

In fact, I think that effect is exactly why the top-paying places do it, because it makes their hiring easier. At this point, if any of them unilaterally drops the hellish, silly, hazing-interview process, they'll be inundated with good candidates they've been excluding plus a shitload of bad ones who'd already been filtered out by the fact that their process is hellish and silly. So none of them will.

onlyrealcuzzo• 5 years ago

Someone wrote a really great article for how you should play this as a company if you can't pay the best.

Unfortunately, don't have the link.

The premise is: you should be aware that there's a large subset of good engineers who aren't particularly great at coding interviews - and you should set up your interview process to select for those candidates.

rimliu3• 5 years ago

I also worked at two companies like this. Both rank as #1 and #2 best places to work. A bunch of very competent people.

kristiandupont• 5 years ago

I find that pair programming with the candidate on their laptop, using their preferred tools works well.

It takes time and in many ways it requires more energy from me than if I were to just sit and observe. However, it gives a better feel for how the person goes about solving problems from the abstract, architectural stuff to the nitty gritty. I love it when pairing with a fellow vim-user as I will inevitably learn some new trick.

aprdm2• 5 years ago

Totally! On their laptop being the key. I interviewed at Pivotal around ~6 years ago and the person had some customized VIM setup which was a PITA to work with. He had a very good workflow with it and I honestly looked dumb trying to achieve the same things as him in his computer...

wdb4• 5 years ago

Yeah, or when they assume you have an English keyboard...

villasv• 5 years ago

I understand why interviewers do this. They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web.

Bad assumption. If you really did understand why , you wouldn’t say it’s stupid (unless for clickbait).

wizzwizz4• 5 years ago

By that logic, no societal system can ever be broken.

gitowiec• 5 years ago

I think that they want to hear is thinking. So every time I am during technical interview, I just talk out loud what I see in front of my eyes. That is great because they get to know my thinking process and it works as a rubber ducky for myself.

cogman106• 5 years ago

This is something a great interviewee does. I don't try and trick interviewees or make things unnecessarily hard. I really just want to see "can you think like a programmer". When an interviewee gets stuck and isn't saying what they are thinking about, it makes it really hard for me as an interviewer to give good prompts.

Obviously, I can't give away a solution, but at the same time some people will get stuck on things like "Can I use X" or "can I use Y". And for me, that answer is almost always "Yes, absolutely use X!". Because that's what I WANT from someone I'm working with. I don't want you to write a sort from scratch, I want you to call `Collections.sort` or even have the wherewithal to ask someone/google "Hey, I know Java has some inbuilt sorts, how do I invoke those?".

The only time I'll maybe mark you lower is if you start the interview by saying "Yes, java is my favorite language to program in and I use it all the time!" and then struggle to do `new ArrayList<>()` (which has happened on multiple interviews). I always try to get someone to use whatever language they are most comfortable with. Because, to me, languages are stupidly easy to pick up and which one you are most familiar matters far less than how you use it.

ub992• 5 years ago

There is a limit to the proposed approach. Most interviews I conduct (algorithms) include puzzle-like problems. So if you just Google them - you would find a complete answer. In that case, what's left for the interviewee to solve? (Whether algorithm questions should be a part of the interview cycle is a different matter.)

aprdm2• 5 years ago

I interviewed at SkyScanner around 5 years ago and they gave me some problems that I already had seen since I was interviewing like crazy. I solved them very easily and the interviewee had nothing else to say. Then her feedback to the interview was negative because it looked like I had already seen the problem.. like... :shrugs:

wdb4• 5 years ago

Yes, Skyscanner is a horrible at hiring. Can't even bother to reject you or give feedback in the last round

tchalla2• 5 years ago

Most interviews I conduct (algorithms) include puzzle-like problems.

The reason for your predicament is in your comment.

ub992• 5 years ago

It's a company policy with vetted questions, I dislike this approach.

goalieca• 5 years ago

This is one of my favourite tweets: https://twitter.com/mxcl/status/608682016205344768

I've seen some rather complex problems being asked in interviews. I've always wondered why my credentials don't seem to matter when it comes to programming skills. I have a masters degree where i did some very tricky algorithms and I even open-sourced it for all to see. But every time I've been looking for a job, i have to rehearse some leetcode problems so that i can put on a good show for 45 minutes.

I get that deep-dives matter a lot and i can respect some of those exercises. These are crucial for senior positions since ideas are more important than code. Then I really get the life story kind of interviews because relating to coworkers and culture fit are hugely important.

It's just the dang leetcode that ticks us all off isn't it?

vultour2• 5 years ago

I was also a fan of this tweet until I found out what inverting a binary tree actually is. Being asked to code relatively complicated algorithms like balancing a binary tree is one thing, but this guy essentially failed FizzBuzz. At that point it’s not about testing the limits of your candidate but filtering out the low hanging fruit.

Obviously I don’t have the whole story of the interview, but it makes me a little worried for homebrew.

SQueeeeeL3• 5 years ago

Inverting a binary tree is essentially trivia in the context of most programming, honestly, if I had to do it without a library I'd be extremely worried I'd fuck it up in some subtle way. Max Howell obviously has a strong understanding of file systems, web protocols, package management, and a whole other suite of skills I'm too stupid to understand.

pydry5• 5 years ago

The fact it was trivia irrelevant to most programmers is precisely why it was such a brain dead question.

Asking what FizzBuzz is is similarly useless and would also make an abysmal question.

ClumsyPilot8• 5 years ago

"until I found out what inverting a binary tree actually is"

So do you consider youself a terrible, unhire-able developer? Presumable your still has quadrupled since you found out this information?

jerf• 5 years ago

No, it's not FizzBuzz. It's a recursive algorithm, which FizzBuzz isn't. (Or doesn't have to be. Let's not cite crazy repos with dozens of solutions deliberately obfuscated.) That automatically takes it out of FizzBuzz range.

If you're a functional programmer, it's probably something you can just bang out. I've done functional programming. But it's been a while. In an interview situation, I'd definitely need some time to struggle through it.

What gives? I claim to be a senior developer of ~25 years experience? Why can't I just bang out the roughly ten-line solution it would be in Haskell, including the requisite data declarations? Well, in my 25 years of experience, yes, I've covered everything that is necessary to do that problem, but I've got to drag it out of storage and rehydrate it manually, because I don't do this sort of thing every day lately. Or ever, really, because what senior dev is running around implementing Computer Science 301 data structures every day anymore? Pretty much just one currently implementing a brand new language that needs those basic structures in its standard library.

I'd get there. It wouldn't even necessarily take long. But I can understand why an interviewer asking this question ten times a week who knows the answer forward and backward might find taking even 5 minutes to be an unimpressive performance for something that such an expert should clearly just be able to scribble down in one shot, right?

And I'm gonna be honest. If you ask me to balance a possibly-unbalanced sorted binary tree, I'm basically going to be re-deriving the answer from scratch. Yeah, I covered it. Probably even did a homework assignment on it in C. But my job for the past 25 years has not been implementing balanced binary trees.

SQueeeeeL3• 5 years ago

People cheat their way through credentials all the time, having a masters degree doesn't tell you anything about a person except they maybe sat in a room on their phone while someone discussed the nuances of Church's Thesis. And most interviewers aren't valued enough by a company to really give a shit who you are, there is just too much happening and too many interviews, so they just can't be asked to look at your Github.

The game and well are poisoned at many levels. There's just too much money on the table at most modern tech companies to trust anything.

cogman106• 5 years ago

Bingo.

I do quite a few coding interviews for my company and, frankly, the pass rate on the coding interview is dismal. It's one of our most effective filters for bad candidates.

What sort of torturous questions do I ask? Merge 2 sorted arrays is one of my favorite.

How many people can pass that? less than 50%. A good number of people don't even get to the "concat the 2 arrays into 1 array and sort" sort of solution. It's really that bad. These are people with "15 years of software development experience" failing really basic coding problems.

I really wish I didn't have to ask that sort of question, but at the same time, I don't want to work with anyone that can't solve it (even "under pressure").

The fact is, a lot of programmers will go off the deep end with simple problems. This joke[1] still relatively accurately describes the mentality of a bunch of programmers in the industry.

[1] http://4.bp.blogspot.com/-Hk1mt-RKYLc/UOkxShm6NrI/AAAAAAAACq...

UncleMeat• 5 years ago

Notably, he was never asked to invert a binary tree and I don't believe he ever got confirmation about why he was rejected. Given how he responded, I wouldn't be stunned if the answer was not his technical performance.

dahart10• 5 years ago

I have definitely been part of interview processes where the team unanimously rejected experienced candidates who express visceral negative and incredulous reactions to being asked to demonstrate basic programming proficiency. The story here has hints that it may be in this category. Some candidates with decades of experience expect to immediately have philosophical discussion about where software is headed, and offered their choice of management/architect positions without talking about code, and get upset when the interview starts out with some softballs. The irony is they get ejected before the interview gets to the good stuff, we do ask about philosophy and management, but a bad attitude can take that off the table very quickly.

fingerlocks• 5 years ago

We don't know the full story behind that tweet. Inverting a binary tree is not exactly a difficult problem. They could have even spoon fed the author with "Ok, here's the code to traverse a binary tree. This is what it means to invert a subtree. How would you invert the rest of the tree?"

marcinzm2• 5 years ago

I've had plenty of candidates with great credentials who utterly bombed relatively simple coding problems. Not fizz-buzz but also not that much more difficult.

evrydayhustling• 5 years ago

Our tech interviews focus on watching you work the way you actually work: Google allowed, your IDE of choice, your boilerplate project templates, etc. Yes, you still have to show progress against a problem in 30-60m -- but sometimes rapid prototyping is important to the job!

stevebmark• 5 years ago

This is a bad take. Coding interviews help you see how someone solves a problem. And good coding interviews let you search for whatever you want except for "how to do this problem in x language."

horsawlarway• 5 years ago

I've done more interviews over the last two years than I'd like, and honestly - I have no problem with folks googling "how do I solve X in language Y".

Frankly, we tell folks up front - "This is not a memory test, please feel free to ask questions, use google/stack overflow/man-pages/etc."

I'm in the interview to give you a problem that looks as close as possible to the work we're going to ask you to do, and then discuss with you how you solved that problem.

If you copy from stack overflow and it works, great! Now we can talk about possible edge cases, performance issues, testing, add a new requirement, etc.

I don't really care how you get the code into the file, or where it comes from - I care that you understand it, and can think through how that code will perform in different situations. Most importantly of all - I care that you can tell me that information in a coherent fashion.

lliamander• 5 years ago

What is your process for evaluating "how someone solves a problem" and how does that inform your hiring decision? Does it simply come down to "does this person solve the problem the way I would"? How do you address confounding issues like performance anxiety induced by constraints not present in a normal work scenario?

My observation is that many companies don't address those problems well.

smcl• 5 years ago

Hold on, how are they “fundamentally broken” if the author is happy with the format with just a slight tweak (allowing use of Google, which many places do already)?

I see that phrase a lot and it’s often deployed without a great deal of thought, which is a good indicator that what I’m about to read is a pretty low-effort article, blog post or tweet.

Invictus0• 5 years ago

I think the author is trying to say that interviews are testing for the wrong thing (ability to solve tricky problems quickly, on the fly, and with no help, which is unrealistic in the workplace) when what they should be testing for is good analytical and research skills, with the assistance of the internet available, just like in real life.

pydry5• 5 years ago

Realism is criminally underrated in interviewing.

lhorie3• 5 years ago

A small pet peeve of mine is when someone criticizes the interview process without having been on both sides, and assumes that they know what the acceptance criteria is. This article is a good example of that:

They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web

This is not quite right. It's right in the sense that if your resume says 3 years of JS experience and you're spending 20% of the time fumbling with unmatched brackets, it says something about you. It's right in the sense that if you say you've done React at two previous jobs but proceed to call setState multiple times in series and then scratch your head when stuff doesn't work, that says something about you. Etc. However, it doesn't mean what a lot of newbies seem to think (that when receiving some leetcode-like task, they're supposed to have the exact ideal answer memorized)

In my interviews, one of the first things I tell candidates is in fact "feel free to google stuff, I'm not here to test whether you've memorized stuff, I'm more interested in how you approach problems".

At least for FAANG/bay area tech, good interviewers looks for signals, and not just purely technical rote memorization: on a basic level, one looks at whether the candidate has working familiarity w/ syntax and APIs that they ought to know, but on deeper levels how they think about code structure, refactoring, testability concerns, design trade-offs, how effectively they communicate (both speaking and listening to feedback), etc. There may also be smaller considerations for legitimate "fit" factor, for example whether a candidate is more startup oriented or more enterprise oriented (this mostly matters when you think about their career aspirations vs what the job is able to provide in terms of challenges).

You can get a pretty decent feel for how "senior" a candidate is, and then acceptance becomes more a question of placing the candidate on a sliding scale based on how demanding of a role one is trying to fill.

The one criticism I have about the interview process is that many interviewers don't tweak their expectations based on level quite as much as they should, especially if they only hire sparsely for low seniority levels. For a junior hire, there should be an expectation that some ramp up time will be required. Expecting upfront solid experience with a laundry list of technologies from them does a service to no one.

yoz-y• 5 years ago

I like the idea of letting the candidate do whatever they would if they were actually coding. I even think it could be interesting (in the initial part of the process) to ask the candidate what question they would like to be asked, and let them implement that.

Few things to point out though:

1. you can ask the interviewer questions

2. the problems are usually simple enough that you don't need to google them, and should have prepared for them in the first place

3. you should be somewhat efficient (being able to do basic stuff without googling) in at least one language, since you can choose the language for the interview do that

jjordan• 5 years ago

I'm lead dev on a rather large frontend project, and I still feel like I'd struggle in a frontend-focused interview today. Underappreciated by many I think is the ability to solve problems. I solve them (almost) every day, but sometimes it's easy, and sometimes it's really tough. But eventually, if you know how to ask the right questions, you'll get to a workable answer. That kind of real-world experience doesn't seem to surface well in a typical interviewer/interviewee type setting.

quickthrower27• 5 years ago

And once you are a lead you are doing less of the stuff day to day that would make you shine in a coding interview. Especially the ones where “we need a c# engineer so let’s dust off those weird exception handling edge cases again and test on it” when in real life you look it up or run a unit test over it (better!)

dahart10• 5 years ago

If the title was a comment, it would be breaking the site guidelines.

More importantly, it's throwing out absolute opinions on why interviews are broken without demonstrating a real problem. There have been hundreds of articles saying hiring/interviews are broken because <logic/opinion>, and almost none that point to data showing that companies are not able to hire developers, nor that developers are statistically unable to get jobs.

Interviews can be difficult and frustrating for both sides, but that doesn't mean they're not working. Despite the fact that the article is correct that looking things up is routine in a dev job, I still may prefer to hire the candidate who doesn't need to during my interview question that was specifically designed to not really need to.

I don't know how often coding challenges disallow using the internet, but the last time I interviewed it was allowed. I've seen lots of companies allow use of any language, and spend your time searching the internet if you want.

ClumsyPilot8• 5 years ago

We literally have thousands of research studies demonstrating that place of birth, income, gender, and even names bias hiring.

If it was this prilliant data driven meritocratic nirvana of scientific precision, we would never have issues with discrimination again minorities, the poor and people who looks funny and have tatoos.

The burden of proof is on folks that keep pushing these silly tasks, where is the data "we've added some stupid questions to our interviews, and now we are doing twice better"?

dahart10• 5 years ago

Oh I'd agree there's cultural bias issues, but that is a complete straw man in this context. The article wasn't about cultural bias, nor was my reply.

Meritocracy, incidentally, is a term that was invented to demonstrate bias, not a signifier of the ideal system. https://en.wikipedia.org/wiki/Meritocracy#Early_definitions

The burden of proof is on folks that keep pushing these silly tasks

This strikes me as a somewhat bizarre and myopic way of thinking about jobs. There is no burden of proof at all, because there is no claim being made. The deal here is someone will pay you money, if you agree to do the work they ask. This opportunity is available to people who make it through the interviews in order to demonstrate they meet the qualifications for the job. Companies that are hiring are the sole decider of what these qualifications are, and can choose to have them demonstrated in any way they choose (up to what we agree are legal limits.) If you don't want money, then don't submit to "silly tasks". (I've never witnessed silly tasks in my interviewing, ever. I've had questions for which I don't have experience, and questions that are too hard, but the questions have always been pretty focused on figuring out what I know and how good of a programmer I am, and by extension how much they are going to pay me...)

ng12• 5 years ago

Where are you interviewing that they don't let you google stuff? I've gotten to the point that I don't even ask anymore, I just open a new tab and explain what I'm looking for. If the interviewer takes issue with it that's a big red flag for me.

lbarrow3• 5 years ago

I see posts like this all the time on HN and I really wonder if there's an alternate world of really stupid interview practices out there that I've just been lucky enough to avoid.

In this case: I've never heard of, participated in or administered a programming interview where the candidate couldn't Google things.

I remember when I interviewed at Braintree, I spent a good chunk of the pairing interview searching for Linux command syntax because I was new to using it. I got the job and spent 7 years there.

chrisseaton2• 5 years ago

Are you allowed to Google things in a Google interview? I don’t think I was allowed to!

How would that even work? You’d just Google for the answer to the brain teaser and find it because there’s only so many brain teasers out there.

lbarrow3• 5 years ago

I'm referring to a programming interview, where you are writing code with the candidate -- not a brain teaser.

jl27182• 5 years ago

I failed an interview once because I knew pacman but they were looking for apt. Big green GPU company.

laichzeit0• 5 years ago

Were you the only candidate? I mean maybe they interviewed a few people, who already knew apt. So it’s a choice between hiring someone who already knows the tech stack they use, and someone that doesn’t.

romwell• 5 years ago

When I interviewed for Facebook, the interviewer berated me for the coding pad losing focus with an alt-tab for a second ("What are you doing?").

I wasn't aware they were tracking this, of course, nor that it wouldn't be kosher, and I specifically asked about whether I could look up Java API at the start and did not get a "no" ("We don't necessarily require working code here" is pretty ambiguous).

I passed the technical round, and then they ghosted me after asking what my technical level at Google was (which I didn't have to tell, as it's hidden even within Google).

TrackerFF• 5 years ago

Probably very controversial opinion, but so far, my favorite type of interviews have actually been take-home problems.

Of course, it sucks if you've invested time into those, and get ghosted afterwards - but luckily I have yet to experience that.

Some people excel on taking test, some people excel on projects, others in both - I've personally never been the type to perform well on banging out code on whiteboards, but I will perform well on projects.

edit: Let me expand a bit on this

All my take-home problems have been very reasonable. Usually they've been more big-picture / architecture oriented, and not some specific implementation - some coding, some presentation, usually takes 2-6 hours to complete, depending on how much you put into it.

It is of course unfortunate if someone decides to code up something for a whole weekend, like 20-30 hours, only to get ghosted or similar. I guess it comes down to identifying free work from actual interview problems.

SteveNuts• 5 years ago

Not controversial so long as they pay you for your time. This should be standard practice IMO

amelius• 5 years ago

Perhaps both parties should pay, i.e. 50/50.

andrewingram2• 5 years ago

Personally I don't find making my tax situation more complicated doesn't help with the stress of job applications. I did a work trial last year and it added a whole new layer of anxiety about figuring out how i'm supposed to declare ad-hoc income (which in this case was foreign, making it even more complicated).

If you're used to something like the UK's PAYE system, being paid for interviewing is far from a no-brainer.

jayd16• 5 years ago

Do they pay you on how well they grade you or do they pay a flat amount?

Either they grade you at 0 and still hire you or I can make some extra cash turning in a bunch of empty applications.

decafninja• 5 years ago

The other big problem with homework is that they are most often used in addition to the leetcode round, not instead of. So double the fun!

pydry5• 5 years ago

I've only ever had bad experiences.

* Here's a problem that takes 6 hours now do it in two.

* Ghosted

* Bizarre feedback that suggests they mixed me up with a different candidate.

* Emailed while I'm half way through the task to let me know that the position has been filled.

* We aren't prepared to spend 5 minutes looking at your portfolio to see if you can code to a base level but please do our take home problem that takes an hour and a half to prove that you can code to a base level.

marcinzm2• 5 years ago

The problem with take home interviews as I see it is that it costs the candidate X time and the company roughly 0 time. This incentives companies to give them to anyone and everyone. So you may be considered a marginal candidate who has little chance of passing unless you prove to be an utter genius in the take home. With in person interviews you'd just get rejected but with a take home they have nothing to lose by giving it to you. So it's a system that can work when few companies do it but utterly implodes at scale.

akvadrako• 5 years ago

I've had some take home interview assignments that were paid at my freelancing rate. In my opinion that's win-win; the company has the right incentives and also saves engineering time since interviews are shorter while in the worst case the candidate made a little money on the side.

jordache3• 5 years ago

takes 2-6 hours to complete

screw that

juancn2• 5 years ago

At my company, we usually do the more in-person interview, but if we suspect you have potential and your performance is negatively impacted by the stress of the interview process, we propose a project interview to wrap up the decision.

Since it's more time consuming we don't offer it up front, most people don't like them, but it's a useful tool to have to size up a candidate.

The post-project debrief provides a lot of information on how you think and how you work, the end result is not expected to be perfect, or even complete, as long as the approach is reasonable and we can picture if the person-team fit is there.

froggertoaster• 5 years ago

What a way to add nothing to a conversation horse that's been beaten to death as is.

jordache3• 5 years ago

Just ask them to articulate technical concepts, so you can know whether they are full of sh*r not.

People who can hold targeted low-level technical conversations are generally well equipped to do the work you are expecting him/her to do.

What's wrong with this approach?

lordnacho• 5 years ago

That's my preferred method as well. Talk about the stuff, throw in words they should have heard of. See if they run out of intelligent things to say.

jordache3• 5 years ago

A good question for ppl in the coding challenge camp.

What new information do you neeed from a coding challenge that you don't get talking shop with the individual?

I don't think low level technical stuff is something you can BS your way through an interview. If it works on you, then you as an interviewer has major gaps

davidw• 5 years ago

I find the 'take home exercise' to be tolerable. I hate the live coding things. Those are awful.

Even the take home things are not fantastic, though - if you already have a job, a family and other stuff going on, "just 4 hours" is kind of a PITA.

handrous5• 5 years ago

"Just 4 hours" for a chance at the job, and how high a chance depends on the employer (i.e. how early in the process they drop the take-home exercise on you, whether you've already come to terms on pay at that point, et c.)

In general I just wish places that weren't FAANG would be more open about their process. Do I need to brush up on leetcode shit before applying, or no? Are you gonna quiz me on obscure corners of a language that I reflexively avoid because they're terrible, so haven't thought about in a while? Gonna talk architecture? Will I be writing code with someone looking over my shoulder? Pairing? On what kind of thing, generally? Is your filter for the 200 candidates who apply to hit them with a take-home assignment or longish automated test first thing, so I know to just skip applying at all (screw burning that much time to apply for the privilege of getting an interview at just one place)? With FAANG you know what you're getting in to, so at least you know you're about to step in a big pile of shit and can put on your waders first. The blind roulette wheel of hiring outside FAANG is its own kind of trash-fire.

quickthrower27• 5 years ago

I remember this with a newborn I spent 20 minutes on such a test. Recruiter tells me they said no because code quality so i gave it another shot spending 2 hours. Remember with multiple applications these times added up.

Got to the interview and they were so obsessed about this being written in some “perfect way” (see the enterprise fizz buzz someone linked to) that they knocked me back when I was explaining it at the interview.

It’s the coding equivalent of “ooh so you are not using a suse vide” at a mates bbq.

rullelito• 5 years ago

When I interview using coding problems, you just need to know very basic Java or python to solve the problem.

We also nudge interviewees in the right direction to make sure they don't get stuck, which would be in no ones interest.

There is also no hard requirement that you need to solve the problem completely. If you talk to someone for 45 minutes about a coding problem you will get a good sense of their performance, even if they don't solve the problem.

Coding interviews are great (except making the intervieww very nervous), but you have to be mindful as an interviewer.

roland35• 5 years ago

I disagree that coding challenges are stupid, I actually find them having some of the best signal-to-noise ratio of any step in the interview. Maybe it depends a lot on what type of coding problem it is?

One important aspect of doing the coding interview well is to make it generic enough and not look for a specific exact solution, so things like "write a function for a movie theater ticket dispenser" vs "write the most efficient string reversal" function.

I am also totally fine if a candidate needs to look something up, but I don't think it is unreasonable to expect candidates to be able to work though a general coding exercise without needing to stop and google things frequently. Especially if they can pick their own preferred language!

planet-and-halo• 5 years ago

It's largely in the execution. Coding exercises are probably the best thing you can do, but many interviewers use them to ask bizarre trivia and look down on people who don't have it memorized.

grishka• 5 years ago

I want to take one of these interviews just to look the interviewer in the eyes and ask one question.

Since I'm not allowed to google stuff now, would that mean I won't be allowed to do that while working for your company as well?

nappy-doo• 5 years ago

Ok, go ahead. Ask me a question. I've done > 400 interviews at FAANG companies, so I guess I'm due.

jamal-kumar• 5 years ago

After convincing the boss to fire a guy who laughed at me using vim saying it was really old and then proceeded to push broken code to production at 4am, trying to blame it on me when the logs were really not in his favour, I ended up in the position of doing the hiring for a guy to replace this yahoo. I live in a country where people's resumes fit in a damn manila envelope because there's just SO MUCH emphasis on degrees and stuff like that, and while the education here is pretty good (A lot of focus on hardware in the compsci curriculum here actually), really all I wanted after rejecting a bunch of prospects for technobabbling bullshit at me with their huge, multi page resumes i barely read was someone to tell me humbly enough that he'd just have to google the solution to the really damn easy fizzbuzz i was presenting them. You know how hard it was to find that in a braindrain situation? My boss thought I was being too mean, but really I just can't work with dishonest people. It's the most important thing to me that I actually like my coworkers for being good people. A coding interview of the MOST BASIC kind can act as a sort of filter for this.

Like sheesh, I'm not looking for this:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

All I want is to know if you know how to work with a modulo operators or not in an honest way, if you know basic third grade level integer division with remainders. If you give me bullshit instead of that, chances are you're not going to get hired. A probationary period for a couple of weeks after on the job after that to see how good you actually are, paid, with the knowledge that if you're just a terrible programmer you don't make it past that.

the_jeremy• 5 years ago

As a job searcher, I want to be able to spend as little time as possible on the interview process for one company. I don't mind researching the company or talking about their specific process, but I want to minimize the amount of time I have to take to prove my competence to them, because that's something that should transfer well between the different roles I'm pursuing.

I understand that not everyone has an OSS portfolio, but it's better than having 5 different companies give me a unique take-home project, and then having another 3 companies give me an algorithms assessment. If everything was "let's take a look at one repo you've spent <10 hours on" or "let's do leetcode problems" that would be preferable to the current state of affairs, because as it stands I have the worst of both worlds.

ClumsyPilot8• 5 years ago

The best is when they give you a take-home problem and an agreement: "we own all the code you write, dont show this to anyone"

karmakaze3• 5 years ago

The author hasn't had the more dynamic interactive form of tech interview that I (as a platform dev) am used to.

Coding is solving problems. A big part of that is looking stuff up. Like, seriously, the most important skill a developer can have it knowing how to research solutions to problems. Specifically…

    Breaking problems into parts
    Identifying what to search for
    Knowing how to sort good info from junk

Rather than have them Google things, there's an open dialog with the interviewer where the candidate thinks out loud and the interviewer gives the 'search results' for them to use now, later, or not.

The interview is not about 'if' the candidate can solve the problem. Even it they don't the result can be positive. It's about how they think, break things down, compose the parts into a solution. No one should care if you memorized the syntax of anything.

kokanee• 5 years ago

Agree with this. In my experience interviewers don't mind if you would normally look something up, but you need to state "hmm I always forget which direction Array.sort sorts based on your return value" and they'll usually say something like "yeah me too, let's try it this way and flip it if needed." If you say nothing and freeze or implement it incorrectly without making it clear that you half expected it, the same situation feels much worse.

In general, I've been seeing some conflation between the "tech interviews are broken" sentiment and the "tech interviews are too hard" sentiment. There's probably some truth to both, and some specific things that both interviewers and candidates can do differently to make more interviews more productive. In all cases, being calm and congenial and trying to put the other person at ease (even if you're the candidate) can work wonders.

rimliu3• 5 years ago

  > It's about how they think, break things down, compose
  > the parts into a solution

I usually think in silence, and alone.

karmakaze3• 5 years ago

That's fine too. Often if I'm thinking out loud it's for the benefit of the interviewer so they don't get bored or confused later when I write a bunch of stuff after a long period of silence.

I also tend to do a lot of scribbling of intermediate picture/thoughts that I wipe and redo so it's not a complete void.

Where it can penalize you is if you don't finish and not having talked/shown your work to that point doesn't count for as much.

The best tech interview is if you describe the strategy, algorithm outline and datastructures that you would be using and the interviewer says, "that's good enough, next question".

lamontcg• 5 years ago

Why don't you ask the candidate about problems that they've solved recently though? Why give them a specific problem out of the blue that they might not have any experience with? Wouldn't it be better to ask them about the hardest stuff they've recently done and then ask them about what constraints and tradeoffs they hit and things like that?

lhorie3• 5 years ago

I do both. The problem with asking only about experience is - as surprising as it may seem - people are often not prepared for this question. This often means they just talk about a highly specific mundane technical task they're currently working on (for example, I've had answers like "implement redux reducers for my project") and when pressed about challenges, they can't come up with anything and just wing it with some generic canned response (e.g. "the challenge was using APIs from backend team to make the product work" or some other mundane aspect that one typically would expect to be present in every such job). Another variation is that they can't organize their thoughts quickly enough to summarize effectively, so they ramble semi-incoherently for 10 minutes about the specifics of their tech debt.

Mind you, while answers can be highly uninspiring, they often help contextualize where a candidate is in the spectrum. It's easy to spot ticket-closers with this question for example, and conversely you can quickly spot highly opinionated individuals. But like in scientific studies, there's different value in self-reported data vs data you collect from your own observation. There's plenty of "talk-the-talk" people that can articulate prose extremely well, but struggle with the most basic of technical tasks when it comes to actually writing some code. This is surprisingly common with people pivoting from startup jack-of-all-trade roles to highly specialized roles in bigcos.

amusedcyclist• 5 years ago

Looking up things isn't solving problems. Sometimes you need to look up things to solve problems but they are fundamentally unrelated. Coding interviews generally require 0 background (other than base CS principles) so you shouldn't need to look up anything. I've never had someone ask me for correct syntax in an interview setting.

rasfincher• 5 years ago

One of the companies I interviewed with did what he described and it was nice. I thought the cool thing was that in the second interview they wanted me to walk them through some of my thought process for why I did/searched for certain things.

I didn't end up taking the job, but boy was it a breath of fresh air compared to some of the other interviews I've done.

thenanyu2• 5 years ago

Posts like this pop up pretty frequently. The format is usually…

I hate tech interviews, they’re a poor proxy for real work.
Here are some ways they’re silly (some examples follow).
A good interview would not have these bad features, maybe someone should do that.

What I’ve observed in 12 years of practice is —

It works; things go south quickly if you don’t do rigorous technical interviewing.

There is huge variance between interviewers, in both accuracy and bedside manner.

The most effective signal by far (close to 100%) is: someone I already trust technically who has worked with them says they’re good, and is willing to stake their reputation on it. I enthusiastically skip the more tedious parts of interviewing in these cases.

Interesting things I’ve seen, experienced, or practiced:

Long trial contracts to hire, no exceptions. Buys you accuracy at the cost of reduced candidate pool.

Willingness to fire quickly (first 30 days) — in practice similar to above. This is often advocated for but rarely implemented.

De-emphasize interview, heavily game-plan and weigh reference calls; do a lot of them (5+). This works if you have the technique to blow past the boilerplate endorsements.

dfadsadsf• 5 years ago

The most effective signal by far (close to 100%) is: someone I already trust technically who has worked with them says they’re good, and is willing to stake their reputation on it. I enthusiastically skip the more tedious parts of interviewing in these cases.

This works in small companies where somebody you refer will likely work directly with you and your reputation is at stake. This breaks at around 100 people or so. If you refer somebody to big company, chances are you will never work with them directly and your reputation is not at stake. Why not help out a unqualified friend at a cost to big faceless company?

thenanyu2• 5 years ago

I’ve seen it work in companies at scale, though it’s not universal. Teams are still on the order of 20 or so and the dynamics still apply. Beyond that, you’re right — but even at huge companies a lot of exec hiring is done that way.

I got hired into a big i-bank through a couple of Facebook messages. We ticked all the HR boxes but it was a done deal. Happens all the time

TrueGeek• 5 years ago

Long trial contracts to hire

I don't understand these. If I'm going to do this (as a candidate) then why not just do independent consulting / contracting and charge a higher rate?

Only once was I offered a contract to hire and I assumed it meant the hiring manager hadn't yet secured the FTE req. When I asked for clarification he just said "that's how we do things here". I explained that a significant portion of their pitch was spent talking about their stellar benefits when they were trying to recruit me and now I wouldn't receive any of those. He said I'd get those in 6 months. I took it as a red flag and passed.

spideymans• 5 years ago

I much prefer interview styles where the candidate and the interviewer just talk about a technical solution they've solved in detail (challenges, architectural decisions, etc...). It'll become evident fairly quickly if the candidate doesn't know what they're talking about.

quickthrower27• 5 years ago

Except for me there is a half life of about 48 hours on how detailed I can talk about that solution.

This has me thinking that interviews should openly publish what types of question you’ll be asked so you can prepare.

Otherwise it’s prepare for anything, which is 20 or more hours work per interview, and requires me deciding what animal I am.

NiceWayToDoIT• 5 years ago

Point of the interview should be to asses knowledge and thinking process, and many other things. Definitely, it is not easy, as in one hour someone needs to assess that person is not faking his entire working history, and that has acceptable skills for the certain role.

One of the good interviews I had was with few people DB/Architecture/Testing/Coding at the end they had combined overview. Usually when I am interviewing I would allow everything, as I am more interested in thinking process of attempting to solve something than actually giving me some clever solution in extra limited time.

For me it is interesting that many companies have decoupled skills vs. money paid for those skills expectation, and often they would like to have star workaholic developers but only if they could pay them as McDonald employees. What I am trying to say, don't have an interview like you trying to employee in Google if you are are not prepared to pay those people like the Google.

Zababa• 5 years ago

I understand why interviewers do this. They want to get a sense for what candidates actually know versus what they’ve copy/pasted from the web. But this process is stupid for a variety of reasons.

That's not how I understand them. I always saw them as a way to see if the candidate is ready to invest a certain amount of time and energy. A bit like "if you can grind leetcode and pass the X interview, you can probably contribute to our codebase".

nsonha2• 5 years ago

Poorly written blog post. What an elaborate way to say "let me google". Except for hackerank type of interview, I've always been able to google or ask interviewers to help me out.

Just have some communication skill and communicate in the interviews, they want to test that in you too, rightfully so.

kokanator• 5 years ago

They are missing the point.

Coding interview has very little to do with Code!

I hire a lot of developers and the code interview is a pivotal point in the process. This is where I find out how you collaborate, take new ideas and incorporate them, deal with changing requirements, handle criticism etc.

Of course I am validating you actually know how to code but I am really looking for the rest other skills because this is what will make you a valuable integral part of the development environment here.

Trying to throw a 'stump the jock' type of question at a developer is worthless and only proves to show how well they memorize things.

Throwing them a difficult problem that requires them to research, ask questions, collaborate will show how well they will grow and take on new challenges they are uncomfortable with.

caymanjim• 5 years ago

One thing I rarely see talked about is that the people doing tech interviews just plain suck at interviewing. Everyone assumes intent; that interviews go a certain way because someone has decided they should go that way. While that is quite possibly true at FANG, in my experience it's not the case elsewhere.

Interviews at most companies amount to "hey, who wants to/can interview someone next week?" Some people volunteer, and then they wing it. They might do a FANG-style interview because that's what they think they're supposed to do. They might parrot whatever the interview process was when they were hired. They usually just wing it, making up questions as they go.

It's not normally intentional or nefarious. Good engineers don't often make good interviewers. Sometimes they don't want to be doing the interview, and are simply trying to bumble through it. Usually, they have the best intentions, but they don't know what they're doing. No one's prepared them; they haven't prepared themselves (and likely don't know how to). Everyone usually has good intentions. They want to give the candidate a fair shake; they don't want to make the wrong decision; they want to find a good coworker; they want to do their employer a solid by finding the best employee.

I know I suck at interviewing, despite doing it dozens of times. I've had a few regrets about people I've hired, but not many. Whatever failures my process has, I don't think they're too egregious. I've been on my own to figure out what works and what doesn't.

jkingsbery• 5 years ago

As others have mentioned, this is more a sign of bad interviewers than a bad format. Of the companies I've worked at, at least one has allowed googling during the interview, and most de-emphasize all the stuff you have to look up in order to focus on the problem-break-down part of the question.

I think there's too much imitation without understanding in interviewing. Candidates hear questions, and then go on to repeat them when it's their turn to be interviewers, without really understanding what's behind the question. These new interviewers then approach the interview as if they were administering a coding test, whereas what they ought to be doing is facilitating a conversation using the question as a starting prompt.

The other problem that I see sometimes with interviewing is interviewers asking obscure questions. Really good candidates aren't solving the problem on the spot - they've come across problems like the one the interviewer asks, and are using approaches they've already validated in their life experience. When an interviewer asks an obscure question, they are not helping to facilitate a conversation as to whether the candidate can handle the typical things that would come his or her way.

juancn2• 5 years ago

The problem result is not the goal of the exercise, I don't care if you solve it, but rather how you approach it.

Note that I don't use puzzle problems, but more open-ended ones that elicit discussion and architectural approaches rather than simple coding.

When I'm interviewing I'm google for all intents and purposes.

I want to see how you interact, what you're thinking and how it would be like working with you as a team member.

I look for potential and red flags. I try to find out two main things:

- will you be good for the team?

- will the team be good for you?

It's a two way relationship we're trying to build here.

Interviewing is a lot like speed dating, we're trying to find a long term partner in a very small amount of time.

kodah• 5 years ago

Some context, first: I work on infrastructure software. I'll try to define it so it's not so vague: software that is core to the company's platform that has strict performance, stability, and FMEA guarantees. Often the skillset we look for is niche, you need systems skills (broad spectrum, both OS and network) as well as software skills (preferred polyglot; "languages are tools" kind of people).

On one hand, I deplore the runaway game that software has let algorithmic knowledge play on our minds. People destroy themselves preparing for interviews at large firms on exciting teams, only to get blown away because someone threw them a curveball in algorithm or systems design knowledge. On the other hand, I've watched developers copy solutions on one screen and transpose them on another. I've hired engineers only to find out they only know the kind of information we would ask in an interview and how to bullshit.

College will never provide my team the guarantees we need to make a hire, that much is well-accepted. Being from a "top tier" company is no guarantee either. What I do think is worthwhile is investing in two things simultaneously:

1. An apprenticeship program. I entered software (and mathematics in general) without a degree. These subjects can be learned with self-discipline and having a career that gradually increases in complexity is a perfect aid to this learning process. In my path, it produced a generalist software engineer with a specialty in systems engineering. In another, it could produce a web backend software engineer, a frontend engineer, an infrastructure engineer, etc...

2. A certification exam. I mean something orthogonal to Professional Engineering or the Bar exam. Something entirely divorced from colleges that can prove you can negotiate algorithms and data structures. I believe people who are keen enough to figure this out once can figure it out again when the time is needed, however, in most cases your brains will be put to more abstract talents that are non-numerical in nature. Reserving your sanity for then, rather than depleting it all throughout the interviewing process over the course of your career seems to me to be the optimal choice.

Tech Interviews Are Stupid

Related Stories