5 ms·

Seriously, if you've never hired before, you have no idea how bad this can get. Here's [1] our practice coding problem. It's quite similar to the one we use on

Seriously, if you've never hired before, you have no idea how bad this can get. Here's [1] our practice coding problem. It's quite similar to the one we use on our interview, and not too far from the one Triplebyte used in the past (ours is tuned to be slightly harder at the beginning and slightly easier at the end). The vast majority of candidates, even with some reasonable pre-filtering, do not get past the first step. A very non-trivial number would not even get that far. [1] https://www.otherbranch.com/practice-coding-problem https://www.otherbranch.com/practice-coding-problem

itronitron 2y ago
That is the sort of coding problem I would love to work on as an exercise however the 25 minute time limit would put me off and I wouldn't even start. I enjoy programming and I don't like to feel rushed, and if you're placing that sort of time constraint then you probably aren't a great company to work for.
cwillu 2y ago
So, having completed the practice problem with about 45 seconds to spare, what sort of openings are there for the aging-but-not-aged Canadian who can probably only manage part-time remote work?
- rachofsunshine 2y ago
  I don't anticipate us getting a lot of clients with budget for a part-time employee anytime soon, unfortunately. I imagine a lot will be remote, but probably not part time. Still happy to have you in our pool in case we do (I think I see you in the signups list - something about oddball proprietary languages, yeah?) but it's not a wildly high-probability bet in the short term. I really, really, really wish I had a better solution for this sort of thing.
  - cwillu 2y ago
    Fair enough, yep, that's me. I do wonder how my “part time” output would compare the expectations from full-time output. During the periods I've worked more conventional jobs, the vast majority of the value I brought was during the oddball times/contributions. Surely there must be some way I can be exploited (in a good way) without implicitly bundling ancillary seat warming into the contract. :D
  - cwillu 2y ago
    Incidentally, I didn't get a confirmation email; might be something to consider adding to the form workflow. My email is the obvious one given my username, on the off-chance I made a typo.
    - rachofsunshine 2y ago
      It got submitted properly and looks like the correct email. Airflow - at least the plan we're on - caps the number of emails to different addresses that it'll send a day, so we hadn't set up confirmations, but I guess normal volume probably isn't a problem for that. (Woulda been fun today, though.)
      - anonymoushn 2y ago
        I think it would certainly help to receive a confirmation email. Thanks!
cipheredStones 2y ago
Oh, that brings back memories. When I interviewed with Triplebyte in 2018 and was rejected, my first item in the 'positive feedback' part of the email was "We saw some real strength on the tic tac toe section.", and my first item in the immediately following "the areas we think you can improve" paragraph was "We didn't see the coding proficiency we were looking for in the tic tac toe section--you didn't make very much progress."
- rachofsunshine 2y ago
  Well, some idiot must have written that email! ...it might have been me, I was writing those emails in the year 2018. That was my first job there. Jokes aside, we generated those emails largely from a template. If I remember right, "saw some real strength" was "got at least an OK score for code quality", while the negative feedback below was about number of steps. The number of mishaps with that system is part of why we do the feedback a bit differently [1] at Otherbranch, at least for now. I think we did revamp it very late in that team's lifetime, just before Triplebyte pivoted and laid off most of the team that did those (two of us, me + one of my colleagues, moved over to a different team, which is why I'm in a position to tell the whole story). [1] https://framerusercontent.com/images/ARBLIder7AsO5KlaEpClZ3Wvlk.png https://framerusercontent.com/images/ARBLIder7AsO5KlaEpClZ3W... (As an aside I wish Framer'd let me link images directly on the proper domain.)
stackskipton 2y ago
I have and you are right, it's terrible. However, I'm coming from Ops side of the house so my knowledge on Dev Hiring is talking to them and making sure they are not going to launch LedgerStore without talking to us first. Ops I'm more experienced with. However, looking at Other Branch example test, it's another data structure question which I would totally bomb. Is this really the end all be all to dev hiring? If they can't do Data Structures, are they worthless to Silicon Valley companies? I'm honestly stumped because we get dev candidates that crash and burn with Fizzbuzz or our REST API test. I MUST KNOW.
- duped 2y ago
  > If they can't do Data Structures, are they worthless to Silicon Valley companies? I think you might be overthinking this - understanding how to model a problem with a data structure is a core competency of any developer. This isn't a "gotcha" question where you need to know union find sets or how to invert a linked list in place. If the question was rephrased, "design a JSON schema for the state of the board" would you know how to approach it? Because that's essentially what step 1 is asking.
- rachofsunshine 2y ago
  You consider that a "data structure question"? Honest question - I would (do) characterize it as a sort of "fizzbuzz+" that is deliberately NOT data-structure-y, and I'm surprised by this response. Can you give an example of short coding tasks you would consider not data-structure-y? (For the record, we do ask about DBs and system design in other sections of the interview. The coding is one portion of three for the interview as a whole.)
  - stackskipton 2y ago
    Minesweeper is all about storing data about the board and displaying the numbers is all about running through data. Seems very data structurey to me but maybe that's non heavy dev side coming through. Maybe I'm just thinking too much problem, overloaded my small attention brain and misread it. I wouldn't call Fizzbuzz data structure-y however. I'm also mostly outsider looking in. Never worked at FAANG and working with YC companies, I come on much later and tends to be more keeping the lights on and stopping the duct tape rocket from exploding.
