Bug squash: An underrated interview question

https://blog.jez.io/bugsquash/

by jez • 2 years ago

434 271 2 years ago

blog.jez.io

JohnFen• 2 years ago

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 and makes even simple tasks more difficult. Just mentioning that to encourage some amount of empathy and understanding for the candidate.

draw_down• 2 years ago

The discomfort and stress is a given in any interview. What I think is nice about this is it doesn’t require you to emanate fully-formed, nicely designed code from your brain on the spot. Instead you just have to navigate the codebase, read it and understand it.

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.

nine_k• 2 years ago

This approach then selects those who are relaxed. The candidates that have five more interviews at advanced stages, and likely to receive several offers, as opposed to candidates who badly need a job.

The former kind of candidate may be more desirable for the employer :-/

shermantanktop2• 2 years ago

Depends very much on the company. Fishing in the unemployed-and-desperate end of the pool is a real tactic. The odds are good but the goods are odd, as they say.

teaearlgraycold• 2 years ago

Even if I have no other offers I’m pretty good at maintaining a calm demeanor in an interview. I think it’s served me well over the years.

burnished5• 2 years ago

Relaxation during an interview can also be a function of practice. Obviously when you're squeezed its more difficult to get that practice in, but if you can it can help tremendously.

b200009• 2 years ago

for me cracking the coding interview is stressful

i prefer the bug squash question. i have 20 years of experience. i will probably do well.

a fresh grad might fail. do i care? no. leetcode has benefited fresh grads and is being used to discriminate against those with anxiety and other disorders and those who are older.

i think it is refreshing to try a different interview method, one that benefits those with experience.

ta_1138• 2 years ago

I administered bug squash questions a few dozen times. Experience definitely trumped the smartest, most prepared young programmers, because no matter how much they studied, they hadn't really faced a real test suite in a large codebase. We had to rate them on a different scale, because otherwise very few of them passed.

yonrg2• 2 years ago

What is wrong with capitals?

mattpallissard4• 2 years ago

I can't speak to anxiety or other disorders but I have a hard time swallowing that leetcode discriminates against the older crowd.

I'm not older, but I was in the industry prior to the leetcode style interview. I've never sat down and "grinded" leetcode but I've also never had a problem with those styles of interview once they became common. Neither have my former co-workers. I have a few friends that are still working, past retirement age, that would crush any problem you threw at them.

In my experience, it's not much different than the whiteboard interview. Sure the presentation of a problem can stump you for a moment, but with a few good follow up questions a solution, however naive, becomes apparent.

I had a mentor early in my career that repeatedly said "There is no such thing as an unsolved problem in computer science". I think that mostly holds true, you either recognize the pattern and implement, or you learn and implement next time.

That all said, leetcode style interviews are the interview version of a "bad code smell" and I'd strongly prefer a bug-squash style, even if it was in a completely unfamiliar programming language. Actually, an unfamiliar programming language might make it fun.

Hamuko2• 2 years ago

Yeah, I've had a live bug squash interview (SSH into a server where a script is not functioning) and I didn't find it particularly fun. I did manage to get through it and the interviewer seemed impressed, but it's still stressful to do it with someone silently judging you. I'd much prefer take-home assignment and do it at my own pace, but I guess that might be susceptible to "cheating" (whatever you consider it being).

sqeaky10• 2 years ago

Doesn't a take-home task also prevent any chance to ask questions in the middle? And I mean questions both ways. An interviewee can ask questions about the code base that might be common knowledge to people on the team and an interviewer can ask questions about why a thing happened and gain insight into the interviewees thought processes.

I get that interviewing is a skill on its own, and not everyone has skills that work in an interview that transfer to the day-to-day job but don't most day-to-day jobs have a large communication component?

brainzap• 2 years ago

thanks for pointing this out

StefanBatory2• 2 years ago

Isn't that what companies would look for, though? They want people who can work under stress. If you had two equal programmers, and one who was stressed and the second who was not, any company would pick the second one without thinking.

chii2• 2 years ago

That assumes that during regular work, you'd be under stress. If it were the military, then yes, i would agree - working while you're being shot at means you need to be able to work under stress.

However, a lot of people don't do well under stress, and in many corporate settings, there's usually no real source of stress (except perhaps artificial stress induced by management). Someone might work much better in a stress free environment than someone else under a stressful environment, but you'd then easily miss these candidates by structuring the interview to be stressful.

lapcat9• 2 years ago

All stress is not the same. Interview stress is actually very different from working stress.

Ask a firefighter who rushes into burning buildings for a living to give a public speech in front of a large crowd of people in a non-burning building. Which is more stressful? For the firefighter, it may be the latter. Fighting fires is what they train for, what they're experienced with, whereas giving speeches is not.

A lot of people, no matter the profession—firefighter, programmer, etc.—have a great fear of public speaking. Likewise, a lot of people, no matter the profession, also have a great fear of job interviews, especially the crazy audition-style interviews of programmers. It's simply human nature, with little bearing on job performance in general. We shouldn't be giving auditions to people who aren't stage performers. Personally, I never work with someone watching me—definitely not a judgmental stranger who will fire me for any perceived peccadillo—nor do I ever have some specific narrow time limit on my work in the range of 15 minutes or so.

playingalong• 2 years ago

Some organizations (although admittedly not all) put a lot of effort to offer a creative environment for their creative staff. So they optimize for something else.

A bit like 100m race vs. marathon.

burnished5• 2 years ago

> They want people who can work under stress.

Not exactly. Interviews are a different kind of stress that is usually a direct result of being observed in an unfamiliar and somewhat high pressure situation. You might have to deal with an outage at work, but typically your employment isn't on the line (less pressure) and you have a great deal more familiarity.

Some hiring practices intentionally try to create a more welcome, less stressful experience because they don't want to bias for interviewing skill (as opposed to fitness for the job).

