Ask HN: Is it crazy that software developers have to study for interviews? | Hacker News Reader

Ask HN: Is it crazy that software developers have to study for interviews?

87 pointswppick131 comments

It seems like to get a software job you need a completely different skill set from the work you do day to day (for some roles). This is why there appears to be an accepted practice of spending a lot of time studying for specific interview questions. And, on the employer side, of asking these esoteric trivia questions that the candidate is expected to be able to think through and answer on the spot while talking, while being closely watched, and under pressure. It seems to me these question really give you very little information about how that candidate will perform on the job, and is just a waste of everyone's time.

View on HN

I decided a while ago that I wouldn't study for interviews, and it's served me well. I either know enough to get the job or I don't. Convoluted interviews where I fell on my face weren't necessarily always jobs I would have done badly at, but preparing a "tricky" interview like that with brain teasers and dumb algorithm questions was a strong enough negative signal to tell me I very likely wouldn't like working there much anyhow.

If I go into an interview without studying and fail legitimately on questions that relate to the job (and who hasn't done that?), then it's a good thing because I obviously wouldn't be able to handle the day-to-day work and therefore am a poor fit. :)

Really, to my mind, it's a win-win for everyone.

Yes. If you're not interviewing your potential employer, you either _really_ need a job (no shame) or you're blowing it.

Agree. And if your potential employer is the kind that will make you jump through arbitrary, irrelevant hoops to get the job, then what's working there going to be like? And if working there is going to be full of arbitrary hoops, do I really want to work there? No, I don't.

Then where do you work? Seems like all the ones I've experienced play some sort of game. Even just the grossly inaccurate or over the top job descriptions places post.

Here’s a good place to start: https://github.com/poteto/hiring-without-whiteboards

Thanks! It seems like I haven't seen job posting from most of these companies.

I hate to suggest toxic social platforms but I've had good results with LinkedIn.

I pretty much never have to reach out to potential clients/employers - they reach out to me which gives me leverage and the ability to set terms such as no take-home tests or tricky algorithmic questions.

Maybe give it a try?

your priorities are different than basically everyone else

you are shortchanging yourself or wealth is not important to you, we are not the same and your reality is not relevant to anyone similar to me

Not "different than basically everyone else". Different from you, which is fine, but jeremymcanally speaks for a lot of us.

> you are shortchanging yourself

You seem to have the idea that a job at "that kind of place" is the only real fulfillment of our employment destiny. That seems a bit narrow-minded of you.

> or wealth is not important to you

This assumes that jobs at "that kind of place" pay much better than jobs at "other kinds of places". That may in fact be true, or at least mostly true. (Or it may be that, to get to the stratosphere of income, you have to jump through those hoops, but other places will make you jump through those hoops and still not pay that kind of money.)

Money is important to me. I am a for-profit enterprise. But it's not the only important thing. It's worth some money to me to work in a sane environment with non-toxic people.

Extrapolating that a company with a coding brainteaser interview process unrelated to the job would also have an insane and toxic work environment is incorrect.

There is no correlation.

No correlation between an insane and toxic interview environment and an insane and toxic work environment? I don't expect 100% correlation, but none? That seems rather implausible.

The team and manager dictates what your work environment will be like.

All big tech does these interviews and does match making later.

Smaller companies also just have no guidance on a better interview process.

So, no correlation.

So at a big tech company, you're saying that a technical manager has never spoken to an interviewing team? That these kinds of questions materialized from thin air without any sort of technical oversight.

In the small company case you're saying if there was only one employee, looking to hire you as the second employee. There is no correlation between the one person you work with and the asinine questions you were asked in the interview?

Again I think the point was you are correct that it must be taken with a grain of salt, but to say there is "no correlation" is false. There is no way to prove the impossibility of a situation.

The point of language is to convey a shared concept, is that what you are doing? It seems like we already achieved that, which word choice would you prefer over “no correlation” to convey the same concept that there is not a useful signal to glean from an industry standard interview process

What word choice would we prefer? "Some". As in, "there is some correlation".

The issue isn't word choice. The words express what you're trying to say perfectly well. The issue is that we think you are wrong. Simply choosing different words isn't going to fix that.

I’ll wait for the other person to chime in

The “no” was to emphasis “negligible” correlation

Really? I mean I've worked at GitHub, Apple, and now Sequoia Capital and get paid pretty well. I'd say wealth is a pretty important factor to me in choosing a job.

I'd just rather find teams in those organizations that don't have ridiculous interviews and therefore often times cultures that view success in that kind of endeavor as something to be lionized. That or I want to fail out because I'm not qualified.

I interviewed for two teams at Apple. One had a brain-teaserish interview (not totally that sort of stuff but involved a lot of whiteboarding arbitrary things) and one had nothing like that. I'll let you guess which team I chose and additionally guess which team ended up having a healthier culture. :)

But you're right, my philosophies on this stuff probably are different than a lot of folks, and that's OK. That's why we have different teams, jobs, cultures, etc. I just optimize for things I like, and I hope other folks do the same!

Sure, once your in the club you can be picky. But to get in the club these days means leetcode interviews.

I've never done an interview at a place like that where I've worked (even in my early career), but you're very, very likely correct if you want to get into a FAANG early in your career without being able to "shop" around. My experience isn't universal to be sure, but neither is the opposite. :)

Leetcode interviews are thing everywhere now. The days of getting an interview from medium/large firms because you have 20+ years of experience on your resume are over. A lot of companies use “online assessments” with timed leetcode problems that require presumably perfect scores to even get a human on the phone. They seem to range from comically easy (Amazon) to impossibly difficult (Microsoft). I highly suspect they are outsourcing this and the questions are chosen randomly, as the difficulty varies wildly for identical positions.

Maybe this is a recent pandemic thing, not sure. I started job searching this year and I’m totally blown away by leetcode-ification of hiring process.

There’s a few notable exceptions- Facebook and google will fast track based on resume, and some medium sized companies if you’re applying for a specialist position. Otherwise you’ll be spending nights and weekends drilling all the silly leetcode tricks into your skull.

