21–30 of 282 posts
- People were allowed to use their favorite IDEs - so you could see how proficient some people were
- Great engineers are really really good at debugging - it was great to see how people debugged and it helped me pick up a few things as well
- People couldn't leetcode their way out of this
[1] https://github.com/emilybache/GildedRose-Refactoring-Kata/bl...
I also like the related challenge of, “add a feature that does X” to a codebase.
I've done interviews like this and one major pitfall is the start-up time. It's possible to spend an unreasonable amount of time debugging cold-start issues with getting the repo set up, dependencies installed, and the app to build while the interview slips away. These things are representative of the first week on a new team or project, maybe. Figuring out why bundler can't seem to download the dependency in the gemfile isn't my idea of a good use of interview time.
I like this approach far, far more than coding tests! > It’s fun. It’s fun in the same way an escape room is fun. It’s fun because of the dopamine you get when the test suite blinks green. Keep in mind that for lots of people in a job interview setting (even excellent candidates) this is not fun, this is stressful. It may be fun on the job or at home, but the stress of a job interview both eliminates any "fun" aspect…
It’s a better demonstration of knowing how software works imo. But I am biased because this sort of thing is one of my strengths.
It was very helpful for sanity checking if a person was able to be in front of a computer. There's a bit of a challenge because I think there's a pretty low ceiling of performance (strace on a Python program is fun, but our bugs are not that deep!), but we could use it to also talk about new features on this mini-system and whatnot.
General feeling on it was "this is a great filter", because ultimately we needed people to just pass above a minimum skill bar, not be maximally good at coding. And having the exercise really helped to communicate the day-to-day (which can be tedious!)
> You’ll need at least one question per language that you want to allow people to interview in. ... “Was this performance poor because they’re bad at debugging, or just unfamiliar with this language’s tools?” Not necessarily a con. Different languages/tech stacks have very different tools. I.e. debugging a GC issue is different than debugging a network issue is different than debugging an embedded issue. If you chose…
> If you chose a language for a very good reason, then it's not a con to filter out those who aren't familiar with that language enough to debug an issue in it The language is based on/chosen by the candidate. We want to map the candidate to whatever language in our repository of "this question in different langs" is closest, to control for the candidate's familiarity as much as possible. If you're screening to only…
I agree with that. I work somewhere that uses a lot of OCaml, we don't screen out those who don't know OCaml, but it usually helps them, since static analysis is easier with an ML family language than say, javascript.
> We want to map the candidate to whatever language in our repository of "this question in different langs" is closest
If there's not a close language in any of your repositories for the candidate, then I think that's a good signal that candidate may not be a great fit. As mentioned before, we don't necessarily ask candidates to write OCaml, most functional languages will have a similar bug + fix.
> problem statement to debugged bug what if the problem you might normally run into is perf issues related to the language? I.e. HFTs usually use C++ and perf = $$$. I would agree that yes, those who have worked on say Rust could be good candidates, but if someone has years of experience in writing highly performant C++, and that's what the job requires, probably easier to look for those candidates.
I definitely agree with you in general, just pointing out that there are times where being familiar with the language used is desirable.
I had golden images with some scenarios I wrote myself, and the images automatically shared a tmux session over http so I could follow along without requiring the candidates to screen share.
I did have to ask for IPs so I could ensure the machines were just available to me and the candidate, but it was otherwise pretty seamless!
Though now that https://sadservers.com/ has a paid service it might be worth looking into.