zem 2y ago
that's actually pretty great, but it brings up another issue I have with the state of tech interviewing - it focuses on being able to write code fast. the more senior you get, the more you tend to focus on depth, taking your time to think over the problem and write a good robust solution rather than banging out code fast, so coding up a solution in 25 minutes versus an hour is not really a good test of what the company presumably wants to hire you for.
- josephg 2y ago
  I was one of triplebyte’s interviewers years ago and I can speak to this. In short, you’re right. But two notes: First, you massively underestimate the range of coding speed you see in an interview. The slowest programmers weren’t senior people who were out of practice. (I interviewed plenty of them). It was people who just seem bad at programming. Like, so bad it takes them 25 minutes to make a hello world program run. (In their favorite language, on their computer and with full access to the internet during the test). A 2x programming speed difference would have rarely changed the outcome of our overall assessment. Second, there was an aspect of triplebyte’s interviewing process that I’d love to see replicated elsewhere in the industry that resolves this. And that is, we should be assessing debugging ability. At triplebyte we gave candidates a smallish program (few hundred lines) with 4 bugs and a failing test case for each one. The candidates had half an hour to fix as many of the bugs as they could. Watching people debug was fascinating. One clear pattern that emerges is exactly what you are predicting. Smart kids right out of school were great at the programming section. But it was always the more senior engineers who smashed the debugging section. Junior engineers would get lost in the weeds and struggle to get very far in the time we gave them. Some of the senior people I interviewed dived straight in, and even found some bugs we didn’t even know about in our own test. It seems to me that being able to read unfamiliar code and fix bugs in it is a hard to learn skill that matters on the ground. And frankly I suspect it’s more useful skill than a lot of leetcode problems. I’d rather hire someone who’s amazing at debugging than someone who’s amazing at data structures. Well, I suppose I want one of each on my team. If I was ever making a programming test, this is something I’d include for sure.
  - rachofsunshine 2y ago
mech422 2y ago
That actually looks pretty good aside from the time limit.. It takes me a while to 'get in the zone' - and especially with you base datastructures you wanna think about it a bit as it has real ramifications on how hard/easy everything else can be. Still, seems better then most of the 'leet code' type stuff I see :-)
- rachofsunshine 2y ago
  Yeah, the time limit is an interviewing constraint, not a principled decision (see my reply in a sibling thread to this one).
  - mech422 2y ago
    Understandable :-)
ctrlw 2y ago
That was a fun coding task. Minor bug in the illustration of Step 4: the mine count in second row should be 8 not 4
- rachofsunshine 2y ago
  Thanks for the correction! Fixed.

itronitron 2y ago

That is the sort of coding problem I would love to work on as an exercise however the 25 minute time limit would put me off and I wouldn't even start. I enjoy programming and I don't like to feel rushed, and if you're placing that sort of time constraint then you probably aren't a great company to work for.

cwillu 2y ago

So, having completed the practice problem with about 45 seconds to spare, what sort of openings are there for the aging-but-not-aged Canadian who can probably only manage part-time remote work?

rachofsunshine 2y ago
I don't anticipate us getting a lot of clients with budget for a part-time employee anytime soon, unfortunately. I imagine a lot will be remote, but probably not part time. Still happy to have you in our pool in case we do (I think I see you in the signups list - something about oddball proprietary languages, yeah?) but it's not a wildly high-probability bet in the short term. I really, really, really wish I had a better solution for this sort of thing.
- cwillu 2y ago
  Fair enough, yep, that's me. I do wonder how my “part time” output would compare the expectations from full-time output. During the periods I've worked more conventional jobs, the vast majority of the value I brought was during the oddball times/contributions. Surely there must be some way I can be exploited (in a good way) without implicitly bundling ancillary seat warming into the contract. :D
- cwillu 2y ago
  Incidentally, I didn't get a confirmation email; might be something to consider adding to the form workflow. My email is the obvious one given my username, on the off-chance I made a typo.
  - rachofsunshine 2y ago
    It got submitted properly and looks like the correct email. Airflow - at least the plan we're on - caps the number of emails to different addresses that it'll send a day, so we hadn't set up confirmations, but I guess normal volume probably isn't a problem for that. (Woulda been fun today, though.)
    - anonymoushn 2y ago
      I think it would certainly help to receive a confirmation email. Thanks!

cipheredStones 2y ago

Oh, that brings back memories. When I interviewed with Triplebyte in 2018 and was rejected, my first item in the 'positive feedback' part of the email was "We saw some real strength on the tic tac toe section.", and my first item in the immediately following "the areas we think you can improve" paragraph was "We didn't see the coding proficiency we were looking for in the tic tac toe section--you didn't make very much progress."