You sound like someone I wouldn't want to hire.

when the third party recruiter shops my resume to your inbox, you’ll see a qualified candidate that will be pretending to be enamored by your startup’s “unique” vision, thinks earning the privilege to buy 0.001% of the company is the most generous thing ever, and knows all the code words for culture fit by having no interests outside of coding and hiking and you will never know it was vmception on hackernews

Fair point

Trivia and minutia quizzes are pointless, non-value-add hazing ritual business theater.

The only interviews that make sense are asking about common problems, or specific current problems and paying people for their time.

I think the industry has this backwards. All the focus is on writing code and there are so many issues doing that within an interview context.

The interview should be all about READING code. The original reason for writing code during an interview was to filter those who can't code. And so problems like fizzbuzz were created and that expanded into leetcode. But does anyone really think that if you ask someone to read a moderately complex piece of code and they can fully explain what it's doing, they can't write a simple for loop? If you can read code, then you can write code. And reading code during an interview if far less stressful than writing. So you will get much higher signal from the interviews since the stress of writing code during an interview causes many good engineers to do poorly. Or never try at all since they don't have time to practice to the point where the stress doesn't matter because it's rote memory.

Reading code is also better at showing the difference between a junior and senior engineer. If a junior or senior crams leetcode and spits it out during an interview, the result will look the same and you really don't know if they are junior or senior. But reading code is where years of experience can really shine.

And I want to stress again, reading code is so important, I think more so than writing. If you're only good at writing, then you can churn out tech debt filled junk quickly. If you read well, you can see where to add a few lines to get the same result. If you only write well, you copy/paste stackoverflow answers without really knowing what's going on. If you read well, the stackoverflow is simply a starting point you modify or discard entirely because you can recognize junk. Or even that the top rated answer is actually not the best one.

This is a great point. Reading code is such an important skill and how most of an engineers time will be spent. The ability to reason about code that was written by someone else (including your past self) and update/expand it in a clean/maintainable way is a better indicator of success IMO then writing a little chunk of code that solves a brain teaser.

Read code, explain what it does and discuss how you would expand it to add additional functionality or fix a bug. I feel that would be a better approach than most of the current leetcode style interviews.

I highly agree with this. When I was in position where I had to interview candidates this is was the 2nd half of my technical interview. Read a piece of code and going through it with me like you're pairing with Jr. Dev. I still think algorithm problems serve the purpose of filtering out the bottom of the barrel.

Too bad I only have one upvote. You have an excellent point, and one I’ve been mulling over for some time now without being able to put into words. I’m definitely going to give it a try at our next hiring round

I think debugging interviews (fixing existing code) would give a much stronger signal than the leetcode status quo, and also not really require studying since reading and tracing code is something we do every day.

Challenging to make the issue non trivial but fixable in an hour long interview

Yeah, making a debugging question takes more effort than a leetcode question, but it is doable. The company I'm at now has an hour long debugging interview on a single problem, with a few "bonus features" in case the candidate fixes the bugs.

If we were bigger, this might not be sustainable due to cheating though, would not be easy to replace the question.

This is what we do in our interviews. We work on something with the candidate and look for reflexes, thought processes, how they reason about things, how they formulate problems and come up with solutions, what they search for on Google, how they read documentation and repositories. We set up a repo on GitLab. We see how they create issues, how they write code, how they commit, etc. That's what they would be doing.

We also pay close attention to our reaction to them getting something we've been doing for a long time wrong or that took us some time to learn. We pay closer attention to our reaction on them stumbling on the solution we chose.

No, it makes sense. It's in fact the flip coin of some of the main advantages of the industry IMHO:

1. There's a lot of self-taught developers, so there isn't a high bar to enter the industry like in other professions like Engineering, Law or Medicine (and these usually include an apprenticeship period as well, often missing in programming).

2. While I love that we are well paid, that's a huge risk for a company to hire someone and this being a potato hire. So I understand that companies really really want to do their best to only hire great people, however misguided these attempts are.

3. It isn't usually "totally unrelated", it's more like they are testing the theoretical part of things instead of the practical. This, as I said, happen in other professions as well and that's why normally there's apprenticeship periods.

I'm definitely not defending some of the ridiculous, cargo-cult practices of many interviews today (like "esoteric questions"). I'm just explaining why I think it makes sense to have an "entry exam" of sorts in the interviews.

I think some of this depends on where you're at.

Like your #1 isn't really a great comparison. The vast majority of developers are building/maintaining boring stuff for businesses. Most of the time, this doesn't require as much training or skill like a doctor or a lawyer. Sure, there's no law preventing people who didn't pass some cert like the bar or board, but a resume with past experience should be a pretty good indication.

Along those same lines, not all of us get paid a lot of money. Most doctors and lawyers make multiples of what I do (median salaries would show developers being lower than the others). This might be different for the Bay area, but I would also guess the doctors and lawyers make more there too just due to cost of living.

> The vast majority of developers are building/maintaining boring stuff

They are still coding, so the test is supposed to asses their ability to do that.

> Law practice can be intellectually rigorous, but much of a lawyer's work is actually mundane and repetitive. - https://www.thebalancecareers.com/myths-regarding-the-practi...

Seems related? From the Lawyers I know and developers I know, I'd say both are skillful technical jobs that need to be assessed. Totally different skillsets, but both go quite in-depth that you cannot just get a random person and get them doing that.

Doctor jobs just seem way too hard.

"They are still coding, so the test is supposed to asses their ability to do that."

It depends on the test. If you're just doing a simple code screen - that's fine. This thread was addressing trivia questions and testa that don't actually test a person kn the type of work they would be doing.

Do lawyers take 3-6 months off to study for their next position? Are they asked in those interviews to explain things in unrelated areas of law from which they will be practicing? They have an industry standard instead of random (and potentially biased) questions - law school and the bar.

