> - give them a hypothetical problem ("the page is loading slowly") and role play how they'd troubleshoot it - do they understand how different bits of the stack fit together? have they ruled out network issues before digging into the code? etc.
I don't know. I think I'm pretty good at troubleshooting on the job (since I can be the one to troubleshoot & solve the trickier bugs) but thinking about doing it in an interview setting makes me nervous. It feels too fickle & up to the biases of the interviewer that day, not to mention that any serious production bug relies on knowing how the software stack operates & which things are relevant, all things that are ambiguous in an interview the interviewee would just be stuck grasping in the dark to try to figure out which scenario you might be describing.
The rest seems fine, but I'm curious about your experience with the live debugging & if you've considered cutting it.
but thinking about doing it in an interview setting makes
me nervous.
I felt it went pretty well in the interviews and didn't seem to introduce any extra stress.
Personally, if I was being interviewed, I'd really prefer this to coding exercises as those really crank up the anxiety for me. (But of course everybody has different preferences!)
not to mention that any serious production
bug relies on knowing how the software stack operates
& which things are relevant,
Oh, I think maybe I didn't communicate this aspect properly in my post.
There's no right answer. We're just looking for their thought process and how they might look up and down the stack to zero in on something. Of course they would need to ask questions about the architecture along the way. We do communicate all that up front - it's their questions that we're looking for.
The rest seems fine, but I'm curious about your experience
with the live debugging & if you've considered cutting it.
Well it's only been a handful of developers, but I felt it was helpful.
I think that kind of exercise is good for distinguishing "recent code school graduates" who are smart and can write code for one or two parts of the stack, from more experienced devs who have experience understanding how all the pieces of the stack fit together in a production environment.
I'd really do well on these types of interview questions. I've spent a great deal of time troubleshooting the most difficult software issues for the teams I've been on. I'd rather not dox myself here, but troubleshooting is a pretty big thing I've done for the past 10 years.
Just today I discovered the biggest issue we've been encountering on our platform, and I'm not even in a developer role here. The developers didn't track it down since I got them involved, but here I am coming in and figuring it out, and it didn't even require access to the source code or how the platform works.
At the end of the day these types of issues come down to creativity and outside the box thinking than it does knowing how the specific software platform works. Looking at bugs and issues in a way that isn't subject to preconceived ideas and existing knowledge.
Sounds like a fun interview for someone like me lol
I've done these sorts of questions before and the point (more me at least) was two-fold:
1. Do they understand the basic machinery of a web application (assuming the job is about building web applications)?
2. Can they take a vague problem ("the page is loading slow") they might get from an actual non-technical user and drill down to identify what precisely the issue is? Is it DNS? Is it a proxy server/load balancer? Is their latency at the DB layer? How would you tell the difference between all of these?
I'll take high level architecture design and software coding problems over live debugging any day. Which is kind of my point. This kind of session is going to potentially weed out candidates with different strengths & a good team is a mix of a variety of strengths.
Surely an interview scenario is far less stressful than an actual outage though? Your performance in the real one is a lot more important for your job/career than the interview is.
Not necessarily. People put a lot of stock into interviews because they could affect not just today, but years of their future. Whereas nobody really expects to get fired if they can't resolve the outage in 45 minutes (instead of 3 hours), say.
Especially if you're junior and your current job sucks and you've never (yet) passed an interview for a better job.
This is counter-productive, but the brain doesn't always work how you'd want it to.
Yeah this is generally what I'm trying to lead them to.
If it's not a network issue, it's probably the database, right? Generally you've got an n+1 and/or some individual huge slow queries. I'd interested in knowing how the candidate would zero in on the database possibility and how they might narrow it down from there.
I don't know. I think I'm pretty good at troubleshooting on the job (since I can be the one to troubleshoot & solve the trickier bugs) but thinking about doing it in an interview setting makes me nervous. It feels too fickle & up to the biases of the interviewer that day, not to mention that any serious production bug relies on knowing how the software stack operates & which things are relevant, all things that are ambiguous in an interview the interviewee would just be stuck grasping in the dark to try to figure out which scenario you might be describing.
The rest seems fine, but I'm curious about your experience with the live debugging & if you've considered cutting it.