73 replies
3d3h
I like this approach far, far more than coding tests!
It’s fun. It’s fun in the same way an escape room is fun. It’s fun because of the dopamine you get when the test suite blinks green.
Keep in mind that for lots of people in a job interview setting (even excellent candidates) this is not fun, this is stressful. It may be fun on the job or at home, but the stress of a job interview both eliminates any "fun" aspect and makes even simple tasks more difficult. Just mentioning that to encourage some amount of empathy and understanding for the candidate.
for me cracking the coding interview is stressful
i prefer the bug squash question. i have 20 years of experience. i will probably do well.
a fresh grad might fail. do i care? no. leetcode has benefited fresh grads and is being used to discriminate against those with anxiety and other disorders and those who are older.
i think it is refreshing to try a different interview method, one that benefits those with experience.
I administered bug squash questions a few dozen times. Experience definitely trumped the smartest, most prepared young programmers, because no matter how much they studied, they hadn't really faced a real test suite in a large codebase. We had to rate them on a different scale, because otherwise very few of them passed.
why do young programmers need to pass? nobody gives a shit whether experienced people pass leetcode so give me one good reason why you should rate young programmers differently.
A) I, and a lot of other people, do give a shit whether experienced candidates pass leetcode, and try not to give leetcode interviews unless forced to by HR fiat
B) As an industry and as a society, it's not a good thing to refuse to hire new grads, since that leads to the kind of labour shortages we see in e.g. medicine and pulls up one of the best ladders for wealth mobility. Tech therefore needs some kind of funnel to evaluate candidates with less experience. A test that almost none of them can pass is not very useful for evaluation purposes
it’s not a good thing to refuse to hire older people and most older people do not pass leetcode without significant grinding
I don't think replacing an interview that fails older people that instead fails younger people is a good solution.
What do you think is a good solution?
Number one: there is research on how to interview find it and read it. All comments I've seen here give no indication that the commenter is even aware of it. I'm aware the research exists, but I have not read it (my company trained me in interviewing, and the class mentioned research but I haven't checked to see if it is the latest research that I'm trained in)
If the above doesn't answer your question, then different questions for different levels. You should know if you are hiring a junior, mid, or senior engineer. (you may have different levels), and ask them different questions.
one thing I found interesting is the observer or hawthorne effect. in short, people perform differently when observed doing a task. this means that simply by observing people while they are coding, you might make them perform differently, and come to a conclusion they are not able to code, while if you did not observe them, they might have done well.
the reasoning is that it's ok to pass on excellent candidates. as a business owner I find that a real problem. I would prefer the best, not just people who had time to grind leetcode and rapidly crank out solutions to standard problems you can find online. i think it would be better if interviews erred on the side of caution and preferred to let people through especially if they have experience. you can always fire them if they don't perform. there is no job security in the US anyway.
It is my experience that caution during the hiring process means skipping on possibly excellent people to accidentally prevent hiring a dud. There are plenty of both on the job market most of the time.
In practice firing people is hard at most companies, even if there are no laws protecting people in an individual situation. In principle it can be easy but generally a manager who is in a position to evaluate performance doesn't also usually have unilateral authority to fire someone. And a technical manager telling someone that this person can't code or is disruptive on a team often can't communicate that to the managers with firing authority. This can be out of hesitance, budget concerns, or legitimate communication skills on either parties count.
So the hiring practices that most of the companies I have worked at tend to skip on possibly excellent candidates in preference of definitely excellent or at least definitely decent candidates. This is mostly about risk aversion then gain maximization.
I think you meant to say organizational dysfunction.
The inability to fire someone obviously incompetent is not risk aversion, it's risk accumulation.
I've seen very few people obviously incompetent. As such it takes a while to prove they are incompetent. They do write working code and get it through review. Often the only clear sign is nobody likes working with them - only after you get rid of them do you have concrete evidence that they weren't contributing (that is the team got as much done now since they no longer were stopping their own work to help the incompetent person on things that it is never clear if should have been figured out alone)
How does your comment relate to the topic here, job interviews?
squeaky said that companies are risk averse in their hiring process because it's hard to fire people. I said that companies are not risk averse if they can't fire incompetent people.
You responded that it takes time to determine whether someone is incompetent. Ok, but that just shows job interviews are ineffective at weeding out incompetent candidates, so there's still no justification for the so-called "risk aversion" of the interviews.
I guess I'm not sure why you responded to me rather than to squeaky.
How do you define best, and once you do, how much better than second best are they? What if the best person asks for several million dollars per year (an unreasonably high number as I write this), but the second will accept for $200k (a reasonable number though low if they really are second best). My guess is you cannot tell the difference between the top 20% of programmers in actual day to day work, and probably couldn't tell the difference in an interview.
You misinterpreted my question, because I was asking what saagarjha thinks, not what anyone else thinks.
This is Hacker News I’m on here to complain not find solutions
I thought the point of affirmative action was that being unfair is ok if it is to compensate for a prior unfairness.
We don’t typically do affirmative action by picking interview questions that make things harder for some candidates as opposed to others, though. We consider some questions to be easier for, say, men to answer (“tell me about a time you were asked to demonstrate leadership”) but we seek to remove that bias rather than asking questions that solely focus on things that can only be answered by those who experienced bias (e.g. “tell me about a time you experienced racism that affected your work” is not likely to be an interview question).
I agree. It's not a good idea to refuse to hire either young or old candidates. It's also not a good idea to refuse to hire experienced or inexperienced candidates.
These candidates have, as groups, different characteristic strengths and weaknesses. You need to give them multiple tests to see those. Leetcode is not a good test, but you do have to test a new grad on something, which might mean a vaguely leetcode-adjacent test like "go print this json tree of directories to the console then tell me what you did in your third year of uni".
Yeah my first response to 99% of these kind of interview questions is why? I look at ROI and how working code impacts budget and investment. It pains me to say it but the biggest companies out there have horrible code in COBOL that frankly doesn’t make sense to change it over. Similarly bug squashing usually is how did it pass QA/static analysis/dev ops.
You should have a mix of developers on any project, some senior, some mid level, some fresh out of school. The senior engineers should devote a significant amount of time to improving the junior. Your mix should skew to junior developers just because some developers will decide to switch to management, selling insurance, or some such.
Note that I did not say younger - you will get a few "old" people switching to programming as well, and they start off as junior.
Do I really want a mix of programmers on my project?
That's a very sweeping blanket statement and you're putting a lot of your beliefs on to other people. The smoothest projects I've worked on were always full of nothing but senior developers. But even though that is just my personal experience I know full well many projects benefit from Junior developers. Sometimes fresh perspective and energy are what you want to solve a problem instead of experience and expertise.
For a short time only senior is better. However eventually someone will leave and it takes time to get the new person up to speed. Your seniors will retire and you need juniors trained up and ready to take over. If you are only a short term next quarter thinker you are right, but if you think long term some juniors that you bring up to senior are the better value. (note that this also requires retention of existing people, if your culture is change the team every project there is no value in this - I'm against such cultures, but it is very common in the real world to not value experience on your project)
Of course there is value in bringing in external experts for a short time as well. You don't want to be isolated and not learn from the rest of the world, and of course sometimes you have money for a large project and sometimes you don't and want to fall back the the minimum staff needed to keep institutional knowledge alive.
Last, ignoring everything else, you have a moral obligation to society to build a better world. That includes training the next generation. (and this helps you - when you are retired they will be the senior engineers building the tools to keep you alive)
Just because people in group A are treated badly, that's favoring group B, doesn't mean it's reasonable to do the reverse.
The real reason is you can pay them less and they'll put up with more BS.
Sometimes you want to hire for a potential, as opposed to just experience, sometimes, the reverse. It depends what you're optimizing for.
What is wrong with capitals?
not wrong per se, but they take longer to type than lowercase
Wait, what?
Per letter, capitalization doesn't take much longer, but over the course of an entire sentence or paragraph, having to reach for shift can potentially add up. Sure, it's still small overall, but I think it's reasonable to give the benefit of the doubt to a stranger about whether the extra effort for them to type them is more than the amount of extra effort for you to read it.
It doesn't take longer for me as I have both of my hands on my keyboard and I can hold the Shift without any delay (or noticeable delay), simultaneously. You could even use "caps lock" in which case you wouldn't have to use shift at all.
The shift key is an uncomfortable stretch for my fingers. I can do it, but it isn't comfortable.
They don't if you have two hands!
NOTHING BUT THERE'S ALSO NOTHING WRONG WITH LOWERCASE
try pressing the the Caps Lock key
What's wrong with contractions?
NOTHING. CAPS LOCK IS CRUISE CONTROL FOR COOL.
i don’t need them here, i am not writing a book
I can't speak to anxiety or other disorders but I have a hard time swallowing that leetcode discriminates against the older crowd.
I'm not older, but I was in the industry prior to the leetcode style interview. I've never sat down and "grinded" leetcode but I've also never had a problem with those styles of interview once they became common. Neither have my former co-workers. I have a few friends that are still working, past retirement age, that would crush any problem you threw at them.
In my experience, it's not much different than the whiteboard interview. Sure the presentation of a problem can stump you for a moment, but with a few good follow up questions a solution, however naive, becomes apparent.
I had a mentor early in my career that repeatedly said "There is no such thing as an unsolved problem in computer science". I think that mostly holds true, you either recognize the pattern and implement, or you learn and implement next time.
That all said, leetcode style interviews are the interview version of a "bad code smell" and I'd strongly prefer a bug-squash style, even if it was in a completely unfamiliar programming language. Actually, an unfamiliar programming language might make it fun.
leetcode style interviews discriminate against older workers: older workers don't have time to grind leetcode. they have other obligations outside work. job descriptions require "x years of experience" but then the interviewer dismisses your experience and you get purely evaluated on whether you pass the interview, just like younger people who don't have the experience.
I don't know where you've been doing coding interviews. I'm pretty confident there are leetcode type problems you will have a hard time with and won't be able to complete in the allotted time. I'll share one of my experiences with a FAANG.
My interviewer first spent a lot of time "getting to know me" and asking trick questions, and stressing he also previously founded a startup, then handed me a problem and demanded I find the optimal solution in ~10 minutes and also wanted me to talk while working on the problem. I could not remember the arguments to a function and couldn't concentrate. It bombed.
A few days later I was sent prep material for an interview at a different FAANG. One of the videos was the author of cracking the coding interview solving this exact problem on a whiteboard. It took her more than an hour to arrive at the optimal solution.
So in short: 1) interviewer had unrealistic expectations
2) interviewer wasted time with introductions given his expectations
3) interviewer asked trick questions to determine whether I am a liar even though it was pretty clear from the introductory conversations that was highly unlikely
4) interviewer created an awkward interviewing environment and triggered my anxiety
5) interviewer thought I should be able to code while talking
6) interviewer probably forgot how long it took him to solve the problem originally and probably never timed that
This isn't discrimination on age this is discrimination on dedication to craft. Young people can have obligations outside of work just as easily as older people.
-- signed an old man
you can't call 20 years of experience a lack of dedication to craft...
I don't doubt that at all. But I've also had that on a whiteboard.
Also, it sounds like your interviewer was a jerk. Which seems orthogonal to the style of interview.
one of his colleagues was similar, so all I can conclude is that this particular FAANG has a higher than average number of jerks
One reason they can discriminate against the older crowd is that they are hard for people with established jobs and familial responsibilities to study for. Working for a longer period of time leads to more experience bug squashing. Younger developers are much more likely to not have kids and more likely to have time to dedicate to grinding questions while having less experience with "real work" i.e day to day LOB software development that the bug hunt interviews optimize for.
I think the point is that competent developers can solve the problem on the go. You don't have to study for it.
I don't know, maybe some places do have ridiculously hard problems that you just have to memorize the algorithm for, but personally I haven't seen that. It's more like advent of code style stuff that you kind of just figure out by yourself.
Last time I did the gauntlet at Google I was able to solve all the problems.
However I wasn't as fast as others as I didn't recognize any of the questions and had to work through them. Interviewers expect you to be fast, or at least compare you to people who seem faster. Doesn't matter who studied or not, or who will actually perform better on non-leetcode tasks.
Also having kids is a real issue, it absolutely crushes the amount of time you have to anything besides working.
You don't need to memorize the algorithm for, but if you haven't been exposed to those types of problems you will solve them much more slowly. Younger developers are more likely to have experience with more CS style problems than an older LOB developer who focuses more on writing clean testable code. I don't have an axe to grind in this as I am the younger developer in this situation.
That is your personal anecdote, n=1. Not that your opinion doesn't matter or carry weight, but it doesn't say much more than the comment you replied to.
This approach then selects those who are relaxed. The candidates that have five more interviews at advanced stages, and likely to receive several offers, as opposed to candidates who badly need a job.
The former kind of candidate may be more desirable for the employer :-/
Depends very much on the company. Fishing in the unemployed-and-desperate end of the pool is a real tactic. The odds are good but the goods are odd, as they say.
What's the goal? Increase headcount at any cost?
Find the occasional spark of brilliance someplace where others aren't looking?
That’s it. Not everyone lives a life that leads to a perfect resume.
And for that matter, some people do live that kind of live but still fall through the cracks. Not everyone is lucky enough to graduate during a strong economy, apply to exactly the right jobs at the right time, etc. There's a lot of wasted talent out there that many businesses have little interest in seeking out.
Improve the ratio of compensation to workload in the hiring employer's favor.
The reason someone is unemployed or is desperate might correlate (inversely) with their ability to produce high workload.
Or it might just be a totally unrelated layoff that axed a whole team / org / whatever.
There are lots of good people who are unemployed through not fault of their own. The goal is (as always) to find good candidates. Because many companies have a weird aversion to those not already working, the pool will be stronger by including those with other job histories because it doesn't really indicate who they'll be as an employee. There are great candidates there.
It's just cargo cult hiring.
In my experience, it's just to hire the people that got passed over by other companies but still have some skill. You dont have to pay as much and they might also be more likely to stick around longer if they have trouble interviewing at other places.
I'm stuck in my job and I get paid less than people with lower tenure and credentials. Due to a disability, I don't have the social/political skills to get promoted in my org nor feel comfortable job hopping. It's funny though because every team I've been on has had managers or TLs telling me things that equate to 'you should be at the next level' such as "if you were preforming at this same level on another team you would probably be promoted". I had an interview internally recently and was told that I "found more errors than was expected" for my level.
So yeah, get disabled people like me so we are less mobile, work above our level for the technical work, cost less, and can't get promoted easily.
Finding talent
Even if I have no other offers I’m pretty good at maintaining a calm demeanor in an interview. I think it’s served me well over the years.
Isn't that what companies would look for, though? They want people who can work under stress. If you had two equal programmers, and one who was stressed and the second who was not, any company would pick the second one without thinking.
Some organizations (although admittedly not all) put a lot of effort to offer a creative environment for their creative staff. So they optimize for something else.
A bit like 100m race vs. marathon.
I'm still at university, so despite my previous post having a bit of accusatory tone, I was genuinely curious. At least my profs told us many times that we should be prepare that stress at work is absolutely normal and that if we can't handle it, just drop out.
In my experience, being a workplace or even academia, there's as many types of work environments as types of teachers.
In the end, management (or founders if it's a startup) set the tone and who they end up hiring (thus, who will manage your work). And management is just normal people in the end.
All stress is not the same. Interview stress is actually very different from working stress.
Ask a firefighter who rushes into burning buildings for a living to give a public speech in front of a large crowd of people in a non-burning building. Which is more stressful? For the firefighter, it may be the latter. Fighting fires is what they train for, what they're experienced with, whereas giving speeches is not.
A lot of people, no matter the profession—firefighter, programmer, etc.—have a great fear of public speaking. Likewise, a lot of people, no matter the profession, also have a great fear of job interviews, especially the crazy audition-style interviews of programmers. It's simply human nature, with little bearing on job performance in general. We shouldn't be giving auditions to people who aren't stage performers. Personally, I never work with someone watching me—definitely not a judgmental stranger who will fire me for any perceived peccadillo—nor do I ever have some specific narrow time limit on my work in the range of 15 minutes or so.
That assumes that during regular work, you'd be under stress. If it were the military, then yes, i would agree - working while you're being shot at means you need to be able to work under stress.
However, a lot of people don't do well under stress, and in many corporate settings, there's usually no real source of stress (except perhaps artificial stress induced by management). Someone might work much better in a stress free environment than someone else under a stressful environment, but you'd then easily miss these candidates by structuring the interview to be stressful.
Yeah, I've had a live bug squash interview (SSH into a server where a script is not functioning) and I didn't find it particularly fun. I did manage to get through it and the interviewer seemed impressed, but it's still stressful to do it with someone silently judging you. I'd much prefer take-home assignment and do it at my own pace, but I guess that might be susceptible to "cheating" (whatever you consider it being).
Doesn't a take-home task also prevent any chance to ask questions in the middle? And I mean questions both ways. An interviewee can ask questions about the code base that might be common knowledge to people on the team and an interviewer can ask questions about why a thing happened and gain insight into the interviewees thought processes.
I get that interviewing is a skill on its own, and not everyone has skills that work in an interview that transfer to the day-to-day job but don't most day-to-day jobs have a large communication component?
Suggestion here: leave the room and come back in 40 minutes. Let them debug, fix the problem, and present to you when they're done.
The discomfort and stress is a given in any interview. What I think is nice about this is it doesn’t require you to emanate fully-formed, nicely designed code from your brain on the spot. Instead you just have to navigate the codebase, read it and understand it.
It’s a better demonstration of knowing how software works imo. But I am biased because this sort of thing is one of my strengths.
thanks for pointing this out