No, this thread is not addressing trivia questions, only normal questions that might seem unrelated to the day jobs and the fact that there is a test at all. The OP asks about both, studying for questions unrelated to day-job AND about trivia questions, and I agree with them that trivia questions are silly and explain the other point.

Almost no developer "take 3-6 months off to study for their next position", please do not distort reality, that might happen to some but def not the norm. I'd say the normal is 1 week to 1 month of studying on the evenings after work.

Lawyers AFAIK is based a lot on reputation, which includes seeing them work, personal recommendations, etc. Is that better than a test when switching jobs?

"Almost no developer "take 3-6 months off to study for their next position", please do not distort reality, that might happen to some but def not the norm. I'd say the normal is 1 week to 1 month of studying on the evenings after work."

I've seen a number of posts on HN where people are taking significantly longer than one month. If the reality is as you say, then that is trivial and the whole basis of the OPs post (and the vast majority of people's responses here) is moot.

Most of that reputation is really past performance and experience on cases. Things like win %. Devs don't have any similarly standard comparison metrics.

The time people will study is based on the ROI of doing well in the interview. Software engineering has huge salary incentive for interviews so people study a lot. Mechanical engineering has mostly flat salaries based on seniority and manager level so ROI for studying for interviews is 0, so nobody does it.

Yes it is crazy.

When I am interviewing a new employee, the last thing I care about is if they can whiteboard some arbitrary algorithm or concept on the spot. This is a stupid waste of everyone's time. I honestly don't even know where this sort of practice began. The only time whiteboards are used around our shop is when we are doing actual work with them and trying to work with stuff we cant fit in our heads all at once.

For us, we have realized that the way we do business does not align as well as we would like with a certain clique of developers who are entering the job market. Determining this fit takes a lot of time and is not something that can be answered over the course of a day, week or month.

My developer interview process for 2021+ works something like this:

1) We find your resume/github/linked-in/etc. and take interest in the fact that you have a respectable portfolio or other demonstrable evidence that you give a shit about the work you would be doing. I.e. don't call us, we will call you.

2) We send you an email to see if you would be interested in a 6 month contract offer with potential for FTE+benefits+options. We briefly outline what we do, who our customers are, what our technologies are, and how we generally do work.

3) You decide you are game for trying out 6 months with us. We onboard you in a few days, and you WFH full-time just like the rest of us (we don't have a physical office anymore). Within a few days you are on our daily standup call and are being assigned issues. You work with other developers and start taking initiative.

4) After 6 months elapses, we have the real interview.

Can you expand upon the interview in (4)?

It is highly variable depending on the individual and how they performed over the last 6 months. It is mostly a conversation along the lines of "So, what do you think so far?" and then we go from there.

Obviously, those who exceed our expectations during the probationary period might receive more tempting FTE offers. Others might get additional contract extensions depending on what both parties are looking for.

> 6 month contract Do a lot of people in high quality positions take you up on it? Accepting a very risky proposition for a 6 month contract for a promise of further engagement seems like a lot of risk. I wonder what sorts of rewards you promise that would make someone in a secure position, doing interesting work, would want to engage with you.

We are more interested in entry-level candidates who are willing to prove themselves, rather than rockstar 10x divas that demand the universe on day one. The 6 month contract is an implicit filter. We look at the work we do as more of a trade than anything. We are essentially hiring apprentices who train alongside masters. We already have enough senior talent. Bringing in more would just screw things up for us at our current scale.

Our requirements for candidates are basically zero. If you have a github account, look like you know what you are doing, and have residency in the US, we would consider you. College education, certifications and other credentials are completely meaningless to us. We are far more interested in work ethic, portfolio, etc. With this in mind, we are undercutting the traditional job market and grabbing some really good talent. The gatekeepers of the past are dead to us now. We welcome candidates from unrelated backgrounds (i.e. individuals trying to break into tech/coding from other industries).

"high quality positions" is quite a subjective label. Everyone in our organization has a title of Developer. We try to not over-complicate things when its not required. Our organization is very small and everyone has to do their part. The most junior developer we have is more than welcome to suggest changes to the architecture of the application (and has done so many times). There are no arbitrary boundaries. Just opportunities.

> We send you an email to see if you would be interested in a 6 month contract offer with potential for FTE+benefits+options. We briefly outline what we do, who our customers are, what our technologies are, and how we generally do work.

It seems apparent to me that you’re implicitly filtering people with family commitments, chronic medical conditions, and probably other groups that include a large number of qualified candidates from consideration.

I’m a married man with a wife and two children at home that rely upon my income. If your company wants me to work for you for six months without benefits, working for your company is not an option for me.

HN previous discussion: every other week for the entire history of HN.

Not sure I agree about that. I can’t recall seeing this kind of questions before, say, the year 2015 or so.

Personally I've encountered fewer "i'd have to study for this" interview questions (red black trees and stuff like that) since 2015 than I did before then. My anecdotal experience is that there's been a trend towards more "practical" coding exercises vs pure algorithms. I've gotten offered (sometimes declining) more take-home things recently too.

My favorite is when they have you do some "homework," then completely gloss over it, act like cold, know-it-all prima donnas, and shove you out the door like they're throwing you out for disturbing the peace. Then, they have a nerve to call back the next year. It's the only time I ever told the recruiter what happened and to tell that prick where to stick it.

Yes. I’d much rather leave money on the table than study for an interview. 20 years ago at the start of my career I might have considered it because academic knowledge was basically all I brought to the interview.

Now if my experience and track record convinces someone I’m a good hire, but my ability to implement something on a whiteboard is questioned? That job isn’t for me.

I’d be very happy to do a code review excercise, or implement a full system as a homework, or describe a project I wrote. But studying for knowledge that would remain in my head for maybe a day or a week? An interview process that selects for that is broken. I don’t want to work for a company that doesn’t realize that.

You don't get it. It's about signaling.

I sometimes hire. When I do, I want people that will do what I say.