nailer3• 2 years ago

It may be fun on the job or at home, but the stress of a job interview both eliminates any "fun" aspect and makes even simple tasks more difficult.

Suggestion here: leave the room and come back in 40 minutes. Let them debug, fix the problem, and present to you when they're done.

harimau777• 2 years ago

I wonder if this is an improvement over a conventional white boarding question.

It seems to me that debugging in particular is often dependent on the developer realizing some edge case or scenario where things circumstances line up to produce a bug. In that case, wouldn't a "bug squash" end up being similar to a "gotcha style" white boarding question.

The author, quite correctly, says that the interview should be scored not on whether the candidate can immediately vomit up a solution but on whether they can demonstrate their an organized thought process. However, isn't that true of white board questions as well?

Overall, it seems to me that the real problem with conventional white board questions is when the interviewer focuses on whether the candidate gets the right answer rather than on whether they demonstrate the ability to problem solve. While it sounds like the author is a good interviewer who focuses on assessing the candidate's thought process, it's not clear to me that giving debugging questions is actually what causes that.

simonw• 2 years ago

"It seems to me that debugging in particular is often dependent on the developer realizing some edge case or scenario where things circumstances line up to produce a bug."

I don't think that's the case if there's a test failing. If a well-written test fails, that means there's a completely scoped out requirement for how the feature should work. The candidate should know how to use a debugger, so they should be able to start diving in and figuring out how the code works and what might be going wrong. I don't think that's likely to produce gotchas.

berikv• 2 years ago

Although I like this interview question, it has a big downside. You make the candidate spend quite a lot of effort while you as an interviewer don’t learn much. The answer to “Can this candidate find and fix this bug?” is not necessarily equal to “Is this candidate a good expansion of the team. What do they bring that we need?”

ryandrake• 2 years ago

It's kind of a fizzbuzz-ish weed-out question: If they can do it, sure, you haven't learned that much, but if they cannot, then you know with pretty high certainty that they're not going to add to the team.

aaronbrethorst2• 2 years ago

Astonishingly, I’ve found fizzbuzz to be a shockingly good weeder question for tech screens.

Noumenon722• 2 years ago

To me this sounds like a relaxing break from the effortful part of the interview.

ozr• 2 years ago

It rarely makes sense to hire for a specific need. I want people that are smart and high agency. Seeing how they approach problems like this is generally enough to tell.

I've done similar interviews in the past and they are remarkably high signal.

jez3• 2 years ago

The point of the interview is not to answer "Can this candidate find and fix this bug?" but rather "what is the candidate's approach to fixing unknown problems?"

A good performance looks like making a hypothesis for where the bug is, testing that hypothesis, and repeatedly narrowing in closer and closer. Finding and fixing the bug is irrelevant!

A bad performance might look like

- running out of hypotheses for what might be causing the bug

- making hypotheses, but never testing them

- failing to interpret the result of their test of the hypotheses (thinking it confirms one thing, when it doesn't actually confirm that, or it confirms the opposite)

johnisgood5• 2 years ago

So like trial & error? Modify, compile, run?

photon_lines2• 2 years ago

Sorry, but do you have any data that shows 'great' candidates run tests and use your approach of finding / fixing bugs? Read the book 'Coders at Work' which describes some of the best developers of all time - most of them use print statements to find bugs / debug. Btw, I've solved bugs in 2-5 minutes which some developers spent hours or days working on (to their amazement) -- I've done this countless times in the past without using code or any debugging / testing tools -- all it took was reading the code and figuring out in my head what was going on and which data elements could introduce problems -- so I suppose I belong in your list as well? Sorry I just want to see the thought process here, to me it makes 0 sense and all the HN commenters commending the parent article are also making me absolutely scratch my head since the suggested process makes many many assumptions without having any data to back them up.

yas_hmaheshwari• 2 years ago

This is one of the interview questions at Stripe, and I agree that it was the most "fun" part of the interview (It is still pretty stressful giving an interview, but magnitude times much less so than converting a BST to doubly linked list, and converting it back )

ajbt2001282• 2 years ago

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

deathanatos• 2 years ago

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 candidates who can code in the language your company primarily works with, you're missing good candidates. The best are going to be able to pick up a new language rapidly, particularly if your language is a mainstream one that's probably imperative or OO-ish, or both; adding a non-esoteric language to one's repertoire is just not that hard a thing to do. But in the interview, I don't want them struggling with syntactic bull, as it's not a useful signal; I want to know how they think, whether they've seen code before, and can they reason from problem statement to debugged bug.

ajbt2001282• 2 years ago

If you're screening to only candidates who can code in the language your company primarily works with, you're missing good candidates.

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.

Noumenon722• 2 years ago

I 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 people with money and hobbies. I mean, I think you should be allowed to hire these people because they will be better at the job, but hopefully they could also show that in a sandbox test.

singleshot_• 2 years ago

Decent product idea? I’ll stay tuned for your Show HN.

dingnuts• 2 years ago

your job doesn't let you configure your own environment and tools?

ElectricSpoon• 2 years ago

I find editors to be deeply personal things. Throw a vim user in vscode and you might be disappointed, and vice-versa. I don't care about your tools, I care that the sum of you and your tools make you good.

I think the good middle ground is having both a canned environment and allowing candidates to use their own... Unless the job is about debugging production systems where only vi is available, in which case that interview might as well represent the actual job.

rtpg2• 2 years ago

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)

ibash2• 2 years ago

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.

jez3• 2 years ago

I think there's the chance to do both!

Some candidates will not have problems installing dependencies and want to use their own tools.

Other candidates will want to not have to think about their environment.

Providing an online code sandbox doesn't preclude allowing candidates to do it on their own laptop!

kenschu4• 2 years ago

