Hacker News Reader

Comment by rickreynoldssf | Hacker News Reader

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.

View on HN

> "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.

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.

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

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.

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.

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-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.

> 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/

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.

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.

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.

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.

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.

> In my experience, engineers who don't use one are a detriment to the entire engineering organization wasting time and money

Well that's a strong opinion and probably a closed minded one.

Maybe you exposed your mindset and this is part of the reason you didn't get the job.

After all you're being judged on everything, including your attitude. Not just your technical prowess.

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.

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.

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.

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!

Is this sarcasm or epic hubris? No-one writes bug-free code, and thinking otherwise sounds like an enormous red flag.

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.

What you say is impossible, and it's not worth my time to discover whether you're a liar or merely deluded.

this is sarcasm, OP is just having fun

Yep, this is the kind of senior tech lead advice I'm willing to shell out 475k total comp for.

I'll send you the invoice.

What? Are you implying that you don't write bugs?

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.

No it was implementing a feature. No palindromes or nonsense like that.

" No palindromes or nonsense like that."

lol, so true.

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.

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.

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

Reply on news.ycombinator.com