I used to hate it, but have now performed enough interviews of supposedly senior devs with decades of experience.
I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even then, grinding for another half hour with no progress.
I’m going to show some vulnerability… this happened to me this week. I’m probably like a lot of you here: professional software developer for 20 years, have shipped countless products in multiple languages / technologies. Work has appeared on tv and print media multiple times. Have generated millions and millions in cost savings and revenue for employers and clients.
But I totally failed a technical screen.
It’s been a week of reflection as a result. I nearly canceled the interview to begin with because the entire process felt like a cattle call - totally cold, the company had shared no information about themselves or the role. There were ten minutes of rapid fire (“you have one minute to answer this question.”) followed by the proclamation that the next 45 minutes would be spent on “as many coding problems as we can get through.”
Within the first few minutes I was able to describe a general solution to the problem, but over the next 40 I totally struggled to produce a working solution. Now, sitting here I could likely write it in 5 minutes. The problem was:
--I was completely frustrated by the experience from the beginning
--I was in a code editor that I wasn’t familiar with
--I had limited access to documentation
--An interviewer looking over my shoulder harassing me
--I realized that while the problem was simple, there were things I’d just never needed in that particular language before, so didn’t have a complete understanding of what was available to me.
--I focus on design before implementation, where the interviewer just wanted me to jump in and bang out code.
--I realized that the last time I wrote this particular bit of code was 20+ years ago, as a college freshman, and certainly not in the language I was using today.
So I agree with the other commenters: we should all check our premises before we disregard another experienced programmer as as hopeless hack.
I wrote a long blog article this week about what I think the interview process should be, will be posting it soon. There are ways to fix this process.
There's no shame in it. Same thing happened to me last week, and I was furious about it. I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing. We're composers, but we're being tested as if we're live concert pianists. Then companies complain that there's a talent shortage! This hurts everybody, and it needs to stop. For my part, I will refuse to participate any further.
> I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing.
Depends on the job.
I'm currently hiring and the live coding exercise is a must for the position because I want to see how the person problem solves while under stress.
Because stuff happens. My team works on mission critical systems that can have issues that we sometimes must resolve quickly which is very stressful.
If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Maybe that's not true for everyone but I haven't heard of a better filter.
Not every position is like this. But that's the big thing I think people miss. Different software positions require different skillets beyond just tech stacks. And the interview process should measure for the particular software engineer skills needed for that position.
I've also hired people who if you just reviewed their code after the exercise you'd think they were terrible. But I'm not testing whether they are good at coding exercises, the test is a tool to see their ability to problem solve under pressure and to see their level of experience with the particularly tech stack.
> If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately.
Those are two very different kinds of stress.
In one situation you're stressed because you feel like your every action and step is being judged. Every moment you spend floundering you feel is being docked against you, you can't help but worry about how the person breathing down your neck is expecting you to approach the problem.
In the other situation you are a part of a team, you have each others backs and trust each other to make sound judgement calls. You're working together for a common goal rather than judging each others every movement.
Your hiring method sounds like hazing, you're putting interviewees though unnecessary stress to see if they crack. Stress that isn't the same as they would feel on the job, at least I hope you don't also treat your employees the same way.
Exactly. The previous poster doesn't seem to grasp the nature of stress and its variants relative to the social or work situation.
To echo your point, fixing a bug with someone you just met standing over your shoulder clock ticking, is nothing like fixing a bug at your regular place of work.
In an interview, if you don't perform the task well, you can fuck off back to the street where you came from. In your job, you get to ask colleagues, consult previous project code, refer to in-house or external documentation, and calmly analyse to figure it out under your own "in the zone" steam.
Soo...when a mission critical system at your team goes down, you get the newly hired guy with no previous knowledge of your code, put him in front of a dev environment he doesn't know and keep pestering him over the shoulder while he tries to get the system back up?
> Because stuff happens. My team works on mission critical systems that can have issues that we sometimes must resolve quickly which is very stressful.
This doesn't sound like something a new hire should be responsible for and more someone who would eventually, after proven themselves able to, participate in.
Interviews are already stressful; you don't need to add to that by putting candidates into even more stressful situations just for kicks.
To flip it around, would you be willing to let the candidate review the details on all technical employees exit interviews and then ask you about them? Maybe review some completed financial audits from previous years? so they can see how the company reacts under pressure?
> I'm currently hiring and the live coding exercise is a must for the position
It's not.
> because I want to see how the person problem solves while under stress
Why, it's a totally bullshit proposition. The stress of not having memorized some algorithm is not the same kind of stress as a live system going down.
You do it this way because you aren't able to come up with anything better.
Would you be OK with interviewees giving the interviewers a quick coding test? You know, to make sure they won’t be working with people who can’t carry their weight?
Right? I wouldn't feel comfortable working with colleagues who couldn't instantly come up with a novel sorting algorithm to some bizarre scenario I thought of to stump people. So maybe I should "counter" each coding question with my own. It'd be like a shootout. This isn't a dysfunctional culture, right?
Yes depends on the job, but if it's a stressful environment, you need to train for it. OTJ. That's a management issue, not a coding issue.
Otherwuse these exercises would just paint a broad stroke that handling stress is common & generalized, when in fact it's unique and case by case in most situations.
You appear to view stress as a good thing, or, at the very least, an unavoidable part of the job. It seems likely to me that you deliberately manufacture stress by deploying mission-critical systems that have issues. Seems there might be deficiencies in your pre-deployment testing regime -- a stress factory for sure.
tl;dr: If you're a stress factory there's no way on earth I'd be willing to work for you in the first place.
I agree this point is valid, but I think it's much more exceptional than whiteboard interviews are. I've personally never applied for such a job, since I typically work on consumer products at BigCos with a glacial development pace.
People have already hammered you for this, but a Merciless Judge actively looking over shoulder while you're working is a completely different kind of stress than trying to get a fix out the door ASAP.
Only way to code under pressure like that is with practice. I turn into an idiot non-coder in these situations, but I've gotten much better over time, to where I always pass a live coding session. In the real world, I spend a fair amount of time thinking and teasing a problem apart before I actually start coding. This is hard to do in an interview - even if the interviewer says "think about it for a few minutes", they will inevitably step in and offer a suggestion after 30s of silence. It's like you have to code by pure instinct. Which is doable with practice. But it's hugely skewed towards people who have the time or desire to practice such things.
This is why advice for passing the Google/etc. interview usually boils down to: Quit your job for a month and do competitive coding, and you will pass with ease.
This. I noticed that I have gone for over fifteen years through some pretty tough jobs, but never needed to write any Leetcode binary tree problem from scratch in thirty minutes in my work while being questioned. I normally freeze up because I worry about current best practices every step of the way.
In the end, I scored a job with a FAANG company literally because I didn't want to work there. A friend warned me away before the interview for work-life reasons, but I decided to go ahead with the interview anyway as practice and I nailed it. There's no reason to stress if you don't want the job. Another friend who worked there later convinced me to take the offer.
What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills.
>What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills.
Yup. You keep keep measuring that thing..I don't think you're measuring what you think you're measuring.
I am sympathetic to this but I have dealt with very senior candidates that could not demonstrate any coherent thought about a given problem over a whole interview. Others don't get code done but at least they can express a clear understanding of the problem and have an intelligent conversation.
I don't care if they can write the code but I want to see some level of engagement with the problem and some understanding.
So a little more on the interview. I've got a laptop setup with eclipse, all rigged up with an integration test and filled out function signatures. I show the interviewee what to press to compile, and the subsequent failing tests. The code builds in it's initial state, but the tests fail. I also show them on the desktop that the original source is squirreled away in case they fat finger and erase everything (I've totally done that too, lol. Source control is a beautiful thing in the real world). Then I peace out for a few minutes to give them space (I know I'm close to an order of magnitude worse at typing when someone is looking over my shoulder).
Given the negative response we've had in the past about take home assignments for senior devs (their time is pretty valuable, so I try spend the same time they do), I'm not sure what else to do to accommodate.
It's not entirely obsession/neurosis either. Several of those things are valid training/familiarity needs and/or safety/ergonomics/self-care needs.
For instance, I nearly avoided very early carpal tunnel issues in graduate school by entirely relearning to touch-type on the Colemak keyboard layout. Sure it only takes a few minutes to switch to the layout on Linux and macOS these days, when I remember where the keyboard preferences are, but it still takes Administrator access and a software install in Windows.
Even "easy", that's still a cognitive load distracting from whatever the actual question was and starting into the actual problem. More importantly, at this point in my career, it's something that I'm going to see this as an immediate sign that employee ergonomics may not be a concern for the person giving such a test, which may speak to other aspects of the work environment.
Todd, is that you? Sounds a lot like the process used by someone I worked with years ago.
It sounds to me like you’ve done some careful thinking about this, and it doesn’t sound unreasonable. One of my beefs really gets down to the interview process turning into a one-way grilling, dehumanizing the candidate into a “code monkey.” It sounds to me like you are trying really hard to evaluate their technical skills, but in a way that is collaborative.
> dehumanizing the candidate into a “code monkey.”
Bingo.
A hiring process that attempts to convert the multidimensionality of humans to a handful of numeric variables is essentially trying to hire the best drone out there, not the best human fit for the job.
I learn more about candidates from the types of questions they ask me, and their reply to open-ended questions I ask them, than from any technical grilling test.
A dev manager I work with insists that one of the best indicators, along with all the usual things you try to suss out about a software development candidate is whether or not he does any software development in his spare time. Not everyone who's good does, but there's a good correlation between people who would be good at writing software, and people who do it for fun.
So I would take writing software for fun as a plus, but would not take not writing software for fun as a minus.
Pair. I do this. I drive, with my machine, on my setup that I'm comfortable with. They navigate, and tell me what to do.
This gives me a pretty deep insight into how they approach a problem, but also how they interact with others. There's no adversarial element, and it gives them the chance to see me screw up to give them the mental space not to sorry about stupid errors.
The one worry I have about this is that it's more vulnerable to my own biases than a more disinterested process would be, but if I'm consciously aware of how that can play out, I'm in a better place to counter them.
I find trying to describe what I want another person on a computer to do an incredibly frustrating experience. I can't imagine how awful it would be under interview conditions!
It happens to a lot of us and sometimes fear that is just how the industry is. I have heard senior engineers just stop interviewing and often switch jobs via their network/friends.
> I wrote a long blog article this week about what I think the interview process should be, will be posting it soon. There are ways to fix this process.
I really hope that's true. Every solution I've heard so far is unrealistic at best, like using take home assignments, as if no one would cheat or complain about those.
Perhaps it's because you insist on testing their ability to live code on the spot as a performance piece, and misinterpreting that as testing their ability to code. If you're turning down someone who wrote space shuttle firmware, because they "can't do fizzbuzz", then you are administering a terrible test and getting a false negative.
I have 20 years of industry experience. Everything on my resume is the truth. I've worked on serious code, for serious projects, at serious companies. At work, my performance reviews have been stellar.
When I do live coding interviews, I'm being tested with tasks that are utterly remedial relative to what I've done professionally over long periods of time. Yet I flub these remedial tasks. It could be because I'm nervous. Could be because the interviewer keeps interrupting me mid-line, so I can't think. Could be they are too terse, and I can't drag enough information out of them. Could be the problem is slightly more complex than I can accomplish under any circumstances in a live performance, but that I could complete correctly in a closed room.
These interviews are degrading, disrespectful, and they tell lies to the misguided interviewer. What do they think they're testing the candidate for? Why does it matter whether you can code something remedial, live? Is live performance part of the job function? Do other professions do this? We should end this practice.
> If you're turning down someone who wrote space shuttle firmware, because they "can't do fizzbuzz", then you are administering a terrible test and getting a false negative.
Or... large companies, particularly defense, excel at hiding mediocrity in their ranks, and it's easy for someone who produces no or negative work to be handed around rather than fired.
The reality here is that everyone is supposing their particular bias explains what happened.
No one seems to have asked what actually went wrong in the interview. Was the interviewee truly incompetent? Were they nervous? Were they fine at code but terrible at interviews? Was the language or environment unfamiliar? Had they just got off a plane after zero hours of sleep?
Without data, opinions are worthless. And generally, there's too little data about the relationship between interview performance and job performance, and too much unthinking mimicry: "We do this because everyone else does."
That is why I advocate for a hypothetical "bar exam" for the software programming profession. I also posted a question concerning that: https://news.ycombinator.com/item?id=16702389
Going through a series of technical filters is not a problem in and of itself. The problem is that each company has its own set of filters, many times with skills that don't necessarily transfer to other interviews.
With the "bar exam" approach, you only need to pass 1 exam for N number of companies, leverage that to fast-track through a company interview. With the current approach, you need to take N exams for N companies, and return to square one if you fail. There is no extra layer of validation that lets you keep a "ahead" placement in these interviews. Company specific interviews should focus on basic soft skills, and if they mesh well with the team.
I'm an experienced programmer- not yet considered senior level, but have worked at several companies -and having a hell of a time going through my latest job hunt.
I have been applying for jobs for 3 years straight now, and it's telling that the only offers I've gotten were three short term contract gigs- one from a past employer who's already familiar with my work, and two from small studios with a very informal process where they just looked at my resume and Github projects and with that, they were very convinced that I'm the man for their job. I took these jobs mainly to add more skills and to fill up the gaping time hole in my resume.
But for the "regular" full-time jobs at businesses, big or small, local or on the west coast (I'm a midwesterner), I have not gotten an offer. I've been through many tests and live coding going through a lot of things. Triplebyte expects you to be a speed demon, but at least they give detailed feedback on what you did wrong.
So what is with the saturation of applicants and tendency to make the hiring process slower and slower? That's what these coding tests and interviews do, they make the process slower.
It's not 2009 anymore- unemployment is reasonably low, so this current phenomena of rigorous testing shouldn't happen. More programmers need to discover and embrace the power of collective bargaining.
I'm intrigued by the on the spot performance aspect, so I wonder if anyone has performed a skit at an interview. It's a tempting idea. Some people are intrigued by live performance, especially the kind with constraints like this, people like Frank Abagnale for example.
Probably, most likely on the Ali G show. If you know enough inside details on the typical interview pattern at a company this would be easy to do, and you would probably get the job.
The other option is to check references, do credential checks, and simple bullshit screens during interviews, like every other professional interview.
Literally every other profession has this challenge! Programmers are unique only in their seeming inability to realize that they are not unique.
Accountants are not asked to solve double-entry accounting whiteboard problems. Finance professionals are not given take-home banking projects. Only programmers seem to be unable to be reasonable interviewers.
Every accountant attending an interview can produce a certificate from an accredited national group saying that they have taken an in-person, proctored exam on double-entry accounting, which is the 'credentials check' you refer to. There's nothing like it for programmers.
There are plenty of options. Programmers only just have to pick one, or create a new one for all that it matters. For instance, NCEES that runs the Professional Engineering accreditation that every other Engineering discipline utilizes, has a Software Engineering PE. Tomorrow we could grandfather in every Senior Dev with 5+ years experience as a PE and then start requiring it, and encouraging kids to train for it and acquire that accreditation.
One major proctored exam scales a lot better than every company for themselves reinventing an almost proctored exam.
That is because it is an actual __Engineering__ exam, not a programming one. Testing for programming skills in an SE exam is like testing a mechanical engineer's CAD skills. I would argue that the majority of "SE" jobs do not actually entail engineering but software development (or construction), which is only a small subset of SE.
The computer engineering exam has tons of the underpinnings covered, with a whole section on relevant math. Where as the software one pretty much only covers process. The one algorithms or discrete math question they have boils down to just 'what is big o complexity'.
I guess the question is what is the necessary "base set" that shows proficiency enough in learning that you could throw someone at a problem and expect them to solve it. Keep in mind that to keep a PE active there are also lifelong learning requirements.
Certainly what I see in the PE today seems like a good starting base. Having some idea of Big O complexity can be a great place to start when working with algorithms, and certainly from my perspective I'd rather have an engineer with a solid idea of Big O complexity trade-off issues than a bunch of rote memorized implementations of classic algorithms.
Also, don't forget that a lot of discrete math and algorithms bubbled up into the Fundamentals of Engineering test that is the prerequisite of the PE test:
Which isn't to say that the PE can't be improved for Software Engineering to better meet industry needs, but certainly the current PE still stands as a good starting point that the industry could try to hone to a better tool if they wanted.
And? You think that a certification exam provides more evidence than a university degree? (which, let’s face it, most programmers have).
No, this is a made-up difficulty, caused by the fact that programmers think there’s a silver bullet solution to evaluating competency in an “objective” manner.
I don't see how that is actually doable all the time. In my short career I have moved from embedded c / c++ game engine / full stack / DBA / backend. All at different jobs with the previous manager not knowing I actually knew how to do the next job, if they were asked anything other than generic questions I would have sounded like a fraud.
This is not to take away from your point, since I agree with you, but both accountants and finance professionals have stringent licensing requirements which (in theory) could provide a baseline expectation of competence.
That is the reason they get away with not testing them, because they have a universal test they can look to. Software jobs are pretty fluid, so unless we have a massive standard test that cover anything from embedded c to FE with react, it seems that kind of test is out of reach for software people.
Civil Engineering has a huge gamut in specializations and in the last century has seen quite a lot of technological change; programming isn't as special as it thinks it is here. A credential test doesn't have to cover everything, it just has to cover the foundations and get some sense that a person is capable of life-long learning and improvement.
Yes. I told the interviewer he could call any of my past managers, knowing they would take the call, and knowing they’d give a glowing report. He laughed!
Well...fuck that guy. There is really no better measure, assuming you have the basic social skills to see through a con job/scam. I mean yah, you could always be tricked into calling someone's buddy or something, but with any depth or tactful questions that is rarely going to fool anyone.
The other, other option is just refuse to do either. I get all my work from friends I've worked with in the last 20 or so years. I mean if a company insists on these hiring practices, and they continue to get bad applications because of it, the probably aren't going to be around for long anyway.
Yeah we try to have a limit of 4 hours for this kinda thing. We understand that it is the interviewee's free time but when you need to screen 12 people for a job it is not worth a Senior Engineers time for a small startup.
Getting the right team is one of, if not THE key to startup success.
Yet you consider it not worth a senior engineer's time to evaluate the candidates for the next hire, and the presumably with whom they will need to work - productively?
Check your org's runway and be sure to have your resume ready when it gets close to the end. I wouldn't expect take-off.
Sorry I assumed that the word 'screen' was universal. This is the first step, it is a waste of a senior engineers time with a candidate that is not even close to ready for the job.
Yes, I suppose 'screen' is a bit ambiguous. Doesn't seem like a pool of a dozen is the first step. I'd want the Sr Devs involved at least out past the final half-dozen if not dozen -- not for 4 hours each, but at least a chat about what they've done, problem-solving approaches, etc.
The takeaway that's relevant to you is the section titled "Interview outcomes are kind of arbitrary". Specifically, things like:
As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.
If you set up a typical tech-company interview process, and if you equate "didn't pass this" with "complete impostor and utterly incapable of coding in any capacity" (as most people with your approach do), well, congratulations. You're almost certainly rejecting a bunch of qualified people, simply because you're terrible at interviewing them and can't actually tell from your process whether or not they're qualified.
The most generous thing I can say is that it's not entirely your fault. You adopted ideas and approaches from people who seemed authoritative but turned out to be the actual impostors in this situation. But now you have a choice: you can reject that, now you know the problems, or you can double down. I suggest not doubling down.
Agreeing with and expanding on the interview studies... In most cases, the job that one ends up doing has very little to do with what you were tested for in an interview. Languages usually have some sort of approved/well know implementation of common data structures and algorithms. When you are asked to do some BFS/DFS/binary tree work in 45min or less you are unlikely to do that for the job. Someone has already provided an implementation. I venture, you are most likely to see it bought up in your next interview (whenever that is).
The question is how can you test for experience in writing code that is maintainable, readable, 'instrumentable' and contributes to a better system. How often does a candidate refer and defer to a decent third party library instead of feeling they need to (re)implement a well known data structure or algorithm? What have they done to help automate things so they can free themselves and their peers from minutae (aka how willing are they to put more work on machines?). What more do they think they can do. How well do they mentor or are ready to be mentored? Given a sample project, how would they go about running the technical side of things. If they focus on code, you should try to motivate them to expand to other areas (without telling them what they are). How cognizant are they of the ecosystem; or does their vision end at coding + unit test.
Lots of intangibles that cannot be measured with a github profile or a white board interview but probably contribute more to picking out better candidates.
Sure. But, of course there is a difference between having a conversation about the overall trends of a practice versus a small subset of personal experiences. It's also important to define what you mean by "can't do FizzBuzz". Like they can't even do a basic loop or they don't get it perfect, in the exact way you think it should be? Because those are very different as well. I think it's fair to say that if you get a senior Dev in that can't even write out an if-else statement checking for 3 and 5 you have a problem.
> It's also important to define what you mean by "can't do FizzBuzz". Like they can't even do a basic loop or they don't get it perfect, in the exact way you think it should be?
Like literally can't do a basic loop. I'm not looking for 'my solution', I'm looking for any solution.
> I think it's fair to say that if you get a senior Dev in that can't even write out an if-else statement checking for 3 and 5 you have a problem.
And yet, I can tell you from experience that there's someone out there who (at least was on the team that) wrote firmware for the space shuttle that literally can't if-else with modulus despite having a great looking resume. And they are far from alone.
Why didn't you check references? I mean wouldn't you consider it a failure that you got a candidate to the interview table that was so bad? Assuming you aren't making it up, the guy was obviously lying on his resume, that could have easily been solved by checking his references.
References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion. You don't want to be calling the HR department. Also, a secret is if the reference (not HR) only verifies employment, that's a negative review. They are concerned about liability. If it was a good employee, the references have no qualms about saying so; it's the negative aspects that carry legal liability.
You need to ask for those, not just prior companies. My resume has a "References available upon request" at the bottom and I'd happily give them. Is that no longer practiced? It used to be a requirement.
> References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion.
Yeah, right. Personal references aren't worth squat because nobody gives references that are going to badmouth them.
The worst hire I've ever seen had a highly positive reference from a previous job.
Most companies, period, will have a policy of only verifying dates of employment. They don't want to get sued from telling the truth about the candidate and costing him the job offer.
Haha, I'd love to see it if that's true. I love cool approaches to computation. FWIW as long as you can back it up with knowledge of what the relevant tradeoffs are (and don't scoff at a more KISS attitude for doing actual work), you're pretty much guaranteed to get a thumbs up from me if you give an answer off the beaten path.
That's awesome! I'd probably follow up that, since I generally interview for real time, firmware jobs, we try to clearly bound execution time, and therefore frown against more functional techniques like that. But you clearly know how to program well and would most likely get a thumbs up. : )
Admittedly most of my phone-screen solutions aren't tuned for performance; they're tuned to make people scratch their heads.
My code for "detect if a number is a perfect square", though, is O(sqrt(n)) time and O(1) space and uses no floating point operations. Which isn't quite Newton's method, but also saves me having to memorize an implementation of Newton's method and appropriately causes confusion. Here it is in Python, with obfuscation help from itertools:
To me the problem usnt fizzbuzz, its “find all matching subtrees in a binary tree” in 45 min at a whiteboard.
I dont need to hit the book to write fizzbuzz, and i could probably code up dfs and bfs without prep but i dont walk around ready to retake my undergrad algoriths midterm. Especially when i really dont even know what the topic will be.
Im aware that the question i posed isnt terribly difficult and perhaps it does say somethingabout me that i need a bit more time to refresh my data structure to do this at a whiteboard.
But i do want to be clear that fizzbuzz is not representative of the 5+ hour whiteboard grilling ive gone through at nany of these interviews.
The problem with the BFS/DFS questions is that you're playing a forced game of knifey spoony: They expect you to write it in the recursive fashion and then try to stump you with "oh but how does that do on large structures?!" .. Stackoverflow. Then they'll try to force you to do tail recursion.
Said space shuttle firmware engineer probably never had to solve a pop-quiz problem on a whiteboard. It's much more likely that he/she deliberated for weeks about a simple change with the rest of their team, and perhaps even with the person/astronaut they might kill if the change had a bad bug.
Who cares if this person can't solve fizz-buzz on the whiteboard? That's probably not even a relevant skill to the job opening you're filling, or a skill they have ever needed to hone or practice. It's like determining a marathon runner's worth by timing their 100 yard dash.
If I ever need to do another coding interview again, I'm gonna troll the person asking the question by pulling out my phone, googling their question, and consulting the stack overflow post in the search results to solve the problem. And why not, this is how I (and the vast majority of people) will actually get the job done in a real situation.
Developing software requires high level/architecture type decisions that you mention in your first paragraph. It also requires solving many small fizz-buzz size subtasks, which are necessary and demonstrate competency.
A marathon runner doesn't need a stellar 100 yard dash time, but they should at least be able to jog 100 yards.
> Said space shuttle firmware engineer probably never had to solve a pop-quiz problem on a whiteboard. It's much more likely that he/she deliberated for weeks about a simple change with the rest of their team, and perhaps even with the person/astronaut they might kill if the change had a bad bug.
> Who cares if this person can't solve fizz-buzz on the whiteboard? That's probably not even a relevant skill to the job opening you're filling, or a skill they have ever needed to hone or practice.
Thing is, shuttle-style development is also probably not even a relevant skill to the job opening he's filling. Odds are, that job requires something more akin to FizzBuzz ('I want to do something. How do I do it?') than to shuttle-firmware.
The point I'm trying to make is that solving a fizz-buzz-like pop quiz on the board is a very different skill from sitting at a desk with internet access and collaborating with team members to solve an engineering problem, even if they reduce to fizz-buzz-like solutions. For this reason, the whiteboard pop-quizzes are not really useful in evaluating how well the candidate will perform on the job. I've worked with terrible team members that have aced their interviews / exams, and I've worked with amazing engineers who crashed and burned spectacularly in their interviews and do so regularly.
Also, another thing to consider is how this kind of interview encounter negatively affects diversity and the experience of candidates from different cultural backgrounds. If we treat this form of interview a sort of hazing experience that doesn't really inform on their aptitude on the job, what kind of traits does this process _actually_ select for? Would be an interesting study.
That sounds to me like fight or flight response. Happens to me sometimes, and when it does I can’t code worth a damn, in spite of having a decade and a half of experience on the top projects at some of the top companies in the industry. This, in fact, happened to me the first time I interviewed with Google: I bombed that pretty spectacularly. The second time I applied I already had a couple of very generous offers elsewhere, so I didn’t care as much and was less nervous during my interviews, so I passed.
Hence the take home interview. At least at the last company I worked at we began doing these because we could tell that the stress was filtering out some otherwise decent candidates. At least that was one of the reasons, it also gave us a chance to talk about technical solutions the candidate produced in a more stress-free way.
I don't think this assertion that the technical interview is inherently filtering out great candidates is being very honest (you responded similarly to another comment of mine the same way). One quality being tested is "can you try to do the thing that we're asking for?" That's a measurement in competence and the willingness to get something done. If said candidate is saying "this test is ridiculous and a waste of my time!" then my common sense instinct will say that they're probably not a great fit even if they're the greatest programmer in the world. At least on the take homes I've issued they shouldn't be taking more than a few hours. These stories about creating applications that take 3 days are certainly problems and recruiters need to lighten up a little, but I don't think the take home is inherently flawed just by its existence.
Most senior devs have a family, value work/life balance, and currently have another job. I don't expect them to take their work home past 5 while they're working with me, so why should I expect them to do that before I'm even paying them?
Finding a new job isn't part of your current job. It is over and above. If you aren't willing to put in a few hours after work for something not related to your job, why are you even bothering to go looking for a new job anyway? Are you job hunting on your current employer's time?
Almost too obvious solution: do an initial phone chat to filter qualified candidates into a small pool and then pay your final round of candidates a nice rate to complete a take home project. Bonus points if you can make it something that you can actually use at your company.
This is a terrible solution at many levels. Paying someone who isn't on your payroll (yet) needs a lot of bureacracy on both sides (e.g. taxes).
And even if it's paid, it's still a not-insignificant time investment for the applicant. They're probably applying for several gigs and take home assignments would quickly turn into a full time job, and filing the tax paperwork could take more time than the coding.
And finally, assigning a job that would actually get used at a company pushes up the complexity level, the need to understand the context. This would also make me very suspicious about the motives of the company.
In my company, we give a "fizzbuzz" level assignment on the whiteboard (or their own laptop if they prefer). The purpose is to weed out the applicants who can't code at all (makes a surprisingly large portion of applicants). Additionally, we've noticed that the ones who are good programmers will ace these tests.
I don't think that whiteboard assignments or takehome work is a good way to assess how good a programmer is. A 15-30 minute smoke test with a binary result (the applicant can or can not code at all) is good to filter out bad applicants but not to distinguish good from excellent.
The take home exam is quite a bit more of an efficient filter than a blanket phone screen. Anything less than a 20 minute call isn't going to tell me much.
Personally I think it'd be fine to e-mail back and say "sorry I don't have time to work on this with my current schedule, could I do an in-person interview instead?" That's me though, I would hope the rest of the industry is willing to work with people. Even just the response to the e-mail would tell me that they're competent enough to know their time management and that they have limited bandwidth. At some point you need to make a sacrifice of time though. Even if your hotel and plane ticket are being paid for to fly out to the place of business, you need to take that time off to go in for the interview.
I'd prefer to do a lot of that at home personally.
> Personally I think it'd be fine to e-mail back and say "sorry I don't have time to work on this with my current schedule, could I do an in-person interview instead?"
What happens instead is that you just don't ever hear back from candidate.
>I don't think this assertion that the technical interview is inherently filtering out great candidates is being very honest
There are plenty of people telling you the same thing, you just don't want to hear it. Here's a data point. I would never do it unless I was absolutely desperate. I mean about to lose the house desperate. There are just too many other companies around.
I mean if you are trying to pay junior rates and maybe pull a decent mid-level guy, it may be a good tactic. If you are at all interested in top talent, you'll turn many if not most of them away. Unless your company offers something no other company in the area offers, tops generally have no time or patience for that, especially if they just handed you a loaded resume with tons of references.
If you're just a boring ole company like all the other companies, believe me, you're turning top people away.
at least the take home test is similiar to a real world issue. Tons of issues with it but it's better than the live code remotely (live coding on paper somehow clicks well for me)
Yeah, I’d vastly prefer that, but it should take no more than a couple of hours, not days. In fact we use a 1-hour take home to screen candidates, with great results. The assignment is pretty simple, but you can’t find a solution on the internet. We have found this to be way more effective than a phone screen (which we also do, to let the candidate also ask questions early on).
When I interviewed at Google it was 2006 and they had a reputation for rejecting nearly everyone. I was still a student! So I rocked up to the interviews calm as calm could be because I didn't believe for even a second that I'd actually get the job and really, the whole thing seemed like an entertaining and potentially interesting mistake.
I did that with the google phone screen. It didn't help that the interview really took a "well that's interesting" approach and basically killed the interview.
It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. The danger with this is that this is not a real world scenerio of how two people would approach a task or problem. It’s also important to recognize that everyone is different with regards to how they process information. Stress has a real biological effect on how the brain processes information, and who doesnt feel stressed during an interview.
I’m somewhat autistic and struggle to process verbal information. But I try not to share that with people because I choose not to be labeled by it. It’s unfortunate that in our society that we have to conceal things like that.
All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not.
Solving a problem within a fixed time period is the best real world scenario for programmers. No project has an unlimited budget, so no one gets unlimited time in the real world.
"Solving a problem within a fixed time period is the best real world scenario for programmers"
The funny thing is an artificial examination style setup totally freezes me up. I'm a valued contributor and write original technically non-trivial code day in and day out.
The last time I did an interview a few years ago my brain completely locked up. The interviewer was very polite, and it could have not have been any less stressful situation. Yet, somehow my brain knew I was in an interview, and it was time to lock up all that valuable technical information ... somewhere where my conscious mind could not access it.
Which is really weird. Usually at work the occasional unexpected stress put's my brain on turbo-charge, and ... it's so beautiful to experience it, everything has perfect clarity, I know what needs to be done and I just do it so much faster than regularly.
My "on-interview" brain is complete opposite of my "million-euros-are-at-a-risk" brain at work. I have no idea why.
"Plan to throw one away." This was one of the major thesis statements of The Mythical Man Month, by Fred Brooks. It's one of the hallmark texts on software development. I don't disagree with what you are saying - that we need to be cognizant of time and money - but there is a scary shift happening in software where more emphasis is put on time-to-market above all else, where we are boiling the frog of consumer expectations. Millions of people lose their personal financial information in a hack, and the entire population just shrugs their shoulders. I'm left wondering if this would be the case if we put less emphasis on continuous production deployment, and more on the care and quality of our processes and systems.
Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures. The scenario here sounds like it's as relaxed and simple as you can get without it being so easy it tests nothing. Are you assuming the interviewer always yells like he's Sam Kinison?
> Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures.
Yes, and they're troubleshooted by people who are already intimately familiar with the systems they're troubleshooting. Nobody in the real world writes an app for a requirement they've never seen before from scratch in 45 minutes.
> Yes, and they're troubleshooted by people who are already intimately familiar with the systems they're troubleshooting.
So you're asserting interviewees shouldn't already be familiar with simple problems like reversing a list? Come on, give me a break.
> Nobody in the real world writes an app for a requirement they've never seen before from scratch in 45 minutes.
Being asked to reverse a list in 15 minutes isn't even close to "writing an app from scratch". It's not even theoretical - just look at all the people who make it past these interviews. I doubt they would call it "writing an app from scratch". Could you try any harder to misrepresent things here?
> So you're asserting interviewees shouldn't already be familiar with simple problems like reversing a list? Come on, give me a break.
Though it is clearly a simple problem, I've not had to reverse a list in any of the code I've written in the past 20 years. So I am not 'familiar' with the problem. I think I'd be able to solve it pretty quickly under normal work circumstances (even crises), but as many have said here already, working on something you've never done before with three strangers looking over your shoulder is a whole other dimension.
Many here and elsewhere have related the 'brain lockup' effect. Take me as another data point. It's real and it totally wrecks the interview for the interviewee and the interviewers, who lose out on a potentially good employee.
> Though it is clearly a simple problem, I've not had to reverse a list in any of the code I've written in the past 20 years. So I am not 'familiar' with the problem. I think I'd be able to solve it pretty quickly under normal work circumstances (even crises), but as many have said here already, working on something you've never done before with three strangers looking over your shoulder is a whole other dimension.
What's your point? You just want to repeat what everyone else has already said?
And how low do you think the bar should be? What would be reasonable questions that actually still separate people who can code from people who can't, since reversing a list is too hard according to you?
> It's real and it totally wrecks the interview for the interviewee and the interviewers, who lose out on a potentially good employee.
Or they hire someone else who might actually be just as good or better. It's not like companies have an unlimited number of open positions.
> And how low do you think the bar should be? What would be reasonable questions that actually still separate people who can code from people who can't, since reversing a list is too hard according to you?
I'm not saying anybody should lower any bars. Just don't immediately fail somebody who struggles with a simple problem. Don't just automatically declare them incompetent. Help the candidate be the best version of themselves. It's in your best interest as an employer. Try to figure out ways to make your interview atmosphere as realistic as possible. Some of these people who choke on trivial problems may have aced the same test on a better day.
I was responding to the words I quoted from your post. I was not aware that somebody had already made the point that even apparently simple problems may not be 'familiar' to all candidates.
> It also isn't even close to "solving a real-world problem".
It's not supposed to be the same thing. It's supposed to test your coding and problem solving abilities, in the limited time you have. What better alternative can you come up with? It's easy to just complain...
> It looks to me like you are the one misrepresenting things.
Hah, yeah right. If it makes you feel better, sure.
I worked with people who were hired with "can you do the job?" test and with people who were hired by "everything is wonderful, you are a special candidate that we just talk with" test.
The second group universally cannot perform under production pressure.
No projects are budgeted to 45 minutes. The real world scenario for such limited time is debugging in production issues. It is a completely different scenario. The people who jump in are mostly those who are familiar with the services or application that are showing issues, those who have a clear understand of the architecture of the company, those who have skills on their tech stacks and know where to look at and how to analyze, etc.
> It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period.
Of course, you have a limited amount of time to interview people. Please let me know when you figure out how to give someone an infinite amount of time to answer questions during a 1 hour interview.
> The danger with this is that this is not a real world scenerio of how two people would approach a task or problem.
That doesn't mean it's not a reasonable way to test basic skills. It's even too easy to test that by itself. What good alternative do you have?
> All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not.
How exactly would you structure a 1 hour interview so that it's not, "scrutinizing them for what they are not"? Or are you just having fun being preachy here?
I realize that you’re doing the best that you know how given the time pressures you have as an interviewer. There is no perfect answer to this problem.
Here’s the thing though, you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. When HN developers are telling that Test A is a bad proxy for developer competence, perhaps, just perhaps, you might consider trying to improve it with the advice given.
The upside of being able to accomodate developers who “lock up” in stressful interviews, is that you now have access to great developer that are (according to your competitors) “impossible to find”.
A lot of that's true or might be true, but how do we improve things?
> you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent.
That's true for any non-perfect interview process at any job. The problem isn't that people don't know this, it's that it's hard to accurately measure who's good.
> you might consider trying to improve it with the advice given
Hah, as if the advice is something amazing! Which of these pieces of advice could we use that wouldn't make things worse in some way and also have a chance of being accepted by existing coworkers and managers? There's some great pie in the sky ideas, but nothing without serious issues.
> Pete Holiday, an Engineering Manager at CallRail in Atlanta, used to use homework as part of job interviews before realizing that he was ruling out good candidates. Some told him they didn’t have time for homework. Others may have never gotten to that point. “It’s way more inclusive to just have someone come to the office and talk to them,” Holiday said. “You’re not counting on them having time, or a computer at home. We have candidates with sick family member, single parents. Without the homework we can cast a wider net.”
So is homework worse than whiteboarding onsite? Who do we believe, some article or the crackpots here?
I wasn’t referring to the in-office vs. take-home aspect, just the “stress test” nature of the white boarding test. (And I was admittedly unclear about that in my post and I’m sorry.)
Think of ways you can de-stress the candidate while extracting useful information. Ideas:
1. Have them bring something they wrote with them and describe it in the interview. A lot of developers will “come out of their shell” when they start explaining something that they worked on.
2. Show them some code and have them explain it to you. I had a manager open a C book once and had me explain some code.
3. Pair program on a problem that the interviewer doesn’t know the answer to. This situation is a lot more like a true work situation.
One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts. If you can fathom the idea that they can drive a car (at all) it seems like it is much more enlightening to hear about how they organize a schedule, clients they have picked up, problems they have solved...how they react and comment to situations you pose to them,etc. I guess the key here is to do this conversationally, and not like you're grilling them. Or you have to be a good question asker and a good listener..but if you are, or can become one, I 100% believe you can get the information you need in a humane and efficient manner. But even as I type this, I'm wondering if the ability to read people is why this so hard for software interviewers...or maybe it's for lack of that simple skill that our industry has resorted to silly proxies like fizz buzz, etc.
> One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts.
That's what people do, or should be doing, along with the whiteboarding. I don't think anyone just has them do fizzbuzz and that's it, like you seem to be implying. That won't even fill an entire interview slot.
> it seems like it is much more enlightening to hear about how they organize a schedule...
Sure, and that's also something you ask about, but that doesn't weed out the people who can talk the talk but can't really program, who do exist.
> But even as I type this, I'm wondering if the ability to read people is why this so hard for software interviewers...or maybe it's for lack of that simple skill that our industry has resorted to silly proxies like fizz buzz, etc.
I think it's because people want real evidence of skill, which is pretty easy to detect via whiteboard in most cases, not just the interviewer's gut feeling.
The amount of times I've heard interviewers go "Oh I had this super experienced guy who but in the interview he couldn't even do some simple programming problem". To me that is a failure in the interview process. I've seen this when I've interviewed people. If people don't do well when their resume implies that they should, I'll discuss it with them and say we want to get some kind of confidence in their abilities. Then work out a way to do that. This has worked out really well in my experience. I've ended up with devs who are quite different from me, one person of note (who we employed), was much slower at solving problems but far far more methodical and exhaustive in approaching problems and often notices very subtle details (which is a good thing in firmware development!).
The only way I could see that scenario could ever occur is if the candidate outright lied on his resume. A quick solution is to check references (call the school said person graduated from, call references, call references via their company line, etc).
Sounds like the interviewer didn't bother checking references.
The majority of shops that firmware devs come from (and particularly defense) have a policy of only verifying the dates of employment and nothing else.
References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion. You don't want to be calling the HR department. Also, a secret is if the reference (not HR) only verifies employment, that's a negative review. They are concerned about liability. If it was a good employee, the references have no qualms about saying so; it's the negative aspects that carry legal liability.
You need to ask for those, not just prior companies. My resume has a "References available upon request" at the bottom and I'd happily give them. Is that no longer practiced? It used to be a requirement.
In my experience, candidates who have experience in dev work but could not pass our interview tests always end up in a dev role somewhere else shortly afterwards. Even some of them go on to find much more success.
Either there are a lot of companies which employ unskilled developers who cannot even code fizzbuzz, or interviewing is not a great way to understand specific types of people.
We have to separate whether or not someone doesn't know how to do a job from whether someone doesn't know how to interview.
This is one of the biggest things I try to guard against. Some people just interview better than a lot of other people, but that doesn't mean they do anything other than interview well.
Oh totally. Fizz Buzz shouldn't take you the whole 45 minutes, so the remainder is just a conversation where I dig down in their experience on a hunt for bullshit.
I think FizzBuzz is about as hard as I would make a technical interview. Maybe some basic questions about database design; what's an index; what's an array, etc. The dig down and hunt for bullshit is the most effective way for a tech person to interview another tech person in my opinion.
This is always my approach too. Pick a few elementary questions about a technology and ask a developer how to do them. Simple stuff, like how to build an array with integers 0-5, or iterate over a map.
I agree w/ you here. And I think a lot of people have some personal experiences encountering this kind of situation. It seems baffling, right?
And yet, you have to really wonder ... what did that person do writing firmware for the space shuttle? Did they really do that? Or did they somehow lose their mind after they left and now couldn't do a simple set of modulus operations on a FizzBuzz test? How can that happen? Even reading this kind of thing makes me totally scratch my head.
Brain freeze under interview conditions? One thing that I have noticed is that taking in an interview seems to engage a different part of your mind from coding. I get quite into the flow of chatting, then have to jump into code. Its quite a context switch.
Plus the pressure of someone staring at you.
Then you feel stupid for not answering straight away.
The you get self conscious and start doubting yourself.
What was the question again?
I don't think there is anything especially unusual about it at all.
Off the top of my head the space shuttle firmware was written by a team that adherred to a very systemic process to ensure it met the spec/reduce the number of bugs, it was often cited in old software engineering papers/books in the time period as the best organization in the world, IIRC in terms of software engineering measurements like defects per lines of code. It would be important to know if someone came from that at the beginning of the space shuttle program when they were creating the standards for work, starting out or if they came on later after the process had been perfected.
I worked in a different contractor in NASA/Clear Lake at the time but even before I read those papers the organization responsible for the shuttle firmware was held in the highest regard.
I avoid doing interviews, but I've suggested fizz buzz a few times to people I've worked with because it's so simple but once outside the environment of your usual IDE seems surprisingly simple to screw up.
Whenever I've suggested it a usually more junior guy has scoffed at how trivial it is... I'm yet to then have one supply a complete and flawless solution. These are from people I work with, respect and happily rely on to be able to code. Their recognition that the problem isn't so trivial for themselves is the only thing I've got out of it - I'm no closer to understanding if it's just a poor test or not.
There first time I came across the problem was as a candidate and I screwed up the upper bound of my for loop just because I was slightly thrown by starting from 1 instead of the almost obligatory zero. Naming things, caches and off by one errors.
My worst candidate experience was only a couple of years ago when they wanted me to reason about booking cinema tickets over the phone (like it's the 90s?!) I've never booked cinema tickets and I think they thought I was joking, but they went at me for at least half an hour on what users would need to supply other than location, film title, date and maybe time, to begin the process of booking tickets. Why they didn't just tell me what attribute they were after I'll never know - eventually they just wrapped it up.
Historically, and if we're talking about someone with 30 years programming experience, this history is very relevant - programming has been a popular field for smart but antisocial/unsocialized nerds who had very few if any friends growing up and have spent much of their life alone at a computer.
For a person with that background, simply sharing a relatively small private room with a total stranger can be overwhelming. It doesn't matter what trivial test you're giving them, if they're not able to think. The test is failing to actually determine if the person can do the technical part of the job, instead it's testing how the person performs in close quarters shared with unfamiliar people.
The whole giving homework for technical vetting is a great way to get around this class of problems.
It's not like you forego the in-person interview and don't learn what you can from that. The point is, by including a take-home portion of the technical interview you can get a better sense of the individual's technical abilities.
If, in addition to what seems to be a technically competent individual, you find they don't perform well in-person, then you take that data and weigh it against where your priorities lie for the position.
There's a huge difference in knowing "technically great, performs poorly with an audience" vs. "technically poor, but we only tested them with an audience".
Furthermore, it's not uncommon for people who experience anxiety during the in-person to loosen up as they acclimate to the office environment and their peers. These people can actually be some of the best contributors, and it can be a very costly mistake to misjudge them. This personality type tends to be quite loyal and averse to changing positions, because the whole process of interviewing and acclimating to a new environment is so stressful to them.
You seem to have a chip on your shoulder in this discussion, are you having a bad day?
Not at all, I'm enjoying myself and the debate (while finding it kafkaesque that people are finding ways to defend failing fizzbuzz on an interview). How are you doing today? That might be the only legitimate point I've read in this chain so far - if you hire people too socially impaired to write fizzbuzz, they'll be less likely to job hop.
Now we're tacking on an additional aspect of the job that we didn't know about before. If the job requires a social interaction with people outside of the company then, of course, it becomes a factor. Let's not be silly in an effort to just be right and prove someone else wrong.
I know several really, really good programmers with pretty intense anxiety. Automatically ruling them out because of a poorly-formatted interview process would be a big mistake.
I mean, they're people. I'm still close friends with a few of them, and I didn't like some of them. It's no different than working with anybody with a disability or an illness (or kids, or elderly parents, or any of the million other human things that can make you a less-than-full-functionality worker bot) - you make the necessary accommodations, work around issues when they arise, and live with it. Specifically, it involved toning down a bro-y, combative work environment (which was a change that I really appreciated).
I worked with a guy who had pretty bad autism and social issues. He was a great guy to work with, incredibly smart and a really nice guy.
He wasn't going to come to any works nights out or even lunches and like you said certain accomodations have to be made, e.g. access to a private quiet room for him at certain times... Able to work from home when he had to etc.
His father had to go to his interview with him, luckily the company allowed this. We have since gone our seperate ways but wherever he is working now got a great developer. I'd happily work with him again.
You could extend your attitude to any sort of disability couldn't you. Why hire someone in a wheelchair, when there is someone who could walk up the stairs in half the time?
You can take the guy who starts frothing at the mouth when you ask him to code fizzbuzz, I’ll take the wheelchair guy who can code fizzbuzz during the interview. Deal?
In your head and the head of those with extreme anxiety it is quite different. You're meet people who might be nice or not and chat a bit, you answer some questions, maybe there's a free lunch involved, you either get a job offer or you don't and you continue your search, and your life continues on without the sky collapsing
You could say that for almost any job, but somehow you don't see the same hyperbolic whinging in all of those fields, do you? And your claim isn't even true. It's very similar to the kind of code discussion you might have on the job. "How would you solve this?" "What if I try X, Y, and Z?"
This whole thing reminds me of a shitty superhero spoof movie from the 90’s - Mystery Men - one of the characters’ superpower is that he can turn invisible when nobody else is looking and he is naked
Not if you can find others who are just as good. And what's your better suggestion for filtering out people who can't code and not filtering out the good ones with anxiety?
Take-home tests. Lower-stress environments for coding tests - working on their own hardware, working remotely, no panel interviews, no actively combative/aggressive interviews. Also, cool aspect of that: all of these options will make the interview process more appealing for everyone. And if the justification for angry/combative/aggressive interviewing is "well, that's how our culture is", I would say the company has a bigger problem to fix.
But people are already crying over take-home tests being like working for free for the company, and then there's no way to prove they aren't cheating, which is a showstopper. That by itself is definitely not a "better suggestion for filtering out people who can't code".
> all of these options will make the interview process more appealing for everyone.
No for people who can competently handle an onsite interview and don't want hours of extra work at home.
> And if the justification for angry/combative/aggressive interviewing is "well, that's how our culture is", I would say the company has a bigger problem to fix.
Maybe you being so disingenuous makes you feel better, but interviews aren't "angry/combative/aggressive" just because someone asks to see some code on a whiteboard.
I've participated in a lot of interviews on both sides of the process.
In my experience, the whole process goes a lot smoother when there's a take-home exercise. It turns the in-person interview portion into a technical discussion about a recent mini-project unencumbered by NDAs and trade secrets.
If you can't quickly determine if an applicant "cheated" on the take-home exercise through a simple discussion, then you may want to recuse yourself from performing interviews.
If an applicant can't make enough time for an appropriately scoped exercise, I think it's likely they're unqualified or they don't value the opportunity enough to make time. Those are undesirable qualities the recruiting/interview process is intended to filter out.
I think you should consider that most interviewees expect to be asked any question from their entire work history which doesn't leave much room for anything else. It's probably worth separating the problem-solving interview and the techno-archaeological trivia game into separate days.
I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even then, grinding for another half hour with no progress.