This is exactly what we've built!

We take in these bug-squash/Github based repos, serve them in VScode Web/Jetbrains/etc, and give you instant results

Email is in profile if anyone's curious to see it live

Mistletoe• 2 years ago

Thought it was going to be about squashing a bug or releasing it outside your house, which would tell me a lot more about a potential employee than this.

franciscop• 2 years ago

I had a very similar intro experience to dev. I started with some friends as a hobby, and my first paid jobs were when I was hired to do a bunch of small tasks in different projects. Add some animations in this Ember project, fix some bugs in this Wordpress project, add a very specific feature in this Angular project, etc. I probably did a terrible job at that time and I'll always be grateful, but it also taught me A LOT about jumping into a foreign codebase and start working on it almost right away, especially since I was paid hourly and I was super-aware I was paid to fix the problems and not to learn the code. IMHO what this article explains is one of the most valuable bits I retain from that time.

kopirgan• 2 years ago

I could be wrong but given how fast things change in this business, this seems to test very micro level skills not the learning and adaptability skills.

What if a guy could, given the business or technical issue the code solves, write something faster than he could fix others code?

May be the job is about heads down coding so this bug fix test is appropriate..

from-nibly• 2 years ago

Then you could do that and showcase that you can write code incredibly fast.

__float5• 2 years ago

How is debugging a "micro level skill"? Jumping into an unknown project/system/whatever is something you will likely have to do at some point. (Sometimes it might be code you wrote yourself years ago, but revisiting without any context makes it feel unknown.)

Is this hypothetical guy always writing 100% correct code?

vandyswa• 2 years ago

I've done the equivalent of this by asking them to describe an interesting bug they've encountered in past lives; how it came up, how they hunted it, how they fixed it. By listening to them describe the work, asking questions, and following their thought processes, you can come to a fairly good hire/no from this single walk-through.

I know, it's short and humane, so not a good fit for current Sillycon Valley culture.

sk11001• 2 years ago

There’s no chance that I can come up with a good bug story on demand without any preparation.

tdeck3• 2 years ago

For past experience I reviews like this it's a good idea to give the candidate advance notice.

serpix• 2 years ago

compare this with the technical interview bomb of demanding you write a full blown program right fuking now, complete with tests. Which one do you prefer?

izacus• 2 years ago

Ok, but why do you think you should be hired in that place though? :)

Lvl999Noob• 2 years ago

Live bug squash is better, imo. I was part of the production support at my $DAYJOB. My work was literally finding and squashing bugs all day. And yet, if you were to ask me for interesting stories, I won't be able to tell you anything. Maybe I'll remember the latest bug I solved but most of the time, once the bug is resolved, its off my mind. I will have to go through my jira and github history to first see which bugs I even worked on, then filter for the interesting ones and then try to remember the story instead of just the root cause.

IshKebab3• 2 years ago

Ugh "tell us about a time" questions. I'm so glad the tech industry generally doesn't do that nonsense.

If you do get asked these questions just lie.

sensanaty• 2 years ago

I straight up lie and make something up for these "tell me about a time..." type questions

Unless it was literally a week ago, I work on too many things to ever remember anything, and for me it's just a fact of the work that I'll be fixing bugs or whatever the questions asks. Nothing stands out, because I don't consider any of them to be some sort of special occasion worth keeping track of

aray07• 2 years ago

I did a bug squash interview when I was interviewing for new grad positions and it was one of my favorite interviews (both as an interviewee and an interviewer)

- 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

boredtofears• 2 years ago

I’ve always liked the Gilded Rose refactoring[1] which is similar but about improvements/feature requests instead.

[1] https://github.com/emilybache/GildedRose-Refactoring-Kata/bl...

jpmoral2• 2 years ago

Had an interview question like this where the interviewers were very impressed. Said it was the fastest and cleanest they'd seen anyone do it, and in an unfamiliar framework no less. Unfortunately it wasn't enough for me to get the job. I had a couple of answers in the next section they didn't quite like.

__float5• 2 years ago

I had a couple of answers in the next section they didn't quite like.

Could you say more about this? Were they technical or behavioral interviews?

jpmoral2• 2 years ago

Technical. IIRC:

- I did the system design at the wrong level of abstraction (too low)

- Got asked about lowish-level database details. I took the question at face value and said I didn't know. What I should have done was explain what I did know (which was at a level slightly higher than the question), make an educated guess, and say how I would find the information. I still don't understand why Id didn't do that as I've always done it in interviews before or since.

This is my own assessment, they didn't give detailed feedback. Just that I wasn't strong enough in some areas (paraphrasing).

michaelteter• 2 years ago

This is indeed a good interview challenge, and as a candidate I’ve enjoyed taking it the couple of times I have encountered it.

I also like the related challenge of, “add a feature that does X” to a codebase.

lr4444lr2• 2 years ago

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

ibash2• 2 years ago

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

photon_lines2• 2 years ago

FYI just small tip on the Windows / Node front, you should just install & use NVM instead of Node directly - will make many headaches go away.

s17n• 2 years ago

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.

lr4444lr2• 2 years ago

What exactly is the interviewer looking for? Familiarity with tools, or actually debugging skill? I like the idea of debugging questions, I'm just not convinced all this setup and "use your own tooling" is necessary,and that a long enough snippet of given whiteboard code sample can morr effciently test for debugging skill. I can always teach (and learn!) new tools, and frankly, there is value to me as an interviewer to see someone manage without his tools.

__float5• 2 years ago

The bugs are chosen in projects that don't require this much setup. (There is no server/database, they use standard tools for the given language, and they are generally solvable without needing an elaborate IDE/debugger setup. Of course that may help, and it's why you bring your own computer and choose the language ahead of time.)

kenschu4• 2 years ago

