5 ms·

I'm a 30+ year experience SWE. I had my own successful startup exit and after that I skipped FAANG to join the founding teams at other startups founded by Ex-FA

I'm a 30+ year experience SWE. I had my own successful startup exit and after that I skipped FAANG to join the founding teams at other startups founded by Ex-FAANG big names. Unfortunately none of them panned out. I recently went through a series of interviews with a company that were dragged out over two months. Each went very well. My last interview was with a "Senior Engineer" who graduated in 2020 and had a little over a year of experience at Google before joining the company in question. He vetoed me because I used a debugger in a pair programming interview. Not because I didn't complete the task well. So yeah, it's a bitch out there.

javajosh 3y ago
Out of (morbid) curiosity - what was his objection to using a debugger?
- rickreynoldssf 3y ago
  Just that I used it at all. There's a contingent of engineers who feel using a debugger is a waste of time and or a sign of weakness. They're the ones who like to stare at code and "run it in their heads" and dump crazy amounts of "got here" into the logs. Evidently this guy is one of them.
  - bb88 3y ago
    There's two reasons I think. (I have ~25 years experience) 1. In your code should know what the edge cases, loop condition issues, etc. I think this is fair. If you don't know the edge case failures when you write your code, you could end up with something like the Microsoft Xune that shutdown for an entire day over a leap year failure. https://www.seattletimes.com/business/microsoft/original-microsoft-zune-confounded-by-leap-year-shuts-down/ https://www.seattletimes.com/business/microsoft/original-mic... Keep in mind that code review will probably not catch all bugs, it's up to the original coder to write it. This is particularly true if you're the best person on your team, say. Or you're working at a startup where no one can really review your code other than you. On the other hand well coded unit tests should help you here. 2. It's toxic brogrammer culture there -- where leetcode scores are all that matter. In which case it's probably best you were passed over.
    - throw0101a 3y ago
      > 1. In your code should know what the edge cases, loop condition issues, etc. Perhaps, but: > It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. * https://quoteinvestigator.com/2018/11/18/know-trouble/ https://quoteinvestigator.com/2018/11/18/know-trouble/ Sometimes you want to go to 'first principles' and reassess your assumptions. As a sysadmin I sometimes I resort to making sure the thing is actually physically plugged in (OSI Layer 1), the move up the stack with regards to how the bits flow.
  - jansan 3y ago
    I am one of these engineers, but I consider the "cowboy style" a weakness and bad habit and would never ever judge another engineer over using a debugger.
  - nunez 3y ago
    I am personally not a fan of debuggers but I would never ding someone over using them unless it was obvious they couldn't debug without them.
  - javajosh 3y ago
    Strange. Whenever I use a debugger I always get a lot out of it. The code never quite executes exactly the way you envision, even with passing tests. In Java, there is a strange emphasis on classes but I've always felt objects are more fundamental, and the debugger is the way to see them and their interactions.
- geysersam 3y ago
  Isn't it obvious? Using a debugger implies that you expect the code you write to have bugs. Not a mindset I'd like my coworkers to have.
  - sethrin 3y ago
    Is this sarcasm or epic hubris? No-one writes bug-free code, and thinking otherwise sounds like an enormous red flag.
    - geysersam 3y ago
      At our org we originally only hired A+ people. The A+ people hired A++ people and so on. Eventually we ended up with only 10x programmers and since then we haven't written any bugs. If I get around to it I'll eventually write a book about this technique.
      - sethrin 3y ago
        What you say is impossible, and it's not worth my time to discover whether you're a liar or merely deluded.
        frfl 3y ago
        this is sarcasm, OP is just having fun
  - diego_moita 3y ago
    Not sure if you're trolling or just missed the "/s" tag. A much worse mindset is to be arrogant enough to assume the code has no bugs. As a matter of principle every code has bugs. Some bugs are found, some not.
  - singleshot_ 3y ago
    It’s actually worse than that: using a debugger shows that you’ve written so much buggy code that you somehow learned that debuggers exist. Steer well clear of these people!
- ninkendo 3y ago
  Just to chime in with a different take from the rest of the comments: there’s lots of tools that aren’t really appropriate to use during an interview. If you’re being asked to do (say) tree traversal, then in real life it’s totally fine to Google it and copy/paste a code snippet. But during an interview, presumably they want to know how much you can do on your own without “help”. It’s not that much of a stretch to say that a debugger is a level of “help” that they want to see you do without during an interview. Using a debugger is a sign that you’re not sure what your code is doing and so you need “help”… maybe the interviewer was looking to see that they could fit the exercise in their head well enough to solve the problem without a debugger.
  - rickreynoldssf 3y ago
    To add more context. The task included interfacing with a 3rd party API that was poorly documented. In order to even see what a response looked like would have been incredibly hard without a debugger. Dumping it to the console would have been many pages of nested JSON. So sitting there twiddling, trying to make sense of an API doc that didn't provide a clear description of the results rather than just run the thing and see what it did was the wrong way to go. A debugger is as much "help" to an engineer as a hammer is to a carpenter. In my experience, engineers who don't use one are a detriment to the entire engineering organization wasting time and money. Anyway, yeah I dodged a bullet on that but it's such a pain in the ass that I went though a two month interview process only to be vetoed at the end like that. During that time I spent about two weeks to learn an esoteric API that I'll never use again. Oh and it would have been highly unlikely that I would have even used that API in the job. It was just a requirement that I learned it for this particular interview. ...and no I'm not going to commit it to memory just so I can pass a coding interview and if that was the expectation then this whole situation is even more ridiculous.
    - ninkendo 3y ago
      Yeah, if the exercise is in using a poorly documented API, and the answer depends on fiddly bits of trivia around how the response is structured, then a debugger is absolutely the right approach, even during an interview. You did the right thing here, and the interviewer is a dummy.