For the interview part, if they have the basic competency I want, I couldn't care less about the actual skills of the person: if I later find they underperform, if I can't find a proper role for them, they will be fired. But that's a waste of my time, and also it can create bad blood.

What I do care about is people who I can easily get to do what I want - not what they want, so I can redeploy them as needed.

I don't want them to play with the latest framework: if I say it will be done in perl, it's going to be perl, end of the discussion.

> just a waste of everyone's time.

No, not a waste of my time, a waste mostly of the candidate time. I will spend at most an hour on the interview. The candidate will have spend days preparing.

It's not a bug, it's a feature: a contrived interview process with a lot of hoops to jump and pointless trivia that requires days of preparation beforehand self select for me :

- people who are willing to waste that much time in something that will be pointless later (so either they are gullible or desperate enough, both are fine for me)

- people who will obey and follow procedures as complicated and pointless as they might be.

See that like "proof of work" in crypto - they are demonstrating they will do what I want.

That has yielded me the best employees. The next best are the hires straight from university: unexperienced and disciplined by years of training to do things like homework.

I sincerely hope this post has been written ironically. It may make sense but I really don't want to live in this world.

> I sincerely hope this post has been written ironically.

I'm sorry if it came as hurtful or mean. This was not the goal. I just wanted to share how it works, and why it's done, in the hope it could help others.

> It may make sense but I really don't want to live in this world.

Neither do I - which is why I'm mostly retired, an anomaly at my age, made possible thanks to crypto.

In the early 2010s I was reading a lot of things on HN that I felt were very wrong: mostly people describing the world as they wish was, but not as it really is. I found out the truth by myself.

In the process, I lost a few years not entering the crypto market early enough (my fault for trusting the HN zeitgeist) and I lost a bit of my soul (mostly my trust in people).

Please do not make the same mistakes I did. Don't buy the lies, instead look at the world honestly and without sorrow, so you can change it for the better.

My sadness was in wanting people who will do what you say. I'm just starting my business but if there's one thing I hate about computers it's the way they do precisely what I say.

From what I've seen of the world over my almost 10 years in industry there are very few people who know what they want. The ones who want to hire a tech and tell them what to do usually know the least of all.

Agree with a lot of this. We're not always hiring for creativity. This especially applies to recent college grads, I'm not hiring you to critique the business, I'm hiring you to complete tickets assigned to you, be available during certain hours, and/or follow protocols.

>It's not a bug, it's a feature.

Agreed.

>From your profile;

>You say 'I can't do XYZ because I have kids and a mortgage?' - well maybe you should have thought about the long term ramifications of your actions.

Lol, me child free here.

From what I've seen in other industries, with friends and such going through the process, you rarely have interviews that truly "give information about how the candidate will perform on the job." Instead, things seem to be "what the candidate has done in the past" or, especially if less directly relevant experience, "who the candidate knows"/"do I get along with them?"

"What the candidate has done in the past" is always a good one, and I prefer to start there when interviewing engineering candidates too, but it's very limited! If you aren't already in a job where you're working on interesting, difficult things, you're gonna be more limited in your ability to talk about that!

The knowledge/coding-based interview is something of a potential equalizer there... though in terms of everybody's free time, "nobody studies for them" would be a better equilibrium than "everybody studies for them" ;).

> "What the candidate has done in the past" is always a good one

A candidate answering this question well is a necessary but not sufficient condition to being a good hire. Some people can deftly spout bullshit about their prior experience, coming across as a high-level expert but completely lacking in any low-level ability. I once interviewed a candidate who initially impressed the whole interviewing panel with a presentation on a complex machine learning model they supposedly developed, yet subsequently couldn’t answer extremely basic questions in probability and statistics.

This is exactly the phenomenon described in Jeff Atwood’s famous FizzBuzz article, “Why Can’t Programmers.. Program?” [0] The reason senior programmers can’t solve FizzBuzz is because they’ve only ever been hired based on their ability to bullshit about their past projects, without any assessment of their ability to actually code.

[0] https://blog.codinghorror.com/why-cant-programmers-program/

"Tech Sector Job Interviews Assess Anxiety, Not Software Skills"

https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

>“For example, interviewers may give easier problems to candidates they prefer,” Parnin says. “But the format may also serve as a barrier to entire classes of candidates. For example, in our study, all of the women who took the public interview failed, while all of the women who took the private interview passed. Our study was limited, and a larger sample size would be needed to draw firm conclusions, but the idea that the very design of the interview process may effectively exclude an entire class of job candidates is troubling.”

I don't think it's crazy but it could be considered illegal under certain civil rights laws that bar discrimination based on gender.

This study suggests that consuming anxiolytic drugs before interviews may be a viable strategy to pass them and receive more compensation. I recommend Kava because it is safe and legal in most countries. https://en.wikipedia.org/wiki/Kava

I have always interviewed under the influence of the same drugs I take for recreation. It's really the only honest way to assess a real chemistry fit. I enjoy a 95% conversion rate, interview to offer.

I have a prescription for Xanax, but don’t take it on a regular basis. One of the instances where I do take it is when I have an important professional/social event. I lose a bit of software ability and gain a bit of social ability.

You don't have to study. I never studied and I passed some whiteboard interviews and have a steady job. Sure, higher paying jobs (such as at Google) might have more difficult interviews which require some study but at less competitive companies you can do fine if you have a decent background in logic and problem solving.

Also, I have to agree with the other commenter here that it could be way worse if professional credentialing starts to be required. Then you have to shell out big money and deal with way more bullshit requirements than just whether you can write code on a whiteboard (e.g. boring classes, standardized tests, diversity quotas, etc.)

Does Google really pay more money?

I recently saw a posting for them at the Pittsburgh office. The pay seemed comparable with similar positions in that area. Maybe they just have most of the high paying jobs in CA or don't advertise them.

I don't really know as I've never worked there but from what I've heard their base pay is relatively average but equity boosts the total compensation a lot.