Agree! This is one of the core pains we set out to fix. Using a CDE to package everything nicely for the candidate goes a surprisingly long way for their experience.

I think there's a valid point that any IDE != a candidate's local setup. But I think there's a compromise there - we try to offer a variety of common IDE's + a few mins of prep to download extensions, etc before you're thrown in the thick of it.

tdeck3• 2 years ago

I somewhat disagree that this is reflective of a person's everyday work. Usually we're only ever working on at most handful of codebases at a time, and getting oriented in a completely new application (including getting it to build and run on your machine) doesn't happen every day.

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.

rtpg2• 2 years ago

At one place there was a bug squash interview like this. Rough idea was we wrote a very small version of a system we had in our app (some data-syncing-then-displaying service), with a handful of bugs and a very simple feature request.

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!)

bluGill9• 2 years ago

I've interviewed a few people who have a great resume and came off well in the interview, but I was left wondering if they could write code. (HR only allows me to ask specific research based questions in an interview and so it is easy to answer well without giving any indication you can write code). We now have some filter exercises that are about if you can write code at all.

Izkata3• 2 years ago

(strace on a Python program is fun, but our bugs are not that deep!)

They don't need to be deep to be useful. I once used it on nodejs on a hunch, looking for anything that felt "off", and discovered it was accessing settings files I had no idea even existed. Turned out the other dev was having problems because of one in his home directory the rest of us didn't have.

tharibo• 2 years ago

This.

Keep in mind people that a job interview is to check wether you want to work with the person, not to judge if they "pass" the test.

Or to say it differently, they don't have to find and fix the bug, they have to demonstrate ability with the tools, a good attitude, a match with your work culture.

flurie• 2 years ago

I'm not too proud to admit I took the general concept from https://sadservers.com/ and turned it into something I could use for interactive debugging interviews.

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.

fduran• 2 years ago

Hello, SadServers author here. Zero shame in adapting an idea you found somewhere; I'm super happy you built something useful.

I've thought of adding programming debug scenarios (I even got sadbugs.com lol), may implement in the future.

I'd love to see what you've done, please feel free to connect :-)

zug_zug2• 2 years ago

I'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?

trevor-e• 2 years ago

Yea there's a huge element of randomness to these kinds of interviews. I wasn't a big fan of them at Stripe. You can get some signal like:

- do they methodically approach the problem? - do they understand the bug? - do they know how to use debugging tools? - do they know advanced debugging tools? - do they work well in an unfamiliar codebase?

But in practice I'd say most candidates check those boxes, at which point it becomes an arbitrary evaluation unless you pass/fail them based on whether they solved the bug.

zug_zug2• 2 years ago

As it happens the place I had a really bad experience with it was stripe. I had pretty much aced every other question, but basically was setup with a problem where I didn't have a way to reliably get it running (and I wasn't even clear what the app was supposed to do, it was just some random project off of github).

Fortunately I already had an offer onhand from facebook.

leoqa• 2 years ago

I gave this interview 100+ times and my criteria boiled down to: did they propose a hypothesis and then follow it to a conclusion? Doesn’t matter if it was wrong, just mattered that they were able to falsify it or find the solution.

At the end, I would have them walk me through the bug, its cause, and the fix in very high level terms to make sure they could articulate the path we took.

__float5• 2 years ago

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

How frequently do people interview in a language other than their "main" one(s)?

- Didn't have standardized questions, which is hugely problematic (some bugs are 2 orders of magnitude harder than others)

How do you know they're not standardized? (You say in another comment where it was, and indeed that's where the blog post author works. It's described as a pretty standardized process by my reading of it.) You can pass the interview without actually solving the bug, but I get it's easier to blame the problem than admit you struggled with it.

tedunangst2• 2 years ago

I seem to interview in a different language every time I switch jobs.

bawolff4• 2 years ago

How frequently do people interview in a language other than their "main" one(s)?

I would say most of the time.

However i still think debugging is a core skill you should be able to demonstrate in languages that aren't your main one.

underdeserver2• 2 years ago

setting up a repo in a language [...] can take a whole hour if it's not your main language.

Even if it is your main language.

saagarjha7• 2 years ago

How frequently do people interview in a language other than their "main" one(s)?

A lot of companies have a set of "standard" interview languages like Java or C++ that may not be used by the role that is being hired for.

maxvt• 2 years ago

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?

Isn't that part of what professional software engineering is about? Unless you worked with the same group of people for a decade and have had the time to mind meld together professionally, _any_ random developer at a new company is nearly guaranteed to think in a different way and have their own philosophy of code comments.

Checking for mental flexibility and adaptation to varying approaches for others is a great subject for an interview as a software engineer.

0x20cowboy2• 2 years ago

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

cheeze• 2 years ago

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_

caseyy3• 2 years ago

Ask them to explain what 4-5 different bits of code do. When they do, ask them to explain it like they would to a junior and to a senior/principal/fellow.

It works very well and takes only an extra 10 minutes on top of the conversation.

marcinzm2• 2 years ago

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.

0x20cowboy2• 2 years ago

I disagree. That would indicate conversations skills equate to knowing what you are talking about.

"Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous."

I think that I am. I'll think about that a bit more. I don't care for popular people so, in fact, my bias might be the other direction. However, I don't think I have ever met a person who I thought was technical and proficient, but turned out not to be.

I have been forced to hire people I knew were not proficient because they passed a test, but not the other way around.

caseyy3• 2 years ago

So true. A test will only measure its set of criteria. What is a test for drive — desire to understand and learn? What is a test for how a person will respond to challenging and overwhelming prod scenarios? What is a test for if they will burn out in a month because they want to prove how rockstar of a programmer they are?

My most successful hiring has always been based on a conversation with 3-4 practical questions. I even worked in a company that had testing down to a science with all the psychometric nonsense and in the end, it just hired many sociopath-adjacents.