vehementi 3y ago
Probably a sign of the previous bad overhiring, and title inflation as you point out. Not so much the job market as a shitty company
bradlys 3y ago
Was it actual pair programming (where you actually build something tangible) or was it a leetcode style interview? In a leetcode style interview, I could see being thrown out for debugging. In a true pair programming exercise, I wouldn’t think this would be super common but guess it depends a lot on the exercise. Pair programming is extremely variable with the tasks.
- rickreynoldssf 3y ago
  No it was implementing a feature. No palindromes or nonsense like that.
  - jacknews 3y ago
    " No palindromes or nonsense like that." lol, so true.
JTyQZSnP3cQGa8B 3y ago
You dodged a bullet. I’ve been coding for more than 20 and the difference between juniors and seniors is: seniors know how to use a debugger instead of randomly tweaking code and writing logs which is a massive waste of time.
jgwil2 3y ago
Oddly enough, I've heard other interviewers at my company state they were impressed when a candidate for a junior position used a debugger in the interview.
frankreyes 3y ago
> "Senior Engineer" You were rejected not because of your lack of skills but to the contrary, you had more skills than that engineer. And that is a threat to that engineer professional future. You made that engineer look bad.
- BrandoElFollito 3y ago
  This is certainly a red flag for the organization (not necessarily the whole company). I have a very senior position in a very large company. I still like to be be in the hiring process of some members of my teams - mostly because I do not want to miss good candidates that may be a bit unusual. When hiring for my first line, I always wonder if the candidate could replace me. It is surprisingly difficult to find such people, who would be hardcore geeks and want to lead others. I asked the "would tout like to be in my position" a few times to successful team members. A few responded "sure". I had them present to the board, lead teams, and all but one came back to say that they are done and want to come back to what they were doing. The one that stayed did well, she is a good CTO today. I can't stand people who are scared by others and would sabotage a team. I can understand that one is afraid of competition but in a sane and big enough organization this can be worked out.

javajosh 3y ago

Out of (morbid) curiosity - what was his objection to using a debugger?

rickreynoldssf 3y ago
Just that I used it at all. There's a contingent of engineers who feel using a debugger is a waste of time and or a sign of weakness. They're the ones who like to stare at code and "run it in their heads" and dump crazy amounts of "got here" into the logs. Evidently this guy is one of them.
- bb88 3y ago
  There's two reasons I think. (I have ~25 years experience) 1. In your code should know what the edge cases, loop condition issues, etc. I think this is fair. If you don't know the edge case failures when you write your code, you could end up with something like the Microsoft Xune that shutdown for an entire day over a leap year failure. https://www.seattletimes.com/business/microsoft/original-microsoft-zune-confounded-by-leap-year-shuts-down/ https://www.seattletimes.com/business/microsoft/original-mic... Keep in mind that code review will probably not catch all bugs, it's up to the original coder to write it. This is particularly true if you're the best person on your team, say. Or you're working at a startup where no one can really review your code other than you. On the other hand well coded unit tests should help you here. 2. It's toxic brogrammer culture there -- where leetcode scores are all that matter. In which case it's probably best you were passed over.
  - throw0101a 3y ago
    > 1. In your code should know what the edge cases, loop condition issues, etc. Perhaps, but: > It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. * https://quoteinvestigator.com/2018/11/18/know-trouble/ https://quoteinvestigator.com/2018/11/18/know-trouble/ Sometimes you want to go to 'first principles' and reassess your assumptions. As a sysadmin I sometimes I resort to making sure the thing is actually physically plugged in (OSI Layer 1), the move up the stack with regards to how the bits flow.
- jansan 3y ago
  I am one of these engineers, but I consider the "cowboy style" a weakness and bad habit and would never ever judge another engineer over using a debugger.
- nunez 3y ago
  I am personally not a fan of debuggers but I would never ding someone over using them unless it was obvious they couldn't debug without them.
- javajosh 3y ago
  Strange. Whenever I use a debugger I always get a lot out of it. The code never quite executes exactly the way you envision, even with passing tests. In Java, there is a strange emphasis on classes but I've always felt objects are more fundamental, and the debugger is the way to see them and their interactions.