A lot of people say if you want to get a job you have to start solving problems on leetcode. My question is that leetcode is great for someone who wants to crack the interview but does leetcode really helps you become a better problem solver compared to someone who has worked on multiple side projects involving different technologies? assuming the person does have the knowledge of Data Structures and Algos.

I'm just curious to know

You are asking the wrong question. It’s a supply and demand issue. The number of people going into Comp Sci is higher than it’s ever been, and you have an entire global economy willing to also work remotely/cheaper. You also have an entire group of non-stem majors switching over to tech to find careers. Supply has simply outstripped demand.

In other words, who cares if Leetcode means you are good or not, there’s too many of you in general at this point, so you’ll have to do whatever it takes to get the job.

I would not advise a younger person to go into Software now days due to this simple reason.

Hey I totally agree with what you said but I think as individual it matters what the person has to offer like the skills and what sets him apart from the crowd

Like why should a company hire this person

Like if you can stand out from the crowd then you can get hired easily

Maybe but the general argument tends to be that other technical fields have much stricter credentialing requirements. I’d prefer to study for an interview than have to “pay to play” (at least how it would be in the US)

FWIW I don’t personally like them and am general not smart enough to pass them (probably never will be on the level I hear some companies require). I may one day give and try though to pass them though.

Not crazy. Since there is no real qualification or certification, there is no real standard. Having said that, once you know basic data structures and have a solid facility for the stack, you shouldn’t need to study much besides the company.

People in other industries study up on the market, the company, and relevant regulations if they don’t have immediate experience, so why shouldn’t we?

The ideal purpose of a technical interview is not just to gauge whether the candidate has all the skills required for the job (this is a best case scenario that rarely happens), but also whether the candidate has the ability to learn the requisite skills that s/he currently lacks.

If the technical questions asked during the interview are relevant to actual problems encountered on the job (unfortunately, they often aren’t), having to brush up beforehand is a good test of the candidate’s ability to apply their existing skillset to novel problems. However, many technical interviews ask algorithmic puzzle questions that are totally irrelevant to the job; having to study those (and administer those interviews) is a waste of everyone’s time.

In lieu of a formal coding interview, I sometimes like to give a short 1-2 hour takehome assignment that asks the candidate to solve a simple but real problem I’ve faced on the job. The candidate’s response to this is infinitely more informative than any coding interview could be.

I haven't had a legitimate technical interview in over ten years, because I haven't cold applied anywhere in that time, either. The jobs I've gotten in this time have always been through a personal recommendation from a current employee or friend of a current employee.

This is how most jobs are filled. The 3rd party recruiters, the online job boards, the e-applications on the company's website, they're a smoke screen. They are how they get to say they are an "equal opportunity employer".

Most places won't give interviews to 99% of the people coming in cold. They are mostly used as a pool of beards to make the hiring process look open when they have someone on recommendation for a job. They'll pick the 3 best resumes out of the pool and then put them through the impossible technical interview. They will fail and all that is left is the person with the recommendation.

When a doctor interviews for a job, they don't ask them to do a day of "trial surgeries". They just assume they have the necessary skills.

The reason they can do that is because there are national standards for graduating which includes a board exam to test academic knowledge as well as a multi-year paid internship.

There are pros and cons to this type of system. Pros include knowing that anyone with a degree is qualified and maintaining minimum standards.

The cons is that is very much limits supply of doctors and locks out a lot of otherwise qualified people who can't get into a program, often excluding poor and minority folks.

But maybe there is a hybrid? Maybe we as an industry can come up with a test that anyone can study for and take and once you pass it you don't get trivia coding exams anymore. We just assume that you know what you're doing. Like a certification that everyone accepts.

That’s not necessarily true.

Plenty of doctors are idiots whom you wouldn’t want to hire. Nobody just looks at your papers and hands out a white coat.

Most of the interview hazing stuff happens because many applicants can’t handle a fizz-buzz question. Engineers/programmers being who they are like to optimize for whatever nonsense they care about. That devolves into this hunger games nonsense.

You’ll see the culture change as tech becomes more diverse. Many of these quizzes end up becoming ways to objectify bias.

> Nobody just looks at your papers and hands out a white coat.

But that is my point. You show up with your white coat that you earned by passing a series of tests. The future employer is just deciding if your stated skillset and your personality fit what they need. They aren't testing your skills as a doctor, because someone else already did.

> Plenty of doctors are idiots whom you wouldn’t want to hire.

Sure, but someone else has already given them the medical equivalent of fizzbuzz and other stupid generic whiteboarding challenges, so you can skip that for more specific tests of whether they are an idiot that you wouldn't want in the particular job.

> "When a doctor interviews for a job, they don't ask them to do a day of "trial surgeries". They just assume they have the necessary skills."

They have a grueling residency period that lasts three to seven years to make damned sure that they do. Can't imagine that anybody in the software industry is going to want to sign up for that.

I've been on both sides of the interview table and I can't think of a better way to test someone's skills than breaking out a coderpad and having them solve a few problems. It sucks. It's a grind. We all know this. Yet if you're an engineer worth your salt, you'll pass a question like the "Valid Parentheses" question every time without having to study for it.

I'm not going to ask you esoteric trivia questions about the Go compiler. I'm not going to ask you to implement a BST. I do have to see you write something because my team has been burned in the past because we hired someone who could talk a big game but couldn't deliver. We didn't have them write code in the interview.

Answer this: would you hire a welder for your construction job without running them through a couple exercises first to see how good they are?

I wouldn't need to. I expect some sort of welding guild would handle the licensure for me.

I've heard that very basic coding tests weed out most of the worst hires. I had to create a simple GUI calculator in a language I hadn't used before. It was fun took me an hour and I got the job. No study required.

> Answer this: would you hire a welder for your construction job without running them through a couple exercises first to see how good they are?

Well, yes, assuming they were previously employed as a welder.

I’d also assign them to non—essential tasks at first, verify their work... and fire them quickly if they weren’t capable of doing what they had claimed.

Yes, it is crazy but it is not too surprising.