kenschu4• 2 years ago

There's both culture and technical elements to consider in a potential hire. I don't think anyone would contest that vetting for the culture/drive of a candidate is important. But I do think the demonstration of skills is a necessary part of technical hiring, at least for non-senior positions.

tedunangst2• 2 years ago

If all I needed to do was express my thoughts out loud, I wouldn't need to hire anyone. I can do that myself.

throwaway215234• 2 years ago

What you're describing is a low hiring bar. Low hiring bars make sense for companies that pay low to average salaries, or don't require particularly deep technical skills. But it's an awful strategy if you're trying to filter for exceptional talent and willing to pay top dollar.

BurningFrog• 2 years ago

Strong disagreement!

Sure, there is some correlation between talking and doing, but I've worked with people who talk like geniuses and code like crap. And also the opposite.

For some skills, there is just no substitute for actually have people actually demonstrate using them.

Pikamander24• 2 years ago

That sounds like a great way to end up with a dev team full of smooth talkers who you then later discover can't code their way out of a paper bag.

mikeocool• 2 years ago

I agree — this is very much the type of interview I like to give. However it took me a while to get good at steering the conversation and digging for details.

It’s really easy to let the interviewee talk through talk through all of the great things they built from a product and business perspective — and assume they understand the technical perspective. There are candidates who are really good at talking in an impressive way, but manage to talk around any true implementation details or deep technical understanding.

It’s also really easy to come away with a bad impression of someone who has a tendency to give short answers and not elaborate on things, even when it turns out that person is really skilled when you dig in.

I imagine a big part of the reason for the test-style interviews we have today is that it’s easier to train an interviewer on how to give them.

sethammons2• 2 years ago

We tried this approach. It did not work. Source: SendGrid while ramping up to become a public company. The interviewing experience involved was fairly extensive; I had probably given a couple hundred interviews in my career by then and I was not the most experienced by a long shot.

We tried to have a zero coding interview. All behavioral and experiences questions followed up by "how would you design a system to do blah." Got a candidate that did well. Hired. Turned out they could talk the talk but not walk the walk. It was wildly unexpected. They simply couldn't code well. Too long to deliver, too poorly written, usually didn't work right. We insisted on _some_ coding in interviews going forward

dave333• 2 years ago

A similar exercise but much easier to do in an interview is to give a short piece of code that does something a bit non-trivial and ask them to write (paper or whiteboard) test cases for it. Can then either run the test cases and see if they can find (all) the bug(s), or simply review vs a known list. Classic example in Myers The Art Of Software Testing is a method that takes 3 numbers as the length of the sides of a triangle and prints out whether it is scalene, isosceles, or equilateral. Many people miss a lot of corner cases.

doawoo• 2 years ago

Triplebyte (one of the best hiring experiences I ever had) gave me this during their initial interview.

They dropped an archive of a medium-ish codebase to my machine, that had failed unit tests. My task was to simply fix the code so the tests passed.

Not only did I feel engaged with the interview because I could speak aloud as I debugged, I also found it fun!

Etheryte• 2 years ago

Too bad that Triplebyte then turned around and decided to sell everyone's data after it turned out their business was not scalable after all.

awkii• 2 years ago

You're describing the parallelized web-scraper that they pointed to their own internal site? Yeah that was fun. Too bad everyone got the same question.

halfcat• 2 years ago

”what we’re observing is X, but we see Y instead.”

What?

Anyway, I’ve found these kind of interview questions rarely helpful because the scenario is either overly simplistic, or it’s some obscure bug they identified (which they only caught because it caused an outage, i.e. they also didn’t “solve” this when they wrote it).

A similarly poor interview question happens in IT operations when the interviewer asks super specific details about some CVE from 5 years ago that he’s particularly proud of pulling an all nighter to patch a bunch of servers.

__float5• 2 years ago

what we’re observing is X, but we see Y instead.

I think this might be a typo - we're observing X but want Y, or some similar variation. In any case, there's a bug.

jez3• 2 years ago

Sorry about that! edited to

What we're observing is X, but we want to see Y instead.

datavirtue• 2 years ago

It's easy to write this question. I can cut a branch with gnarly UI bugs in it, no sweat.

ryoshu• 2 years ago

One of my favorite interviews was like this, but it was a long time ago and they printed out the code and told me there was a problem. Here's a pencil. What's wrong? Most were a function call or two. In one case I remember someone was doing a loop that incremented the index of a SQL query in code and using each result, instead of querying the set and looping through it in the code.

The fun part was it was a discussion. Two people, paper and pencil, talking about the code. And the examples were from bugs they'd already squashed in a code base they inherited. It was a project that I ended up working on that had... quite a few interesting bugs like that.

mistercow4• 2 years ago

It’s easy for the candidate to self-assess their own progress.⊕ When the candidate isn’t doing well on it, they probably already knew it without needing to be told as much by the recruiter. This is a much better candidate experience than the whiplash of thinking you solved a question perfectly only to realize that the interviewer was looking for something else entirely.

Not to say that I think this is a bad type of question overall, but IMO, this is an anti-feature. The candidate does not need to accurately self-assess their performance on the day. They need to have their confidence preserved so they don’t tilt and tank the signal for the entire interview round.

bawolff4• 2 years ago

I don't know, i think the best questions are the ones where candidates fully understand what is being asked about them. If they aren't able to self-assess did they really understand the question?

kenschu4• 2 years ago

Candidates walking away pissed is itself also a problem. A significant percentage of candidates avoid buying from companies they're rejected from [1]. They also love sharing their poor interview experience with future potential applicants.

[1] https://www.wayup.com/employers/blog/how-a-positive-candidat...

mistercow4• 2 years ago