geysersam 3y ago
Isn't it obvious? Using a debugger implies that you expect the code you write to have bugs. Not a mindset I'd like my coworkers to have.
- sethrin 3y ago
  Is this sarcasm or epic hubris? No-one writes bug-free code, and thinking otherwise sounds like an enormous red flag.
  - geysersam 3y ago
    At our org we originally only hired A+ people. The A+ people hired A++ people and so on. Eventually we ended up with only 10x programmers and since then we haven't written any bugs. If I get around to it I'll eventually write a book about this technique.
    - sethrin 3y ago
      What you say is impossible, and it's not worth my time to discover whether you're a liar or merely deluded.
      - frfl 3y ago
        this is sarcasm, OP is just having fun
- diego_moita 3y ago
  Not sure if you're trolling or just missed the "/s" tag. A much worse mindset is to be arrogant enough to assume the code has no bugs. As a matter of principle every code has bugs. Some bugs are found, some not.
- singleshot_ 3y ago
  It’s actually worse than that: using a debugger shows that you’ve written so much buggy code that you somehow learned that debuggers exist. Steer well clear of these people!
ninkendo 3y ago
Just to chime in with a different take from the rest of the comments: there’s lots of tools that aren’t really appropriate to use during an interview. If you’re being asked to do (say) tree traversal, then in real life it’s totally fine to Google it and copy/paste a code snippet. But during an interview, presumably they want to know how much you can do on your own without “help”. It’s not that much of a stretch to say that a debugger is a level of “help” that they want to see you do without during an interview. Using a debugger is a sign that you’re not sure what your code is doing and so you need “help”… maybe the interviewer was looking to see that they could fit the exercise in their head well enough to solve the problem without a debugger.
- rickreynoldssf 3y ago
  To add more context. The task included interfacing with a 3rd party API that was poorly documented. In order to even see what a response looked like would have been incredibly hard without a debugger. Dumping it to the console would have been many pages of nested JSON. So sitting there twiddling, trying to make sense of an API doc that didn't provide a clear description of the results rather than just run the thing and see what it did was the wrong way to go. A debugger is as much "help" to an engineer as a hammer is to a carpenter. In my experience, engineers who don't use one are a detriment to the entire engineering organization wasting time and money. Anyway, yeah I dodged a bullet on that but it's such a pain in the ass that I went though a two month interview process only to be vetoed at the end like that. During that time I spent about two weeks to learn an esoteric API that I'll never use again. Oh and it would have been highly unlikely that I would have even used that API in the job. It was just a requirement that I learned it for this particular interview. ...and no I'm not going to commit it to memory just so I can pass a coding interview and if that was the expectation then this whole situation is even more ridiculous.
  - ninkendo 3y ago
    Yeah, if the exercise is in using a poorly documented API, and the answer depends on fiddly bits of trivia around how the response is structured, then a debugger is absolutely the right approach, even during an interview. You did the right thing here, and the interviewer is a dummy.

vehementi 3y ago

Probably a sign of the previous bad overhiring, and title inflation as you point out. Not so much the job market as a shitty company

bradlys 3y ago

Was it actual pair programming (where you actually build something tangible) or was it a leetcode style interview? In a leetcode style interview, I could see being thrown out for debugging. In a true pair programming exercise, I wouldn’t think this would be super common but guess it depends a lot on the exercise. Pair programming is extremely variable with the tasks.

rickreynoldssf 3y ago
No it was implementing a feature. No palindromes or nonsense like that.
- jacknews 3y ago
  " No palindromes or nonsense like that." lol, so true.

JTyQZSnP3cQGa8B 3y ago

You dodged a bullet. I’ve been coding for more than 20 and the difference between juniors and seniors is: seniors know how to use a debugger instead of randomly tweaking code and writing logs which is a massive waste of time.

jgwil2 3y ago

Oddly enough, I've heard other interviewers at my company state they were impressed when a candidate for a junior position used a debugger in the interview.

frankreyes 3y ago

> "Senior Engineer" You were rejected not because of your lack of skills but to the contrary, you had more skills than that engineer. And that is a threat to that engineer professional future. You made that engineer look bad.

BrandoElFollito 3y ago
This is certainly a red flag for the organization (not necessarily the whole company). I have a very senior position in a very large company. I still like to be be in the hiring process of some members of my teams - mostly because I do not want to miss good candidates that may be a bit unusual. When hiring for my first line, I always wonder if the candidate could replace me. It is surprisingly difficult to find such people, who would be hardcore geeks and want to lead others. I asked the "would tout like to be in my position" a few times to successful team members. A few responded "sure". I had them present to the board, lead teams, and all but one came back to say that they are done and want to come back to what they were doing. The one that stayed did well, she is a good CTO today. I can't stand people who are scared by others and would sabotage a team. I can understand that one is afraid of competition but in a sane and big enough organization this can be worked out.