There are many examples of maladapted "solutions" to practical problems in the software business and they tend to propagate in spite of being "disfunctional."

It took a long time for me to come to terms with the simple fact that conducting job interviews (at least for technical positions) is a process that is imperfect in the extreme.

Coming to terms with this fact allowed me to stop seeking 'silver bullet' solutions like algorithm challenges -- which ultimately amount to a plausible (and perhaps even clever) "solution" but does not actual do anything meaningful to remedy the imperfection.

It is theatre. It is a feeble attempt at transmuting a job interview into an Apprenticeship.

So, I don't study for interviews because I practice the fundamentals all the time by writing code at varying degrees of complexity. For instance, a silly side project of mine has me writing my own UIs with canvas. Is this a good idea? Well....

The core challenge is there is the job of understanding the machine and the science, but then there is the task of building products for humans. We only have a good sense of how to measure one and not the other.

The frustration that I have is that knowing the machine and the science is like... less than 5% of the job (and that's being generous). Fortunately, I made a good career in infrastructure where instead of 5% it is more like... 25%... as the architect.

I'm not a developer, so my experience will be different I'm sure.

I never study for interviews, but I do research the company. Not days of effort, but if I want the job then at least a few hours. This is as much for me to make sure I understand the company, and what issues I can see from the outside I might want to talk about. I always make and account and make notes of the sign up processes etc.

If I'm interviewing someone who hasn't even visited our site at all, that never leaves a good taste for me.

Yeah, it's pretty dumb. Not every company use the "reverse a linked list" questions, but they remain very common - especially for junior hires, where they effectively test that the candidate knows how to practice for interview questions.

That particular question is actually quite sensible (/s), it tests whether you actually have some experience coding in C and are looking to get hired in the late 1970s/early 1980s -- it's a "weed out the interviewees who are overstating their experience" question (h/t to Hillel Wayne, who did the research on why the question is used, and has a good talk in which it is the main focus)

It's not even spending a week studying. For the big tech companies, it can be months.

People will study for interviews as long as interview performance has significant impact on your salary, no matter the field and no matter the interview.

When people say that other engineers don't study for their interviews what they are actually saying is that other engineers can't get a better job than they currently have no matter how hard they work. If they could get a better job by showing that they are great at their job in an interview they would study to be able to show that side and get that salary increase. Instead the interviews are just formalities and you get hired and your salary is based on your resume.

I've never studied for an interview. I've never studied for anything. If you know something well through practice and application, that will be obvious. If you don't, then you're probably not ready to work on it. Studying and rote memorization isn't the same as practical experience, and should be obvious to the interviewer.

If you really want a job at FAANG, you may need to study to get past their ridiculous and pointless interview process, but if you want to work anywhere else, just show up knowing what you're talking about from experience.

If you took CS in college, you learned algorithms and proofs then. If you did not take CS, you are probably lost when asked these questions.

It takes time and lots of practice (which CS grads did in college) to learn these things. Once you get the hang of it and are good at using DP to solve these problems, you'll probably remember it for the rest of your life.

And, a handful of solutions will solve most all of these questions. The 'lots of practice' you do in college is basically training you to quickly identify which solution to apply to the problem you face.

As an "old person", I feel like I often have an advantage in the types of interviews they give nowadays, since they frequently involve implementing basic functionality that was relegated to a library or made far easier by some other library, so folks who started after early/mid 2000's may not have ever had to actually build those after college.

It's not nearly as bad as people fear it is when they worry about stuff like this. Most of the interviews are pretty reasonable, a few are weird. Tech companies are trying to get rid of these weird interview questions because it makes it hard for them to hit their hiring numbers.

It seems like your actual problem is you don't like rejection. Just accept that you have a 10-20% shot at any given interview you go on. It's often not you (sometimes it is you) there are many variables outside your control. Blaming the system isn't useful.

You need to ask questions that brings about the intent and ability to learn things. In case of welder, welding technique doesn’t change much and also what he interviews for is exactly what he will do in the job as well. But in software, things change frequently and what you do in job is nowhere near to what you would be asked in interview. I wrote BST and reversing the linked list etc but not once I had a need for them in my job. You need good writing skill to express your thoughts and good understanding on system design

In my opinion, yes, it is crazy.

I would give everyone a home test - program X or Y in one of languages (L1, L2, L3). And I would watch:

a) the overall quality of the code and documentation,

b) whether the person asked about intentionally vague part of my request,

c) how much of the code was taken literally from StackOverflow or other source and whether the person acknowledged it,

d) whether I received the solution from them in the last hours before deadline or a bit sooner.

This, taken together, would tell me much more about that person than a highly technical and esoteric interview.

Can you explain item d more? What does that tell you?

Being organized

Eh. Not quite the same thing but, if I have a writing assignment, I'll probably let it sit for a bit before I send it off. I likely won't send it at literally the last minute but I'm not going to just send it off ASAP either.

People who send their assignments in as late as possible tend to fall into two very different subsets:

* either the procrastination champion who leaves things untouched until the deadline looms, or

* someone who completes the work early, but before committing it, leaves it alone for a while and reviews it later.

Everything else being equal, I would prefer the second type, because last minute rushed work tends to introduce unwanted bugs into the code.

Ofc, the world is full of exceptions.

I think homework like this is only appropriate if you compensate the applicant. It's really no different from requiring hours of studying prior to an interview, and the addition of deliverables makes it feel extra icky to me.

Every time I've seen what an applicant submitted for such an assignment, it's been garbage; I don't think it's a good way to assess candidates.

Edit: a previous employer told candidates to not spend more than 8 hours on these assignments. For a position that pays 100k/yr with 3 weeks of vacation, that's a bit over $50/hr. Needless to say, they weren't giving these candidates $400.

I actually applied this "sieve" with an assignment that could be finished in 30 minutes if you were really competent and 2-3 hours if not. If it went wrong, at least I saved the person the commute time to the interview.

This issue with take home interviews is that the time commitment on the side of the candidate is super high. If every company gives you some variant of this take home, you spend at 2-10 hours on each take home, and you're interviewing at 10-20 companies, it very quickly becomes a full time job.

There are occasions when it's absolutely necessary to see concrete examples of writing, programming, design, etc. A portfolio in other words. Now, this can often be satisfied with work that already exists. Though for programming you're now getting into "what do you mean you don't have open source projects on GitHub?" territory.

These questions that you have to study for and the leetcode problems are all symptoms of a total lack of licensing in this industry. Other engineers, lawyers, CPAs, doctors, etc. all clear some exam and have regular requirements for maintaining their license. Since there’s no trusted third party for companies to assess some baseline of competency, we all basically have to take a license exam and have an interview for every company we apply to.

Serious question: what do you think is the ideal interview? I don't think there is an obvious clear universal answer, and it probably depends on the role and company's needs.

For mobile engineers, I'm a fan of laptop coding interviews where you give candidates a problem and an hour or two to work through it, or take-home projects. I know that people have concerns about the time investment required for take-home interview problems, but I'd like to separate that (reasonable and fair) point from the question of "are they effective at measuring relevant skills".

For server engineers, posing a problem and asking them how to architect a service on a whiteboard seems reasonable.

I'm on the fence about algorithms questions. The pro is that they're somewhat "easy" to grade. The con is it's unclear how relevant these questions are to on-the-job performance. Ideally (with a large emphasis on ideally), these kinds of algorithms questions would help you avoid problems like https://accidentallyquadratic.tumblr.com/. Obviously these kinds of problems still happen at companies that test for algorithmic knowledge, so who knows. It's hard to say without the counterfactual, but it's possible that we'd have more of these performance problems if we didn't test for algorithms at all.

This recent HN convo was very relevant: https://news.ycombinator.com/item?id=26152335. I think there's some validity to a point that was raised: "I would argue that the majority of developers are juggling half a dozen tasks that need to be done ASAP and a simple quadratic solution was fast enough for the use case they had in mind and there definitely was no time to optimize for the case of invisible icons." However, I also think it's a lack of skill there. I'd like to believe that someone who was very algorithmically-minded would never accept that as a solution in the first place. I would almost never allow myself to write a doubly-nested for loop and in general would constantly be asking myself whether or not something I'm writing has the potential to be superlinear, especially if I'm iterating through a list and doing any operation on every element of that list.

As an employer / hiring manager yes, it's crazy. I dont want ANY of my candidates studying for my interviews. It will give me false positives.

Instead I want them to come as they are and show me their real skills.

I've always wondered how is it I Chemistry or biology fields? When you are interviewing for a position, do they ask you to balance a chem equation in the whiteboard or the optimal way to combine two carbon based constructs?

> I dont want ANY of my candidates studying for my interviews.

This contrary to the explicit advice that most Big companies give in preparation for interviews.

For example, my last interview round with Google included an email "Google Technical Interview Prep!" It's about 4 pages of things to study and have effectively memorized before the interview.

Similar prep material is given for Facebook and Amazon.

If you don't expect it, then make that clear to everyone around you, especially your interviewers

It depends on the company and the interviewer.

Some are practical enough to assess whether your knowledge and skills match the specific role they are looking for.

Others (famously Google) would say that they are looking for software engineers in general, not narrow specialists, and thus use more artificial challenges intended to assess the candidate's computational thinking in general.

The problem is that no part of being a serious software engineer is about things our exam systems are designed to test for. It's not about original thinking, think too far outside the box and no one will be able to pick up where you left off, if you can only implement vanilla algorithms without original thinking, well there's a library for that.

It depends on who the job interviewer is. Pre-COVID if it was all expenses payed trip to the left coast for an interview with SV royalty then yeah I might study a bit on the plane.

I always loved a good travel to a nice location (e.g. Seattle) for a few days break and interview in a company of interest.

You can make a sport of it but yeah it's worth it for some top tier companies.

"have to?" No you don't have to study for job interviews. Maybe if you are coming out of college, but you really shouldn't be studying for the interviews. You should know most of it. But I'm guessing there are other jobs it there that all technical questions that require people to study up for before the interview.

ROI for studying interviews is enormous. If you care about salary per hour of work then spending some work studying is the best way to spend your time.

Like lets say I take a year off to study interviews to get into Google and double my salary. Then I work at Google for 4 years. Compare that to working at Median Co for 5 years. In one case I get 5 base years of salary, the other I get 8. So ROI of that year of studying was 3 years of salary, and just keeps on giving. Now most don't need anywhere close to one year since they already know the basics, so the math is more like study 1 week -> get 200 weeks of extra salary, or about $400k. $400k for a weeks worth of work is ridiculously good payoff, which is why software engineers feel they "have to" study.

No big issues here. It's never been easier to jump from a lower paying job to a higher paying job. Just grind for a month and you're set.

The one issue that I can see are the low paying companies with simple work related problems to solve requiring LC Hard problem solving skills. They think they're google when they're nothing.

I last interviewed in 2019 where I was passed on by several companies before my current job. In my spare time I study for interviews, even though I do not plan to interview again for another year at least.

I try to fit in my interview study with general study of trying to have a deeper understanding of the framework, language and programming concepts in general. When I am trying to get something done I just skip over things, but if I am studying something and it makes a reference to, say, anonymous functions, and I don't really have a firm grasp on what anonymous functions are, then I go study that. I also take notes and quiz myself on topics, and sometimes I go back and quiz myself again.

I sometimes get asked for a given work sample home, so I study to be able to put together the kind of state-of-the-art 2021 best practices work sample. Sometimes they say I can give my own code sample, not one to their spec, but I have to keep it up to date and similar to the work sample.

The waste of time is things I only memorize for interviews. I rarely use characters don't need to memorize string to character conversion for my normal work, but I do so due to interviews. Or how to create a multiarray and print a specific element from it. Or how to divide a string into an array of words by the space. These are common things you need to do on 30-60 minute coding exercises, so I memorize them pretty much only for interviews.

