5 ms·

>how clean their code is, I got bit in the ass by this one as triplebyte itself. They asked me to make a tic tac toe game, and gave me iirc 30 minutes (less?)

>how clean their code is, I got bit in the ass by this one as triplebyte itself. They asked me to make a tic tac toe game, and gave me iirc 30 minutes (less?) to do it. Except, it wasn't "build a tic tac to" game, first it was "draw a board to the console," "take user input from the console," etc a bunch of instructions in a convoluted path that perhaps another engineer would do when knowing from the outset that the goal was to build a tic tac toe game in 30 minutes, but not me. So we'd get to a portion where I'd be writing a quick test on user input, or extrapolating something to a function, and the interviewer would say "don't worry about that, just worry about {getting the grid to print to console or whatever}." Later on I got my feedback and they said they were disappointed with my user input tests and repeated, extractable code in the tic tac toe portion. Triplebyte is trying to do good things in the interview space but I think they're still learning. All in all my interview with them was about as positive an experience as a harried and bad interview could be, from my perspective.

closeparen 8y ago
Telling people not to worry about parts of the problem is often a time management strategy. They want you to move on so you have a chance to show strength in other parts of the problem, or at least come away with the positive experience of finishing something, even though it may count against you.
Benjammer 8y ago
I took shortcuts in my triplebyte coding porting of the interview, assuming we would iterate and expand on the solution. Instead we just moved on to algorithms and I got heavily dinged on my feedback for the shortcuts I took (things like hard-coded strings in some places to get the UI working before wiring up to real data models).
localcrisis 8y ago
Same experience with the Tic Tac Toe, then again with the rest of the interview. There were a lot of Googlable boilerplate questions (e.g. "what does malloc return?", "what's a bloom filter?") that, as a product engineer, never come up. Then there were the classic Big-O notation queries that for most use cases don't come up until much later stage. It felt like the founders were classically trained in CS and over-optimizing for things that aren't practically relevant for the large majority of early/mid-stage startups. Am I familiar with these concepts—e.g. can I go back and refresh myself when they come up?—absolutely. But often times the skills you'd want in an engineer are: 1. Knowing when to optimize 2. Knowing how to profile and identify bottlenecks 3. Familiarity with the available solutions 4. Ability to dig in and evaluate which is the right tool for the jon
- Afforess 8y ago
  >"what does malloc return?" This is particularly pernicious, because it's a trick question, too. On linux, malloc always returns, it will never return NULL. Even if you ask for 4 petabytes of memory on a 128mb system, malloc will hand you back a valid pointer for the memory. https://scvalex.net/posts/6/ https://scvalex.net/posts/6/
  - merb 8y ago
    well a sane answer would be that it returns a void* ptr to the allocated memory that can be casted to the needed ptr type.
  - coryrc 8y ago
    I'm pretty sure it will fail NULL if overcommit is disabled. (And apparently other conditions: https://stackoverflow.com/questions/2248995/is-there-a-need-to-check-for-null-after-allocating-memory-when-kernel-uses-over https://stackoverflow.com/questions/2248995/is-there-a-need-... )
  - Retra 8y ago
    If I were asked that, I would say something like "malloc attempts to allocate some memory on the heap and return a pointer to it." If pressed for more details, I would say it depends on the allocator and that we should look at the documentation for it to find out. If that was an unacceptable answer, then I'd consider the interview a waste of time.
sigfubar 8y ago
You failed your Triplebyte interview because you neglected an extremely important aspect of the job: communication. You made assumptions about the ask which turned out to be grossly out of tune with those of the interviewer. In the real world, engineers are often left holding the bag when other participants of the process leave out important details. It’s our job to ask questions and establish the boundaries of each problem before diving into a solution.
- gizmo385 8y ago
  > engineers are often left holding the bag when other participants of the process leave out important details That sounds like a process problem and not an engineering problem. If I've been given requirements, I'm going to trust that my project managers and stakeholders have done the due diligence to understand their request. Also you've got to realize that different developers tackle issues in different ways. Not every engineer is going to be super talkative while they're in the mud trying to get something to work until they've hit a wall that they don't feel like they have enough information to overcome. I think expecting an engineer to sit there and talk through every aspect of their reasoning WHILE working is fundamentally counter to the way that most engineers perform their day-to-day jobs.
- komali2 8y ago
  As verbatim as I can remember our interaction: Me: "I'm going to just put some user input checks here, no guarantees they'll actually input X or O, yea?" Interviewer: "Oh, don't worry about that, assume for now that you'll get X on X's turn, O on O's turn." Later: Me: "Normally I'd extrapolate this to a function, so let me just - " Interviewer: "For now, just focus on getting the program to response to the next user input." Me: "Ok... well the fastest way to do that right now is just copy paste this code down here." Interviewer: "That's fine." But, it turns out, it was not fine. I felt I was bamboozled.
  - halfjoking 8y ago
    Triplebyte sounds like a bad girlfriend. When she says "don't worry about it" or "that's fine", you can't take her word for it. You need to be psychic and understand her needs without her saying anything.
