7 ms·

To everyone praising how good this challenge is, calm down. There's nothing great about making somebody sweat for 3 hours during an interview. It's even worse i

To everyone praising how good this challenge is, calm down. There's nothing great about making somebody sweat for 3 hours during an interview. It's even worse if "someone got so frustrated that they threw their laptop on the floor" like the top comment claims. Yes, it would be great to avoid hiring people who have a bad temper and tend to throw tantrums when nervous, but, then again, it's beyond me why anyone would need to prove they can cope with such pressure without breaking down. We're talking about a desk job here, which requires writing good quality code according to some requirements during normal working hours, not disarming a bomb with a timer attached to it.

theamk 4y ago
If "3 hours" is "such pressure" for you, then maybe some teams are not a good fit for you? For example, I have broken the build in the past - and this prevents everyone else on your team from merging PRs. In this case the expectation was that I fix it "soon" - once I finish my current meeting/lunch/conversation. If someone is prone to breaking down from pressure given 3 hour deadline, they would have a breakdown right there.
- fzeroracer 4y ago
  Generally speaking if your build process is so fragile that one person creating a breaking build results in a chain of failures and a pressure crunch then that's a work environment problem. I would consider that sort of thing completely unreasonable and consider finding a new job immediately. If you find yourself in that sort of thing frequently then perhaps you should reconsider normalizing it and instead push for actual fixes. You look at the issue and say it's a personal issue. I look at it and see a dysfunctional development environment issue. Now this doesn't always hold true and sometimes devs have to be held to higher pressure environments (such as having on-call duties): but those kind of things are usually better compensated for and called out as part of the job duties.
  - vimwizard 4y ago
    In an ideal world, no one would ever have to work under pressure, and while some people in this industry don't, many (I would bet a majority) of people do or have in the past. This seems especially true for startups trying to break into a market with competition. Either you have been lucky with the places you've worked at, have sifted through tens of shops to find a good one, or have very little experience in the industry. I really do hope that none of my assumptions are true and that one day I can find a functional, low-pressure team to work with.
    - fzeroracer 4y ago
      This goes back to what I said earlier: If the work environment is dysfunctional, then you should either work towards fixing it (especially if you're a senior engineer) or work towards finding a better job. Software engineers are one of the few career paths afforded the ability to do so and it would be better for us as a whole if there was less normalization of awful development practices under the guise of 'everyone else has experienced this or does this'. This goes doubly true for startups in my opinion because rushing things like this and having a shaky foundation just adds another point of failure to your organization. Remember for every startup that succeeds, multitudes of others fall flat on their face due to a build up of problems.
  - KerrAvon 4y ago
    Even in the best environments, stuff happens. If you have a central enough role in a large enough environment, you will cause pain for a ton of other people every once in a while, even if it’s not directly your fault. If you have a process that completely prevents all fuckups that an engineer could possibly cause, you either have a relatively small leaf node project or one that is low productivity. That said, I wouldn’t necessarily give this question to the most junior candidates. Coping with a large existing sourcebase rapidly is a set of learned skills even if it’s just cargo-cutting a solution like this.
- jseban 4y ago
  Yeah a shitty working environment where people are constantly stressed, is not a good fit for me.
- newaccount74 4y ago
  I agree with you. Sometimes stressful situations arise, and there is nothing you can do about it. Even if you have the best QA process in the world, and people can't break the build because you can't merge code that doesn't pass the test suite, at some point you are still going to ship a bug to customers, and even if your manager is the nicest person in the world it will be a very uncomfortable situation once you realise that your bug is losing customer data. If you can't deal with an occasional stressful situation, life is going to suck for you, because there are always going to be stressful situations. Being given 3 hours to add a minor feature to a pretty run-of-the-mill C program really shouldn't be an issue to anyone who is familiar with C, assuming the job asked for experience with C. Sure job interviews are stressful, but if you can't calm yourself down in 3 hours and do something that would take an average C programmer maybe 30 minutes of time, you probably aren't a good fit for a job where people are going to rely on you.
ramraj07 4y ago
What’s your alternative? This is an alternative to leetcode vomit at the least. I agree this question isn’t 100% inclusive but then no other method I know of is; at the least the only thing to worry here is people being frustrated or getting anxious. This can be mitigated by being nice and reassuring them that even a suboptimal solution is okay. As others mentioned, 3 hours is generous and probably accounts for people freaking out and then cooling down.
- mihaitodor 4y ago
  > What’s your alternative? I didn't comment here to propose an alternative, just to point out that the proposed approach isn't so good for some people, including myself. Since you asked, maybe people should stop looking for the one true way of interviewing and realise that they're hiring actual humans, not robots. The hiring process in this industry has become this lazy meat grinder which most people with actual decision making power swear by while bemoaning the lack of diversity (and I don't mean just gender). Some day, perhaps the industry will move towards more inclusive approaches.
jseban 4y ago
I agree with you completely. But other desk jobs have management that actually understand and organise the work, not just make people sweat.
rootlocus 4y ago
> it's beyond me why anyone would need to prove they can cope with such pressure without breaking down. Where's the pressure? You have a piece of code, all you need to do is read it, understand it, make a (possibly) trivial modification. That's exactly what you would be doing (or have been doing) every day. You don't have to explain complex algorithms on a whiteboard. There are no high stakes. You can leave whenever you want. Last time I had to do something like this I was allowed privacy, internet, headphones.
- chii 4y ago
  > Where's the pressure? the pressure comes from the context - you're in an interview situation, faced with a previously unknown task (presumably you haven't done something similar before). The result of this "test" determines your candidacy in the job (presumably you want or need this job). It's like asking why a bomb defuser feels pressured.
  - rootlocus 4y ago
    > It's like asking why a bomb defuser feels pressured. The stakes and environment aren't even close for this to be a meaningful comparison. A job interview will always carry some degree of pressure, no matter the circumstances. What I fail to understand is why would someone feel more threatened by this scenario as opposed to, say, answering a barrage of technical question or solving algorithmic problems.
    - db48x 4y ago
      Yea, the pressure is almost always in our heads; most interviewers aren’t taking any pleasure from torturing their candidates.
kdtsh 4y ago
I can only hope that an employer seriously using this in an interview is looking at how someone codes, not necessarily that they get a result in 3 hours; I can also only hope that they explain this to the interviewee. At best, assuming no prior knowledge, it tests an interviewees understanding of the broad structure of a given procedural programming language and their use of whatever tools are available to them on the day (hopefully this at least includes coreutils). It has to be treated as a kind-of-realistic, fun challenge on an existing code base; otherwise it is meaningless. Stories about someone so frustrated they threw their laptop on the floor are genuinely sad. Like, what are people trying to achieve with a test like this if that is a possible outcome? No one would expect a solution to this in 3 hours under normal conditions, regardless of whether someone can push one out - I got something going in an hour, and I have no idea what the hell to make of the code base now except that a) it builds and b) it works according to the fairly vague parameters of the task, i.e. input `mult age 10` to your telnet session and get 380. Regression testing be damned, especially considering there are no parameters for testing (does that 3 hours involve rewriting a bunch of Perl to support the interviewee's hacky changes? It takes a while to run `make test` ...) Other commenters are saying that it is outrageous to expect someone to put in 3 hours work, without pay, to produce a meaningful result. I agree, as this is notionally their profession, and people are not generally in the business of handing out their work for free. That being said, I haven't had to deal with Leetcode in my career (yet) but from what I've heard it sure beats that.
- mihaitodor 4y ago
  > That being said, I haven't had to deal with Leetcode in my career (yet) but from what I've heard it sure beats that. Lucky you... I'm at my 8th job now and Leetcode-style interviews pushed me to the point where I ask up front if this is part of the interview process, because, as stated on my LinkedIn, "I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming". If that's a showstopper for them, then they need to find someone else.
  - kdtsh 4y ago
    I have great respect for that. By all accounts Leetcode sounds absolutely tedious at best and more often an insulting, demeaning waste of time.
Maro 4y ago
In general I don't do well on interviews because I get nervous. Having said that, for this specific case, 3 hours seems like a lot of time. All you have to do is find a similar command (probably the increment), trace it in the code (possibly with a debugger and some breakpoints), and copy/paste to add the funcionality for the multiply. Then, see if it compiles, it won't, and keep repeating until it compiles. Then, see if it works, it won't, and keep iterating until it does. To be fair, in my first job 20 years ago I did this exact sort of thing for 3 years on a very large C/C++ codebase. Also, later when I was at Facebook I did this a lot in that humungous codebase (searching the codebase, finding the right place to make a change, looking for something in the neighbourhood that looks similar and can be copy/pasted). So this interview question would be right up my alley.
lkxijlewlf 4y ago
To me, this would be much less "pressure" than leetcode. Just seeing a leetcode problem pisses me off. It's so fucking low effort.
mberning 4y ago
You know what I really want to see? We streamlined our firing process so we don't have to go through all these hiring shenanigans. When you have a ridiculous hiring process you can still make a bad hire. At most places I have worked bad hires stick around way too long because of HR and Legal BS. Just give the person a really nice severance to part ways. Be done with it. The departing employee can feel good about it, the team can feel good that the bad apple is gone, and you can focus on finding another person.

theamk 4y ago

If "3 hours" is "such pressure" for you, then maybe some teams are not a good fit for you? For example, I have broken the build in the past - and this prevents everyone else on your team from merging PRs. In this case the expectation was that I fix it "soon" - once I finish my current meeting/lunch/conversation. If someone is prone to breaking down from pressure given 3 hour deadline, they would have a breakdown right there.

fzeroracer 4y ago
Generally speaking if your build process is so fragile that one person creating a breaking build results in a chain of failures and a pressure crunch then that's a work environment problem. I would consider that sort of thing completely unreasonable and consider finding a new job immediately. If you find yourself in that sort of thing frequently then perhaps you should reconsider normalizing it and instead push for actual fixes. You look at the issue and say it's a personal issue. I look at it and see a dysfunctional development environment issue. Now this doesn't always hold true and sometimes devs have to be held to higher pressure environments (such as having on-call duties): but those kind of things are usually better compensated for and called out as part of the job duties.
- vimwizard 4y ago
  In an ideal world, no one would ever have to work under pressure, and while some people in this industry don't, many (I would bet a majority) of people do or have in the past. This seems especially true for startups trying to break into a market with competition. Either you have been lucky with the places you've worked at, have sifted through tens of shops to find a good one, or have very little experience in the industry. I really do hope that none of my assumptions are true and that one day I can find a functional, low-pressure team to work with.
  - fzeroracer 4y ago
    This goes back to what I said earlier: If the work environment is dysfunctional, then you should either work towards fixing it (especially if you're a senior engineer) or work towards finding a better job. Software engineers are one of the few career paths afforded the ability to do so and it would be better for us as a whole if there was less normalization of awful development practices under the guise of 'everyone else has experienced this or does this'. This goes doubly true for startups in my opinion because rushing things like this and having a shaky foundation just adds another point of failure to your organization. Remember for every startup that succeeds, multitudes of others fall flat on their face due to a build up of problems.
- KerrAvon 4y ago
  Even in the best environments, stuff happens. If you have a central enough role in a large enough environment, you will cause pain for a ton of other people every once in a while, even if it’s not directly your fault. If you have a process that completely prevents all fuckups that an engineer could possibly cause, you either have a relatively small leaf node project or one that is low productivity. That said, I wouldn’t necessarily give this question to the most junior candidates. Coping with a large existing sourcebase rapidly is a set of learned skills even if it’s just cargo-cutting a solution like this.
jseban 4y ago
Yeah a shitty working environment where people are constantly stressed, is not a good fit for me.
newaccount74 4y ago
I agree with you. Sometimes stressful situations arise, and there is nothing you can do about it. Even if you have the best QA process in the world, and people can't break the build because you can't merge code that doesn't pass the test suite, at some point you are still going to ship a bug to customers, and even if your manager is the nicest person in the world it will be a very uncomfortable situation once you realise that your bug is losing customer data. If you can't deal with an occasional stressful situation, life is going to suck for you, because there are always going to be stressful situations. Being given 3 hours to add a minor feature to a pretty run-of-the-mill C program really shouldn't be an issue to anyone who is familiar with C, assuming the job asked for experience with C. Sure job interviews are stressful, but if you can't calm yourself down in 3 hours and do something that would take an average C programmer maybe 30 minutes of time, you probably aren't a good fit for a job where people are going to rely on you.

ramraj07 4y ago

What’s your alternative? This is an alternative to leetcode vomit at the least. I agree this question isn’t 100% inclusive but then no other method I know of is; at the least the only thing to worry here is people being frustrated or getting anxious. This can be mitigated by being nice and reassuring them that even a suboptimal solution is okay. As others mentioned, 3 hours is generous and probably accounts for people freaking out and then cooling down.

mihaitodor 4y ago
> What’s your alternative? I didn't comment here to propose an alternative, just to point out that the proposed approach isn't so good for some people, including myself. Since you asked, maybe people should stop looking for the one true way of interviewing and realise that they're hiring actual humans, not robots. The hiring process in this industry has become this lazy meat grinder which most people with actual decision making power swear by while bemoaning the lack of diversity (and I don't mean just gender). Some day, perhaps the industry will move towards more inclusive approaches.

jseban 4y ago

I agree with you completely. But other desk jobs have management that actually understand and organise the work, not just make people sweat.

rootlocus 4y ago

> it's beyond me why anyone would need to prove they can cope with such pressure without breaking down. Where's the pressure? You have a piece of code, all you need to do is read it, understand it, make a (possibly) trivial modification. That's exactly what you would be doing (or have been doing) every day. You don't have to explain complex algorithms on a whiteboard. There are no high stakes. You can leave whenever you want. Last time I had to do something like this I was allowed privacy, internet, headphones.

chii 4y ago
> Where's the pressure? the pressure comes from the context - you're in an interview situation, faced with a previously unknown task (presumably you haven't done something similar before). The result of this "test" determines your candidacy in the job (presumably you want or need this job). It's like asking why a bomb defuser feels pressured.
- rootlocus 4y ago
  > It's like asking why a bomb defuser feels pressured. The stakes and environment aren't even close for this to be a meaningful comparison. A job interview will always carry some degree of pressure, no matter the circumstances. What I fail to understand is why would someone feel more threatened by this scenario as opposed to, say, answering a barrage of technical question or solving algorithmic problems.
  - db48x 4y ago
    Yea, the pressure is almost always in our heads; most interviewers aren’t taking any pleasure from torturing their candidates.

kdtsh 4y ago

I can only hope that an employer seriously using this in an interview is looking at how someone codes, not necessarily that they get a result in 3 hours; I can also only hope that they explain this to the interviewee. At best, assuming no prior knowledge, it tests an interviewees understanding of the broad structure of a given procedural programming language and their use of whatever tools are available to them on the day (hopefully this at least includes coreutils). It has to be treated as a kind-of-realistic, fun challenge on an existing code base; otherwise it is meaningless. Stories about someone so frustrated they threw their laptop on the floor are genuinely sad. Like, what are people trying to achieve with a test like this if that is a possible outcome? No one would expect a solution to this in 3 hours under normal conditions, regardless of whether someone can push one out - I got something going in an hour, and I have no idea what the hell to make of the code base now except that a) it builds and b) it works according to the fairly vague parameters of the task, i.e. input `mult age 10` to your telnet session and get 380. Regression testing be damned, especially considering there are no parameters for testing (does that 3 hours involve rewriting a bunch of Perl to support the interviewee's hacky changes? It takes a while to run `make test` ...) Other commenters are saying that it is outrageous to expect someone to put in 3 hours work, without pay, to produce a meaningful result. I agree, as this is notionally their profession, and people are not generally in the business of handing out their work for free. That being said, I haven't had to deal with Leetcode in my career (yet) but from what I've heard it sure beats that.

mihaitodor 4y ago
> That being said, I haven't had to deal with Leetcode in my career (yet) but from what I've heard it sure beats that. Lucky you... I'm at my 8th job now and Leetcode-style interviews pushed me to the point where I ask up front if this is part of the interview process, because, as stated on my LinkedIn, "I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming". If that's a showstopper for them, then they need to find someone else.
- kdtsh 4y ago
  I have great respect for that. By all accounts Leetcode sounds absolutely tedious at best and more often an insulting, demeaning waste of time.

Maro 4y ago

In general I don't do well on interviews because I get nervous. Having said that, for this specific case, 3 hours seems like a lot of time. All you have to do is find a similar command (probably the increment), trace it in the code (possibly with a debugger and some breakpoints), and copy/paste to add the funcionality for the multiply. Then, see if it compiles, it won't, and keep repeating until it compiles. Then, see if it works, it won't, and keep iterating until it does. To be fair, in my first job 20 years ago I did this exact sort of thing for 3 years on a very large C/C++ codebase. Also, later when I was at Facebook I did this a lot in that humungous codebase (searching the codebase, finding the right place to make a change, looking for something in the neighbourhood that looks similar and can be copy/pasted). So this interview question would be right up my alley.

lkxijlewlf 4y ago

To me, this would be much less "pressure" than leetcode. Just seeing a leetcode problem pisses me off. It's so fucking low effort.

mberning 4y ago

You know what I really want to see? We streamlined our firing process so we don't have to go through all these hiring shenanigans. When you have a ridiculous hiring process you can still make a bad hire. At most places I have worked bad hires stick around way too long because of HR and Legal BS. Just give the person a really nice severance to part ways. Be done with it. The departing employee can feel good about it, the team can feel good that the bad apple is gone, and you can focus on finding another person.