I also have been asked about IS-A, HAS-A whiteboard class design of the UML kind so I practice that as well.

Then there are the host of programming, language and framework questions you can get. Or ones about git.

I don't mind much as most of this stuff I find useful, other than memorizing how to convert a character into an integer which is something I rarely do for tickets, but have done more than once on coding interviews. And that memorization is not that hard. I try to fit in my study with a broader study, I am not just doing leetcode at night, not really learning anything. I am studying my language right now, in a couple of months I might go on leetcode and see how my skills have progressed. But I have the time now to spend weeks and months taking my time to study abstract things to get a deeper understanding of all of this, it will be a few months before I get back to learning tricks to sling out 30-60 minute code samples faster. But I have a programming day job that pays OK and is OK much of the time so I am in no rush. If I was unemployed or work was bad it would be a different story.

The scientific method is well known in tech. You're kidding yourself if you think these companies don't randomly hire people who perform poorly on interviews and then compare them to people who perform well. You need a broad sample to draw conclusions. They most definitely have.

I have been rejecting job offers whenever there is a tech interview involving coding assignments, trivias and the like. It has worked fined for me (dev with more than 5 years of exp.) but I can understand that for juniors it's more difficult to reject such practices.

Completely agree. I've found that these kinds of questions select for people with good memorization skills more than for people with depth of experience. I would rather someone could tell me the trade offs between different solutions than solve a brain teaser.

Not Crazy, studying for a coding interview, doing leetcode problems, is in my mind much easier than the actual programming job, programming jobs can be so complicated, so hard, that studying for leetcode and solving such questions on the interview is really the easy part.

There are a lot of indicators eventually, code clarity, thinking clarity, problem-solving, handling edge cases, analysis of the runtime, choosing in between different solutions. If someone has managed to study leetcode problems, and he is good at them, when presented with a different topic he would study it and be good at it. The leetcode problems provides a common set of framework for all companies to measure by, a common baseline for all programmers, a common topic for all programmers a specific line of thought.

The crazier thing is that developers are willing to do oncall shifts without vacation day compensation.

I've only done a handful of Leetcode questions, but to me they seem to involve very little organizational skill. The ones I remember tend to be simply an implementation of a function, eg find the number of turning points in an array, that type of thing.

In my experience the real issue in coding is untangling, or avoiding, spaghetti code.

I'm not sure doing a bunch of quickfire type questions translates into being able to keep a large codebase organised.

they are optimizing against false positives, and find false negatives a tolerable loss.

thats the rationale to make it not crazy, whether this is the best way to accomplish that is not resolved.

“Cracking the Coding Interview” covers this pretty early in the book

My sense is that the current interview practice has high accuracy (people good at leetcode can become great engineers) but low recall (a subset of great engineers may not be good at leetcode)?

Not true. Success in leetcode interviews does not correlate with success or impact once in the job. The current methods have poor accuracy and poor recall. The only reason they are widely used is political gatekeeping. You need the ability to imagine failure or argue that you, the existing employee, are superior, in any interview you want, for political purposes, so the interview has to be complex enough to facilitate this.

Tricky / complex interviews are a sign of internal political arms race and peacocking, nothing else. Absolutely great candidates fail all the time. Absolutely terrible candidates pass all the time.

> The current methods have poor accuracy

Where do you get this conclusion from? How wide does it apply? e.g. I can't agree with you that a "poor" portion of engineers at FAANG are actually great engineers.

I get it from ~15 years experience as a manager across many engineering teams in large ecommerce companies. I’ve seen it literally hundreds of times. Someone absolutely aces leetcode interviews and appears to walk on water with instant solutions to non-cookie-cutter dynamic programming problems, exotic tree / heap / graph data structure problems, word problems that are hard to map to data structure problems.

They join with a big offer and it goes nowhere. They don’t know how to choose simpler methods, do things a bad fast way, be incremental, follow evidence from quick user feedback and only optimize when you really have to. Their output is poor, but because they see themselves as high status due to leetcode superiority, it just becomes a problem for everyone. Eventually they think the issue isn’t their poor output but rather some ceiling they are limited by and they quit.

Meanwhile plenty of other people do terribly badly at the dynamic programming / data structure trivia, but they are great at the actual job. They work incrementally, they are less prone to over-engineering or premature optimizations, they focus on the business impact, all while still writing clean, simple code and carefully picking their battles in terms of significant data structure work or optimizations.

The sheer randomness of outcomes leads to leetcode performance just being totally uncorrelated with success in the role as defined by any measure of business impact or effectiveness.

I mean I hate it.

But to be honest one perk is that it's a filter for intelligence.

And it's nice to know you're working with mostly smart people and not people who are just good at schmoozing interviewers.

How is it a filter for intelligence? For discipline, maybe. Maybe for willingness to be abused by your employer. But how is it for intelligence?

99% or more of the world can't do dynamic programming, even tech people.

;)

If you have to study for the interview, they're not selecting their candidates for intelligence, really, but either intelligence or studiousness.

Yes.

Much like "culture fit", it's a way for employers to weed out applicants that aren't desirable when they normally fall into a protected class.

A decent enough sentiment in this industry refuses to acknowledge that people disavow their biases via publicly acceptable encoding, see all threads concerning diviersity, and Black inclusiveness in particular[0][1]. The flipside to the reverse racism claim is that for a Black person getting into tech, you basically have to hope and pray the interviewer has forthright character, which, IME, is not a common characteristic of most engineers I've met.

Rationality discussion is not a property or trait, its a mutual engagement between participants. That mutuality is a purely ethical artifact, but this industry likes to duck the question when its put to them like this in preference of the ethical legalism that's already running rampant through American culture

[0]https://news.ycombinator.com/item?id=24714502 [1]https://www.youtube.com/watch?v=ouKgUdqZMds

It makes no sense but you should be grateful that the only thing stopping you from being one of the highest paid employees in the world is a few weeks of studying.

Reply on news.ycombinator.com