auston 8y ago
I had the same tic-tac-toe q, I felt that the instructions were pretty clear: “Accomplish this one thing, as simple as possible, then generalize to actually work.” To me it felt like I was getting specs to write a class and that’s what I did. I had a pretty great experience and would recommend TripleByte.

closeparen 8y ago

Telling people not to worry about parts of the problem is often a time management strategy. They want you to move on so you have a chance to show strength in other parts of the problem, or at least come away with the positive experience of finishing something, even though it may count against you.

Benjammer 8y ago

I took shortcuts in my triplebyte coding porting of the interview, assuming we would iterate and expand on the solution. Instead we just moved on to algorithms and I got heavily dinged on my feedback for the shortcuts I took (things like hard-coded strings in some places to get the UI working before wiring up to real data models).

localcrisis 8y ago

Same experience with the Tic Tac Toe, then again with the rest of the interview. There were a lot of Googlable boilerplate questions (e.g. "what does malloc return?", "what's a bloom filter?") that, as a product engineer, never come up. Then there were the classic Big-O notation queries that for most use cases don't come up until much later stage. It felt like the founders were classically trained in CS and over-optimizing for things that aren't practically relevant for the large majority of early/mid-stage startups. Am I familiar with these concepts—e.g. can I go back and refresh myself when they come up?—absolutely. But often times the skills you'd want in an engineer are: 1. Knowing when to optimize 2. Knowing how to profile and identify bottlenecks 3. Familiarity with the available solutions 4. Ability to dig in and evaluate which is the right tool for the jon

Afforess 8y ago
>"what does malloc return?" This is particularly pernicious, because it's a trick question, too. On linux, malloc always returns, it will never return NULL. Even if you ask for 4 petabytes of memory on a 128mb system, malloc will hand you back a valid pointer for the memory. https://scvalex.net/posts/6/ https://scvalex.net/posts/6/
- merb 8y ago
  well a sane answer would be that it returns a void* ptr to the allocated memory that can be casted to the needed ptr type.
- coryrc 8y ago
  I'm pretty sure it will fail NULL if overcommit is disabled. (And apparently other conditions: https://stackoverflow.com/questions/2248995/is-there-a-need-to-check-for-null-after-allocating-memory-when-kernel-uses-over https://stackoverflow.com/questions/2248995/is-there-a-need-... )
- Retra 8y ago
  If I were asked that, I would say something like "malloc attempts to allocate some memory on the heap and return a pointer to it." If pressed for more details, I would say it depends on the allocator and that we should look at the documentation for it to find out. If that was an unacceptable answer, then I'd consider the interview a waste of time.

sigfubar 8y ago

You failed your Triplebyte interview because you neglected an extremely important aspect of the job: communication. You made assumptions about the ask which turned out to be grossly out of tune with those of the interviewer. In the real world, engineers are often left holding the bag when other participants of the process leave out important details. It’s our job to ask questions and establish the boundaries of each problem before diving into a solution.

gizmo385 8y ago
> engineers are often left holding the bag when other participants of the process leave out important details That sounds like a process problem and not an engineering problem. If I've been given requirements, I'm going to trust that my project managers and stakeholders have done the due diligence to understand their request. Also you've got to realize that different developers tackle issues in different ways. Not every engineer is going to be super talkative while they're in the mud trying to get something to work until they've hit a wall that they don't feel like they have enough information to overcome. I think expecting an engineer to sit there and talk through every aspect of their reasoning WHILE working is fundamentally counter to the way that most engineers perform their day-to-day jobs.
komali2 8y ago
As verbatim as I can remember our interaction: Me: "I'm going to just put some user input checks here, no guarantees they'll actually input X or O, yea?" Interviewer: "Oh, don't worry about that, assume for now that you'll get X on X's turn, O on O's turn." Later: Me: "Normally I'd extrapolate this to a function, so let me just - " Interviewer: "For now, just focus on getting the program to response to the next user input." Me: "Ok... well the fastest way to do that right now is just copy paste this code down here." Interviewer: "That's fine." But, it turns out, it was not fine. I felt I was bamboozled.
- halfjoking 8y ago
  Triplebyte sounds like a bad girlfriend. When she says "don't worry about it" or "that's fine", you can't take her word for it. You need to be psychic and understand her needs without her saying anything.

auston 8y ago

I had the same tic-tac-toe q, I felt that the instructions were pretty clear: “Accomplish this one thing, as simple as possible, then generalize to actually work.” To me it felt like I was getting specs to write a class and that’s what I did. I had a pretty great experience and would recommend TripleByte.