What you want is to prevent floundering death spirals. They need to understand the criteria, but if you need to hint and nudge them, they need to not feel like that means they’re bombing. Of course, you can absolutely do that in a bug squash interview, but my point is that it defeats this claimed advantage.

alexvitkov2• 2 years ago

"We don't want you to know you've already failed so we can waste your time for a month in the off-chance nobody better shows up."

mistercow4• 2 years ago

What an incredibly bad faith reply. Candidates should always be given an answer within a few days of finishing the interview. But it’s not good for a candidate to think they’ve bombed during the interview.

If someone fails my interview, it is completely possible that they’ll still get an offer. I have one data point, and my colleagues are going to collect more. I’ve changed my vote from no to yes in debriefs many times once I saw other feedback. But that’s a lot less likely to happen if my interview wrecks their confidence.

bawolff4• 2 years ago

In computer security, this sort of interview often takes the form of find the vulnerability in this app.

I like it. It feels like much more directly measuring skills than most interview questions.

zgs• 2 years ago

Kind of like the "install this software" as part of the interview process.

"My hourly rating for figuring out your bug is $X".

maxwelljoslyn• 2 years ago

My kingdom for this approach to take the place of (some/all) leetcodes.

Brystephor• 2 years ago

I had a bug squash interview today. I found it nice, but also frustrating.

It was nice because I didn't need to practice and I knew exactly how to debug the thing.

It was frustrating because my personal laptop is from 7 years ago (from college), is slow, and the dependencies and editor don't work out of the box for an a new repo. Additionally, I'd prefer to use IntelliJ like I do at work but again, that's too heavy for my computer to handle so I resort to vscode and have to figure out how to use it. So then the interview becomes debugging my environment instead of debugging the problem. Maybe that's a useful signal, but it's not really bug squashing anymore then.

So overall, it was still requiring learning but there was not a very good way to test in advance (how do you test all possible repo structures?)

jdlyga• 2 years ago

This sounds like a lot of fun to me. A lot of people dislike debugging, but I always enjoyed it. It's a bit of a murder mystery. You not only need to understand what's happening several layers beyond the initial problem, but why the code may have been written the way it is even when you find the issue.

Twirrim• 2 years ago

My favourite thing to do for "coding" interviews is to give the candidate a piece of absolutely awful python code that a friend of mine came up with for use for interviews.

There are code smells, side effects, errors, confusing syntax, a whole slew of things in it. I give them the code, tell them I'll help with every bit of python syntax (and really emphasise that I don't mark people down _at all_ for any lack of familiarity with python / python syntax), and ask them to work through the code and do a code review.

There's some python specific quirks that I largely consider bonus points at best, but anyone with any appreciable familiarity with at least one language should be able to spot a number of things. As they call stuff out, I'll dig in (or not) as seems appropriate.

So far it seems to be working out great for me as an interviewer. Candidates seem to be way less stressed than they are with a "whiteboard coding" exercise. Good discussions are showing me their development skills, etc.

bigbong• 2 years ago

Would you mind sharing it?

esperent• 2 years ago

It does seem a bit unfair - ok sure, anyone familiar with C-family syntax should be able to work through it and spot errors. But anyone already familiar with Python would be able to do so a lot faster.

I think the idea is good, but to be equitable it should be given in a language the person claims to be already familiar with. Or alternatively, only give it to people in a language they are not familiar with.

phil-martin• 2 years ago

If the goal was to objectively evaluate ability in a broad population, I 100% agree. However, if my dev shop primarily uses Python then selecting for people familiar with Python is pretty reasonable.

Thankfully there is a giant corpus of terrible code out there for any language. Especially that code written by the most evil terrible coders of all time: past-self :D

naught0• 2 years ago

I'm dying to see this code

devjam• 2 years ago

As was also pointed out in the TFA, while you may not be "marking people down" because of unfamiliarity with syntax, an interviewee who has more experience with the language (and it's debugging tools) used in the interview will have an inherent advantage over someone who isn't as familiar.

Borg33• 2 years ago

Right... Python.. Its syntax is so ugly. So I guess you can have really awful gems there with hidden bugs :)

I myself, shoot myself in a foot once doing Python code. I declared variable called 'len' and boom! What an interesting failure mode the script had. Took me a while to figure it out.

IshKebab3• 2 years ago

When I write Python it's an absolute hard line requirement to run it through Pylint and Pyright. They catch sooooo many issues you'd have to be a complete idiot not to do this (many people are unfortunately).

In this case Pylint will tell you about this mistake:

https://pylint.pycqa.org/en/latest/user_guide/messages/warni...

BodyCulture• 2 years ago

Please show some examples of such code, everyone will profit from this, no reason to hide it, thanks!

quectophoton2• 2 years ago

Yes! I love these kinds of interview questions. For some reason these feel more like a "normal" pair programming (/ code review) session, and I totally forget I'm in an interview.

Still a tiny bit stressing at the beginning while I read the code for the first time and try to understand it because I worry that I might be taking longer than the interviewer expects, but if I'm thinking out loud then that helps both of us. After I get reasonable context I can then forget about the interview and just focus on the normal pair programming / code review.

xgb84j2• 2 years ago

Great idea, that's exactly what I like to do as well.

Because many people were interested in some actual code, here is an example that we used for Java:

---

public class UserDao {

    private Provider<Session> sessionProvider;

    public UserDao() {
        this.sessionProvider = new DbSessionProvider();
    }

    public boolean saveUser(User user, ApiConfig config) {
        try {
            Session session = sessionProvider.get();
            session.save(user);
            System.out.println("User saved!");
            return true;
        } catch (DbException e) {
            EmailUtil.sendEmail(config.getTechnicalSupportEmail(), e);
            return false;
        }
    }

}

---