rachofsunshine 2y ago
Well, some idiot must have written that email! ...it might have been me, I was writing those emails in the year 2018. That was my first job there. Jokes aside, we generated those emails largely from a template. If I remember right, "saw some real strength" was "got at least an OK score for code quality", while the negative feedback below was about number of steps. The number of mishaps with that system is part of why we do the feedback a bit differently [1] at Otherbranch, at least for now. I think we did revamp it very late in that team's lifetime, just before Triplebyte pivoted and laid off most of the team that did those (two of us, me + one of my colleagues, moved over to a different team, which is why I'm in a position to tell the whole story). [1] https://framerusercontent.com/images/ARBLIder7AsO5KlaEpClZ3Wvlk.png https://framerusercontent.com/images/ARBLIder7AsO5KlaEpClZ3W... (As an aside I wish Framer'd let me link images directly on the proper domain.)

stackskipton 2y ago

I have and you are right, it's terrible. However, I'm coming from Ops side of the house so my knowledge on Dev Hiring is talking to them and making sure they are not going to launch LedgerStore without talking to us first. Ops I'm more experienced with. However, looking at Other Branch example test, it's another data structure question which I would totally bomb. Is this really the end all be all to dev hiring? If they can't do Data Structures, are they worthless to Silicon Valley companies? I'm honestly stumped because we get dev candidates that crash and burn with Fizzbuzz or our REST API test. I MUST KNOW.

duped 2y ago
> If they can't do Data Structures, are they worthless to Silicon Valley companies? I think you might be overthinking this - understanding how to model a problem with a data structure is a core competency of any developer. This isn't a "gotcha" question where you need to know union find sets or how to invert a linked list in place. If the question was rephrased, "design a JSON schema for the state of the board" would you know how to approach it? Because that's essentially what step 1 is asking.
rachofsunshine 2y ago
You consider that a "data structure question"? Honest question - I would (do) characterize it as a sort of "fizzbuzz+" that is deliberately NOT data-structure-y, and I'm surprised by this response. Can you give an example of short coding tasks you would consider not data-structure-y? (For the record, we do ask about DBs and system design in other sections of the interview. The coding is one portion of three for the interview as a whole.)
- stackskipton 2y ago
  Minesweeper is all about storing data about the board and displaying the numbers is all about running through data. Seems very data structurey to me but maybe that's non heavy dev side coming through. Maybe I'm just thinking too much problem, overloaded my small attention brain and misread it. I wouldn't call Fizzbuzz data structure-y however. I'm also mostly outsider looking in. Never worked at FAANG and working with YC companies, I come on much later and tends to be more keeping the lights on and stopping the duct tape rocket from exploding.

zem 2y ago

that's actually pretty great, but it brings up another issue I have with the state of tech interviewing - it focuses on being able to write code fast. the more senior you get, the more you tend to focus on depth, taking your time to think over the problem and write a good robust solution rather than banging out code fast, so coding up a solution in 25 minutes versus an hour is not really a good test of what the company presumably wants to hire you for.

josephg 2y ago
I was one of triplebyte’s interviewers years ago and I can speak to this. In short, you’re right. But two notes: First, you massively underestimate the range of coding speed you see in an interview. The slowest programmers weren’t senior people who were out of practice. (I interviewed plenty of them). It was people who just seem bad at programming. Like, so bad it takes them 25 minutes to make a hello world program run. (In their favorite language, on their computer and with full access to the internet during the test). A 2x programming speed difference would have rarely changed the outcome of our overall assessment. Second, there was an aspect of triplebyte’s interviewing process that I’d love to see replicated elsewhere in the industry that resolves this. And that is, we should be assessing debugging ability. At triplebyte we gave candidates a smallish program (few hundred lines) with 4 bugs and a failing test case for each one. The candidates had half an hour to fix as many of the bugs as they could. Watching people debug was fascinating. One clear pattern that emerges is exactly what you are predicting. Smart kids right out of school were great at the programming section. But it was always the more senior engineers who smashed the debugging section. Junior engineers would get lost in the weeds and struggle to get very far in the time we gave them. Some of the senior people I interviewed dived straight in, and even found some bugs we didn’t even know about in our own test. It seems to me that being able to read unfamiliar code and fix bugs in it is a hard to learn skill that matters on the ground. And frankly I suspect it’s more useful skill than a lot of leetcode problems. I’d rather hire someone who’s amazing at debugging than someone who’s amazing at data structures. Well, I suppose I want one of each on my team. If I was ever making a programming test, this is something I’d include for sure.
- rachofsunshine 2y ago

mech422 2y ago

That actually looks pretty good aside from the time limit.. It takes me a while to 'get in the zone' - and especially with you base datastructures you wanna think about it a bit as it has real ramifications on how hard/easy everything else can be. Still, seems better then most of the 'leet code' type stuff I see :-)

rachofsunshine 2y ago
Yeah, the time limit is an interviewing constraint, not a principled decision (see my reply in a sibling thread to this one).
- mech422 2y ago
  Understandable :-)

ctrlw 2y ago

That was a fun coding task. Minor bug in the illustration of Step 4: the mine count in second row should be 8 not 4

rachofsunshine 2y ago
Thanks for the correction! Fixed.