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

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.

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.

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.

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.

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.

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

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.

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

"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.”

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

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

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.

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?

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.

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.

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.

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.

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?

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.

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.

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

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.

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.

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.