Ask HN: Is it crazy that software developers have to study for interviews?
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.
132 comments
[ 1.7 ms ] story [ 193 ms ] threadIf we were bigger, this might not be sustainable due to cheating though, would not be easy to replace the question.
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.
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.
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 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?
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
> 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.
There is no correlation.
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.
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 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.
The “no” was to emphasis “negligible” correlation
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!
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.
The only interviews that make sense are asking about common problems, or specific current problems and paying people for their time.
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.
* 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.
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.
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.
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?
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.
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.
;)
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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
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 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 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.
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.
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.
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.
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
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'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.
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.
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.
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.
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.)
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.
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.