"Solution": We always ask the candidate "What would you change about this code?" or something similar. We expect the candidate to come up with some selection of: - Database sessions should come an injected provider. - Configuration should probably be injected as well and not passed as a method parameter. - Booleans are not canonical Java as return value. - Don't write to stdout but to a logger. - Exception handling should probably happen outside the DAO. - Don't use static methods for sending Emails without good reason. Non-static methods are easier to test.

Finding these things is as important as being able to talk about them and give background on advantages / disadvantages of doing things different ways. With good candidates one can talk easily half an hour just about this example and adjacent topics (e.g. error handling).

---

Edit: Formatting

Edit 2: added "Solution"

actionfromafar• 2 years ago

This is canonical Java. Commit and deploy!

bilekas• 2 years ago

I love the exception suppression via email.

Sr.Dev : "UserSignup failed, ask tech support what happened in our code"

Genius.

vaylian• 2 years ago

Booleans are not canonical Java as return value

What should you return instead? Or should the method return void and raise an exception on failure?

normie30003• 2 years ago

This code looks like normal enterprise Java ugliness to me - I object to it on principle, but apart from having to pass ApiConfig when saving a user I probably wouldn't identify any of the official problems you listed without familiarity with the rest of the codebase.

whatever12• 2 years ago

"Don't write to stdout but to a logger."

Not great advice given the fact that a logger paged pretty much every SDE on this planet.

hkon• 2 years ago

Ever get the answer: this code should not exist?

filcuk• 2 years ago

I work it BI and am hoping to expand the team. Does anyone have a good universal SQL code for that?

In my interview, I was given a T-SQL code, where I did point out the mistakes, but was told my solution wasn't optimal, but that was because I've never used that flavour before (nor was it specified in the hiring docs), so I'd like to avoid doing the same to others.

Pikamander24• 2 years ago

I wrote some entry-level PHP interview questions years ago and the number of people who couldn't spot simple syntax errors or identify the security hazard of echo $_GET['var'] was staggering.

AsthmaBoy• 2 years ago

I like this approach. We did something similar, but for a position as support engineer, where coding ability was one of the requirements, though not the only one.

They were given a piece of code on a toy, easy to read, english-like pseudo-language, and were asked to examine it and explain what the output to a specific input would be.

They were told that we would answer any question, except what the answer was or what the code was doing, and encouraged them to explain their reasoning as they went ahead.

We wanted to asses the candidates ability to problem solve, communicate, how would they react under preassure, and how they approached the issue.

We were not necessarily looking for perfect answers, we rather rated the candidates willingness to ask for help when stuck, how well they communicated while doing the task, whether they tried different approaches, their ability to grasp what an unknown piece of code was doing and so on... all important properties for a role supporting mission critical solutions with near to zero down-time requirements.

Our reasoning was that technical knowledge is easy to acquire over time, but problem solving skills, how candidates tackle difficult and unknown challanges were more important for the role.

In my current role I try to design interview questions like that, looking both for the candidates current skills as well as their future potential.

Not easy, but IMHO more rewarding for us and them in the long run.

RomanPushkin2• 2 years ago

The only downside I see is that I need to share my screen with a person I don't know. Don't get me wrong, but I normally have access to some crypto on my laptop, banking notifications turned on for my 2FAs, private messages I'm getting from my spouse, maybe some borderline NSFW chatgpt dialogs, screenshots of my ideas, emails, private notes, personal projects, whole bunch of tabs I am not willing to close or share, etc.

I don't have issues to show the screen to a friend of mine. Or showing the screen of a work computer to a colleague. However, demoing the whole screen is violation of privacy. Please don't do that, unless you grant VNC access to a machine with a set of popular tools, code editors, etc.

How about reverse bug squash? Interviewer shares the screen with all his/her private info, notes, tabs, development environment settings, shell command history (with maybe autosuggestions turned on), and the interviewee needs to guide the interviewer towards finding the bug?

yonrg2• 2 years ago

True, this would discomfort me, too. Also in webconferences, I never share the full screen, only one window. This should be enough for bug squash as well.

tdeck3• 2 years ago

This is common in many interviews, not just "bug squash" interviews. I recommend having a plan for it if you're interviewing. Perhaps dedicate a virtual desktop to interviews if your system supports it.

RomanPushkin2• 2 years ago

Thanks for recommendation. I just finished my rounds of interviews, gotten a decent offer (SF company), being 20 years in industry. I have my own rules, and luckily they align very well with industry standards. So I never had any issues not following the scenario when I need to share something to land a job. I also don't do any take-home assessments, and moreover, I only use one programming language while interviewing. Never had any issues with that.

I think I don't need a plan or virtual desktop. I just say "no" if it doesn't work for me. Unless I am really desperate, I do not share.

aaronbrethorst2• 2 years ago

This is essentially what I do with candidates. I ask them to pair with me on adding features to a codebase, and also to offer a code review to a PR. 100% success rate on candidates thus far.

gecko6• 2 years ago

I have an interview question:

step 1: the candidate is shown the specification for a method and the results of running the test suite on an obfuscated version of the method. All tests pass. The test suite is minimal, and test coverage is abysmal.

step 2: the candidate is asked to come up with more test cases, based on the specification. The code is run against the updated test suite - most new tests will fail because the method's implementation has several known bugs.

step 3: The un-obfuscated source is provided and the candidate is asked to correct any bugs they discover.

step 4: the changed source is run against a full test suite.

I like this because the candidate's ability to think of test cases, debug, and fix existing code are all tested for.

pastage• 2 years ago

This has failed me because code get pretty gnarly fast, many things I thought was obvious was missed by people smarter than me. I think as long as it is a tool for discussions rather than grades it is good though.

saagarjha7• 2 years ago

Curious if any interviewee has tried to unobfuscate the code.

eru2• 2 years ago

Do you allow property based testing?

