[dead]
Bug squash: An underrated interview question
31–40 of 282 posts
Re: Bug squash: An underrated interview question
#32I was thinking, wouldn't it be fairer to do the test in an online code sandbox where being able to build and install isn't an issue? Then I thought, isn't letting the candidate use their own machine and debugging tools about as biased as hiring a limo driver based on how fast they can drive their own car? It does tell you who's a real "car guy" or "Unix guy", it just has a slight disparate impact by screening for peo…
We would run stuff in repl.it, you get the shared codespace and also don't waste time on the ops issues (which are maybe interesting and you really want devs to be able to handle but also entirely incidental complexity for most devs).
In abstract I think it's great to have people use tools their comfortable with, but I dislike dinging people because they write good code but are not good at unborking Python venvs (less of a problem now) (yes you can be a good programmer and still lose time on dumb environment stuff)
Re: Bug squash: An underrated interview question
#33How much time do you allot for this thing? Cloning the repo, dependency installs, server/DB setups, possible build steps, configuring the IDE to the project ... even if the whole thing is containerized, just going from nothing to running code in an IDE alone could be expected to take 20-30 minutes of the interview.
You just need to rewrite the dev tools in rust!
Joking aside, modern fast tools like bun can make this type of interview way more viable.
I once conducted this type of interview where the candidate had to install node on their windows laptop and... we spent most of the time debugging their install :/
Re: Bug squash: An underrated interview question
#34I was thinking, wouldn't it be fairer to do the test in an online code sandbox where being able to build and install isn't an issue? Then I thought, isn't letting the candidate use their own machine and debugging tools about as biased as hiring a limo driver based on how fast they can drive their own car? It does tell you who's a real "car guy" or "Unix guy", it just has a slight disparate impact by screening for peo…
yikes. any time I'm asked to use a sandbox I ask if I can copy/paste to my own editor and share the screen.
Otherwise I'm easily 4-5 slower and can't think as clearly because of errant keystrokes.
Re: Bug squash: An underrated interview question
#35[deleted]
Re: Bug squash: An underrated interview question
#36I've only had one "find the bug" interview, and it was awful:
- Didn't set you up with a way to reliably run/test the code, nor a step-through-debugger which, jeez is it 1980? Like setting up a repo in a language you aren't familiar with (say getting your py-env exactly right) can take a whole hour if it's not your main language.
- Didn't have standardized questions, which is hugely problematic (some bugs are 2 orders of magnitude harder than others)
- It also just seems like there's a huge random element, like am I debugging code written by somebody who thinks at the same level of abstraction as me? Did they write comments I understand?
Re: Bug squash: An underrated interview question
#37How much time do you allot for this thing? Cloning the repo, dependency installs, server/DB setups, possible build steps, configuring the IDE to the project ... even if the whole thing is containerized, just going from nothing to running code in an IDE alone could be expected to take 20-30 minutes of the interview.
In my experience doing these interviews in Node and Python, it takes about 5 minutes to get running. If it takes more than that... maybe use a different codebase.
Re: Bug squash: An underrated interview question
#38If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.
Re: Bug squash: An underrated interview question
#39If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.
On the flipside, I've spent an hour with a candidate who seemed great, but could hardly _actually program_. It was a bizarre dichotomy. Dude was clearly smart as hell but was so caught up in building perfect abstractions in parts of our software that _didn't matter all that much_ using languages that nobody else knew or wanted to use.
I get it, your fun language is fun. But if the dev shop is 60% one language and 39% another, I don't really care about the small improvements. You need a strong reason that it actually _helps the business_
Re: Bug squash: An underrated interview question
#40If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.
That biases heavily to candidates with good people skills and the skill to take over a conversation. Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous.