6 ms·

Instead we have to simulate work samples through whiteboard coding, pair programming sessions, take home coding projects, coding knowledge tests,

Instead we have to simulate work samples through whiteboard coding, pair programming sessions, take home coding projects, coding knowledge tests, etc. Very small sample size but we've had good results skipping coding exams entirely, and simply talking through some scenarios with candidates. - 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. - "tell us about a tricky technical challenge you solved" - ask them what makes a for good code review on a pull request / what makes good code review culture in general - ask them about things the team did well at their previous role(s) and things they'd improve, and how they'd improve upon them. (not looking for "correct" answers or opinions - but they should have some opinions) - what are some technologies/frameworks/languages you'd like to learn next? again there's no "right" answer. but if they don't have any - red flag, right? - etc This of course presumes that some minimal screening has been done to make sure they're actually a software developer; an initial Fizzbuzz screen etc. At each step of the way we discussed relevant technical bits in a natural and conversational way. For example if they mention that they "optimized" or "refactored" or "fixed" something at a previous job then naturally we ask them for the details and usually wind up swapping some stories as well. If they passed this conversational interview, we usually extended an offer to them within 24 hours or less. Sometimes we waited longer and they got snatched up by another company. Of course this sort of interview doesn't tell you about their work ethic and how reliable they are and so on. But, neither does a lengthy coding assignment-based process either. And the "conversational" method gives you a sense of how they'll fit in with the team. Considering how quickly good candidates are snapped up, doing "fast" interviews like this can be a big advantage for your hiring efforts. If worst comes to worst, and they don't work out, you can part ways. It's not like either side is locked into the employment agreement. Depends on your specific locale a bit, of course -- and at my current employer we're helped by being a remote team, so it's not like we're asking folks to relocate or anything.

vlovich123 5y ago
> - 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.
- glofish 5y ago
  page loads slowly ... it is the database query man ... make sure to join the fields properly :-)
  - JohnBooty 5y ago
    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.
- selykg 5y ago
  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
- NationalPark 5y ago
  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.
  - majormajor 5y ago
    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.
msie 5y ago
"tell us about a tricky technical challenge you solved" I have so much trouble remembering previous challenges I've overcome. I don't ruminate on them, I just move on...
- agustif 5y ago
  Then just do a few canned answers before getting into interviews, so you don't have to wait and think about it and just shout out the most appropriate one you can think of the list you made?
- tempest_ 5y ago
  You don't need to ruminate on things like this but there is a lot of value in keeping a light dev journal of sorts about what you have done and the results. Makes it way easier in interviews or ever just in a normal performance review where you can refer back to things.
- JohnBooty 5y ago
  Well, if I was your interviewer, I'd say "no worries." I'd be fine if you had to skip a few questions like this and did well on the rest. That's a fairly common interview question, though, so it's a good one to rehearse!
- wintermutestwin 5y ago
  Yes, I have found that this question just selects for people who can recall well on the spot, or worse, can make up some a believable canned war story and articulate it well. As such, it is really testing a particular set of social skills which have minimal bearing on an engineer's ability to do their job.
  - JohnBooty 5y ago
    it is really testing a particular set of social skills I need my engineers to have strong communication skills, so this is intentional and desired. ...which have minimal bearing on an engineer's ability to do their job In positions I've held, communicating and remembering are pretty desirable qualities. For engineers and others. I need my engineers to be able to do those things. You obviously don't. That's fine. We'll hire different engineers. Everybody wins.
majormajor 5y ago
I've generally found more people flunk this sort of interview than flunk a whiteboard one. Namely, if you've had only boring, uninteresting jobs so far, you might not have a truly interesting "tricky technical challenge you solved," and similar gaps around the other questions. Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing or... Whereas tossing an algorithm question or two at them too to see if they can figure it out at least potentially screens for potential in a way this conversation doesn't. So I always make sure we do both on interview loops, because I don't want to reject you just for lack of good past jobs, OR because of lack of studying algo problems recently (the good senior candidates crush the conversational one even if they're rusty on the algorithms).
- JohnBooty 5y ago
  Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing I feel like it would be tough to spend any amount of time developing web apps, even if they're just internal tools, without hitting a basic performance issue like an n+1 query situation where you accidentally write a page with 500 queries or something. But maybe that's me... maybe devs are better than me these days. I hope so =) There are of course innumerable network related reasons an app could slow down and we wouldn't expect a software dev to dive into them... I'd expect them to just be able to do some ultra basic stuff to rule out a network issue and zero in on the application stack.

vlovich123 5y ago

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

glofish 5y ago
page loads slowly ... it is the database query man ... make sure to join the fields properly :-)
- JohnBooty 5y ago
  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.
selykg 5y ago
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
NationalPark 5y ago
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.
- majormajor 5y ago
  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.

msie 5y ago

"tell us about a tricky technical challenge you solved" I have so much trouble remembering previous challenges I've overcome. I don't ruminate on them, I just move on...

agustif 5y ago
Then just do a few canned answers before getting into interviews, so you don't have to wait and think about it and just shout out the most appropriate one you can think of the list you made?
tempest_ 5y ago
You don't need to ruminate on things like this but there is a lot of value in keeping a light dev journal of sorts about what you have done and the results. Makes it way easier in interviews or ever just in a normal performance review where you can refer back to things.
JohnBooty 5y ago
Well, if I was your interviewer, I'd say "no worries." I'd be fine if you had to skip a few questions like this and did well on the rest. That's a fairly common interview question, though, so it's a good one to rehearse!
wintermutestwin 5y ago
Yes, I have found that this question just selects for people who can recall well on the spot, or worse, can make up some a believable canned war story and articulate it well. As such, it is really testing a particular set of social skills which have minimal bearing on an engineer's ability to do their job.
- JohnBooty 5y ago
  it is really testing a particular set of social skills I need my engineers to have strong communication skills, so this is intentional and desired. ...which have minimal bearing on an engineer's ability to do their job In positions I've held, communicating and remembering are pretty desirable qualities. For engineers and others. I need my engineers to be able to do those things. You obviously don't. That's fine. We'll hire different engineers. Everybody wins.

majormajor 5y ago

I've generally found more people flunk this sort of interview than flunk a whiteboard one. Namely, if you've had only boring, uninteresting jobs so far, you might not have a truly interesting "tricky technical challenge you solved," and similar gaps around the other questions. Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing or... Whereas tossing an algorithm question or two at them too to see if they can figure it out at least potentially screens for potential in a way this conversation doesn't. So I always make sure we do both on interview loops, because I don't want to reject you just for lack of good past jobs, OR because of lack of studying algo problems recently (the good senior candidates crush the conversational one even if they're rusty on the algorithms).

JohnBooty 5y ago
Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing I feel like it would be tough to spend any amount of time developing web apps, even if they're just internal tools, without hitting a basic performance issue like an n+1 query situation where you accidentally write a page with 500 queries or something. But maybe that's me... maybe devs are better than me these days. I hope so =) There are of course innumerable network related reasons an app could slow down and we wouldn't expect a software dev to dive into them... I'd expect them to just be able to do some ultra basic stuff to rule out a network issue and zero in on the application stack.