ReleaseCandidat• 2 years ago

It’s fun because fixing self-contained, reproducible bugs like this is what so many of us enjoy the most about software engineering in the first place.

Do really "many of us" enjoy that? In the "day-to-day business", not interviews.

jb1991• 2 years ago

I am quite skeptical of item 6 in this list, but otherwise it looks pretty good:

Cheating effectively is indistinguishable from debugging skill.

If you know the code or problem ahead of time and how to fix it, you can certainly be convincing in your walk-through of how to do it.

pyromaker• 2 years ago

Would love for others to share non-technical questions that can filter bad candidates!

globular-toast• 2 years ago

I like this idea but I'm curious how others would implement it. Does the developer have to write the failing test themselves? Are they instructed to do it first, or is that behaviour worthy of bonus points? (Most write a passing test afterwards, which is worse).

I’ve seen candidates wield their text editor like it was an extension of their fingertips.

So am I allowed to install my own text editor and other tools (Emacs with my own config that requires some build time)? Or is it on my own laptop (I don't have one)? It seems unfair if some candidates get to use their favourite tools and others don't.

eru2• 2 years ago

Compare and contrast https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

steventhedev• 2 years ago

Having done nearly 100 technical interviews (with multiple questions each), the bug squash question gave us the biggest signal on candidates.

Our question was far simpler: it was a simple class (java + python variants, no fancy syntax) and ask them to describe what it does, then find the bug, and finally ask them what they would change.

It reflects a true test of what the day to day is, and whether or not the candidate would succeed in the role.

Pikamander24• 2 years ago

I've written some interview questions before and can confirm that having people find and fix simple issues in code is a surprisingly great way to weed out people who have no clue what they're doing.

Cheating effectively is indistinguishable from debugging skill. Even with knowledge of the exact bug ahead of time, if you just open the file with the bug, barf out the code to fix it, and run the tests, you’re going to fail the interview.

Did you mean "distinguishable" here, by chance? The first sentence seems to contradict the second.

sethammons2• 2 years ago

"Work Sample Test"

Our best received interview question was in this style. Pick something your team fixed or did, distilled down do a 15min thing a teammate could do. Give the candidate 3x the time.

For us, it was a db value not being set as expected during a cron. The candidate got our forged bug reports, cloned a repo, ran the script, verified the unexpected db state, and off to the races

ChrisMarshallNY• 2 years ago

I agree. Great question. Academic LeetCode exercises are really not what I consider useful in evaluating candidates.

However, I'm biased. I'm really, really good at finding and fixing bugs, and pretty much stink at LeetCode, so take my support with a grain of salt.

One problem is that, if the exercise gets known, expect an underground economy of solution cheats. Same with LeetCode, but that's sort of expected. Bug fix solutions hit harder.

janaagaard• 2 years ago

I agree. The best interview experience that I had was to be sat in front of a small app that had lots issues, both big and small, and also a lot an not-really-issues-but-still like inconsistent code styles and names, and code comments and code that weren't aligned. This was a great starting point for both me and the interviewer. The interviewer had a list of things to ask into about the code, so that we didn't get stuck.

bluGill9• 2 years ago

There is academic research on how to interview. Most comments here give no indication the commenter is even aware it exists much less what it says.

I'm aware this exists, but I'll admit to not having read it directly. (HR gives me a list of questions I'm allowed to ask in an interview and they tell me those questions are based on research but I only have their word they are)

giantg22• 2 years ago

I've never done a bug squash interview. I have done PR review interviews that are similar - given a PR that technically runs but has tons of problems, then see how many of the problems the candidate identities. I really liked that interview.

rurp• 2 years ago

I was given a similar interview problem and thought it was one of the better interviews I've had. In my case the interviewer pulled up a web app and said this particular page is loading too slow, how would you approach the problem? We went from opening dev tools to look at the requests driving the page all the way through database optimizations and every layer in between.

This kind of interview didn't feel like a gotcha and was much much closer to real world work than the toy and/or algorithm problems that I have encountered. More companies should adopt these types of interview approaches.

aeternum• 2 years ago

Cheating is indistinguishable from debugging skill. Even with knowledge of the exact bug ahead of time, if you just open the file with the bug, barf out the code to fix it, and run the tests, you’re going to fail the interview.

Umm hopefully you don't fail for this. I've definitely known and hired devs that can do this with surprising frequency. Just because the interviewer may have taken hours to find the bug doesn't mean someone else must.

nailer3• 2 years ago

I’ve seen candidates drop into strace to debug a Ruby program

strace is great. 99% of the time, your program is looking for a missing file.

A pity it's so hard to use in modern macOS due to OS integrity protection.

mark-r• 2 years ago

I ended up doing this for an entire week, once.

I was hired and presented with a system that didn't work. I knew nothing whatsoever about their proprietary system and wasn't even given access to their codebase. I wondered why they were being so spectacularly unhelpful with onboarding tasks. At the end of the week, I found out - the whole thing had been a test to see how well I would do, and needless to say I failed miserably.

They told me I was a bad fit, and I had to agree, but probably not for the same reasons they were thinking. I really dodged a bullet with that one.

rudnevr• 2 years ago

it's kind of strange to me that ad-hoc debugging is considered such a valuable skill. I thought it's mostly a juniors' perspective. I typically set up extended loggers and logger methods, write everything to the some formatted file, and have a diffable, persistent, provable, multithread-friendly and versioned bug demonstration, which scales well to bugs of any complexity.

(I once found some 10 bugs in a pretty old and tested bond calculation engine while migrating it to the cloud, which nobody could initially believe.)

GoToRO• 2 years ago

Unrelated: why there are no stories about interview questions for managers?

darepublic2• 2 years ago

Ah the humble 2 point bug ticket

Bug squash: An underrated interview question

Related Stories