I'm a developer not a compiler
news.radio-t.com
news.radio-t.com
If the interviewer is any good--big if--they'll mainly be concerned about whether the candidate is making plausible code, regardless of whether it is String.split(s1,s2) or s1.split(s2) or StringUtil.split(s2,s1) ...
Kidding aside, I agree completely that syntax isn't the important part. For interviews I think of it more as a sign the person is "warmed" up in a language. If they code in Go or Rust all day currently, then I expect a bit more of the syntax to be known for that language, but it's more a tell on what they actually do all day then what they can do in a week or two of learning.
"what's the favorite bug you've ever fixed?"
and
"what's your strongest opinion in tech?"
why? because they are open answers and 99% of the time they bring really interesting discussions to the table, which can lead to understanding the candidate better.
also, they are good filters: if they say "none" and "none", i know what to expect.
Sometimes students scores would be appearing as zero despite their average score being not zero.
Turns out it was some very simple averaging that didn’t filter out tests with a score of zero. That zero would then basically poison the entire calculation and only produce zero.
I don’t know how interesting that one is though.
when i ask about a bug, i just want to know how you go debugging, understanding logs, dealing with other frustrated developers... you know, how you deal with things in a day-to-day basis.
favorite is kind of odd phrasing because you're cursing the bug as you're chasing it. Maybe "what's the most elusive bug you've ever fixed?" would be better? Problem is that most of those situations were painful and I've generally blocked out the details now many years later so I'm not sure I'd have a lot to say other than cuss words.
I don't know how any kind of problem solver in any field does not love it when they get really baffled and then solve it.
My problem would just be remembering any particular example.
“What’s the most elusive bug you’ve ever fixed?” is a worse question, because it tells me less about you as an engineer, and more about the specific problems you’ve worked on. It’s a worse question to get to the heart of who you are - which is the whole point.
And, because the point is to get to know the person, you have way more breadth in your answer than you think. “Well, I don’t have a favorite bug. I hate all bugs. But I do remember a bug so horrible it took down our site at least once a day for a month…”. This is a fantastic answer - since it answers the real question underneath, of who you are.
Ultimately, I think it's a terrible question - there's no 'right' answer, and you're completely at the mercy of the interviewer's subjective opinions/feelings.
If you want to hear about something the interviewee has passion/knowledge of - ask them about a project they worked on, what problems they ran into, what they learned, etc.
basically most strong opinions are based on lack of knowledge. one that i have now for example is that kubernetes is over engineered for most problems. it's based on discussions here on HN and not any actual knowledge or experience with it.
as a consequence i have learned to be very careful with strongly expressing opinions, because it can be difficult to back them up, especially when i face someone more knowledgeable in that space.
I use a variant, "What's the most memorable bug you've fixed?" - and I use it as an indicator of maturity to distinguish L3 SwE from a L5+ SwE (google levels).
First, there is the time-in-field aspect. Simply being in the field for a long time increases the amount of time you have to encounter a sleep-depriving bug.
It can show tenacity. How did they find it? What did they have to do to reproduce it? Was it in prod, test, or dev? etc.
It can show maturity. Why did it pass test? What tests were introduced to detect it? Was it a new class of bug that required new testing? Were you able to add lint rules to detect it? Did you ensure it was pushed properly to prod and do proper follow up.
It can show autonomy. Did you update the testing procedures or just post a bug and hope the QA team fixed it? Did you meet with devops and share info on how to detect and mitigate it? Did you update the playbook at least?
So many possible places to dig in to get the "hire" when the default answer is "no hire". And if you cannot find any, then that's confirmation of the default answer.
I'd be hard pressed to choose a "favorite" bug, let alone remember the details years later. I'm trying to build working software, and bugs are just obstacles on my path. I fix the bug and then move on to what I actually care about.
That would be like asking a driver, "what's your favorite pothole you've ever driven over?"
If you’re the candidate, practice reframing any question you get asked into the variant of the question that brings you the most alive. Your interviewer, and your career, will thank you.
and honestly, it's not about the specific answer: it's about creating enough conversation that you can understand the person. i usually use these two with senior+ engineers, but if i'm interviewing someone more junior, i will ask something different (like, what are you learning right now? what do you wanna understand over the next 12 months? is there anything that you currently do not like in tech?).
About 20 years ago when I was still in school I remember a bug in C++ that took me a whole week to find, where I was accidentally returning a pointer to a local variable. The embarrassing thing was that the compiler warned me about it, but I was so laser focussed on finding why my program was crashing that I decided to leave fixing the compiler warnings til later.
About 10 years ago I spent 3 months on and off trying to track down a memory leak in a nodejs server process. I can’t remember what the fix was - I’m sure it was something stupid. But along the way I learned to connect the chrome dev tools to nodejs and I figured out how to use heap snapshot diffing, and what roots are, and how V8 thinks about memory. I still use that knowledge to this day.
I could tell lots of stories like this. That time I left a debugging statement in some performance critical code and for 3 months it ran 20x slower than it should have. How a diffing function actually needed to be a 3 way diff to function correctly - else some weird corner cases would cause problems. And so on.
Do you seriously not have interesting stories? Are you just not curious when things go wrong, why they go wrong? This sounds like a great interview question to weed out people who don’t have any passion to become excellent engineers.
Your brain remembers things that you think about a lot, or that had a strong emotional experience. That’s how memory works. People who think a lot about engineering become better engineers.
As for strong emotional experiences, it seems obvious to me that people will have a wide range of different emotional reactions to their work. None of these reactions is inherently better or more correct than any other. Here I think you are falling into the common interviewer trap of judging people negatively for not being exactly like you.
It seems like some people have this sequential narrative of their experience in their head, where events are strictly ordered—but for me it's more like a pool, or an unordered set. I learn things Just In Time, they go in the pool, and eventually they fade away if no longer relevant (goodbye, VB6). That doesn't mean I don't care about the craft, it just means I'm focused on the future rather than the past.
One I didn't work on, but was the sort of stuff legends are made of. A very specific revision of Blink that was never shipped as a Chrome release but got shipped as BlackberryOS's default browser had a bug around one of the bitshift operators (can't recall which), which would give a wrong result around once in a million operations. The desktop build of that particular revision would only trigger that bug semi-reliably, but the Blackberry build would trigger it deterministically. Bitshifts are not particularly common in most JS codebases, but this was a bitcoin wallet, and bitshifts are used by the thousands as part of e.g. key derivations. "Key derivation" is exactly where this bug triggered for a user, and he lost a whole bunch of BTC to that bug. We were almost 100% sure the guy was trying to defraud us with that bug report but something made us itchy and we had somebody keep digging until we found the bug. The good news is that, because the Blackberry version was deterministic, we managed to reproduce the bug to the point of recreating the badly-generated keys and successfully recovered the guy's BTC.
One I worked on myself, diagnosing it involved attaching both IntelliJ's debugger and GDB to a running Java application, so I could set breakpoints both in Java land and in the C++/JNI component of a JDBC driver. My colleague tracked it down to an NPE at that boundary, and was stuck on how to proceed from there.
A fun one from a couple of years involved a script that ran fine on Firefox but failed on Chrome. This was around the time when fat arrow notation was introduced for JS functions. Introducing that involved changes to the parser, of course, and a vendor's minified scripts triggered a bug in the Chrome's JS parser such that it was seeing a fat arrow where there wasn't one. We solved that one by re-minifying the vendor's minified script with a different minifier that wouldn't generate the offending pattern.
I suspect this comes down to biological or neurological differences. As someone who remembers lots of trivial facts but cares not for the details of bugs, it might also just be a matter of whether your passion is your work.
Yeah I agree. But in that case, people with a passion for their work make better employees. A good interview process is actively looking to select people like that.
I'll never forget the bug where a function took by copy a mutex (instead of passing it by reference) so locking the mutex didn't work which triggered threading issues, it took me two weeks to fix it, threading issue like this are evil: debuggers are useless, logs are useless..
The bugs that matter aren't potholes, they're trails with no markers, cut by someone you don't know who has left the organization years ago.
This is more like "What was your harder part of the Rubicon trail?"
I spent 7 months debugging a single issue which happened once a billion requests across 100k web servers or so.
For those 7 months, most machines did a hard restart every 4 hours and the bug never reproduces, so I didn't even know if I fixed it until I had enough confidence to turn that restart loop off.
Finding the issue had a fork of valgrind in the middle, found a CPU errata with AMD hardware when 2 locks placed in the same cache line (but not all failing machines had that CPU version), found a "bug" in UFS FreeBSD where deleting a file + recreating it uses the same inode id (not a bug, but not how linux worked)
The fix was 2 lines.
Your answer is not the wrong answer, but the bugs that you encounter in the wild is often like a tiger hunt in a jungle, alone.
A few bugs are really interesting. I can still describe my most interesting bug, in detail, and it was about 13 years ago.
I thought about both of these just now, and granted it's the end of a long day and I've never been good at favourite questions, but it took me a good few minutes to come up with what is probably my actual answer to the first question, and a good couple of minutes to surface anything at all.
I've dealt with quite a range, too. Heisenbugs, compiler bugs on obscure c compilers, etc. But recalling them quickly is difficult. "What's your favourite problem that you've ever solved" brings things forth much more easily, but it's almost like bugs, once solved, don't get kept around in my easily accessible memory.
Does that say anything about me, according to your filters?
the second one: i think most (if not all) developers have at least one strong opinion -- even if it's just "i don't like javascript".
see, interviewing, for me, is not about right answers, it's about getting to know the person and getting to see how they approach different problems. these are just two of the things i might ask, depending on how everything is going.
>Does that say anything about me, according to your filters?
i don't know, i never saw your resume, i don't know your experience and we've never talked before. maybe it just means we have to have a 15min talk before i could ask those. and there's something i always tell every single candidate i've ever interviewed: there are no wrong answers -- if you don't know, you don't know.
That's just objectively bullshit.
If you don't know something, you probably are going to be marked down compared to a candidate that does know it.
Even in a subjective question, your answer depends entirely on your interviewer's subjectivity. One interviewer might find an answer good while another finds it lacking.
Interviews are one of few places where there are very clearly wrong answers.
maybe for the jobs you are applying this is true, but for the places i've been searching for candidates, there are only answers and those answers will tell me (and other people in the pipeline) what to think of you.
for my own process, answers are only data points and the whole point of interviewing is looking at datapoints and getting to an answer. it doesn't mean "the person that get everything right gets the job".
once, i got a person that was incredibly smart, but they where not a cultural fit. we ended up hiring someone with less experience, but that person fit perfectly within the team.
the first person answered everything perfectly, the second didn't.
I mean... They clearly didn't otherwise they would have had the job.
> once, i got a person that was incredibly smart, but they where not a cultural fit.
Do you somehow think cultural fit is not part of "the right answer"? It's just as much if not more so given how subjective interviews are... Which just goes back to my original point.
> answers are only data points and the whole point of interviewing is looking at datapoints and getting to an answer
So... Some answers are better than others. Some answers will "give" higher scores while others will have low. Some may have no good data to provide, some may even give negative score. This is, quite literally, the definition of right and wrong answers.
As a result, there are very much wrong answers. Even though you say there aren't, you yourself have clearly shown there are. If someone gives an answer you don't like, they will be scored lower than someone that gives an answer you do like.
Just because you're obfuscating it behind a vague "overall answer" doesn't mean you're not taking the answer, evaluating and judging it, and then using it to make your decision.
Put another way, if there's no wrong answers then how are you rejecting people? Everyone has correct answers to all your questions, after all.
… because it is a spectrum as it’s not binary/mathematics we’re dealing with here, it’s fuzzy human stuff…
… there is a difference between “absolutely wrong” and “not right as much as that other person we interviewed”.
there are absolute wrong answers. if you tell me in the interview that you worked for north korea’s security services im noping the fuck outta that interview.
but if you say “i hate XYZ” and our team loves XYZ, then, like, i mean, yeah, that’s not ideal. it’s not wrong. maybe we could put you on something where you don’t work with XYZ directly. but are you going to be as happy and productive as someone who actually likes XYZ? cos you’re gonna have to deal with XYZ at some point working here.
there are absolute wrongs, but, 99.99% of people don’t say things like that in interviews.
and the things you seem to be referring to in a binary manner right/wrong are, really, more about where in the SPECTRUM of right/wrong you come out in the aggregate.
that’s why we tell people in interviews that there’s no wrong answer. it’s to help calm them down, help them feel comfortable, so we can find out where they sit on the spectrum of “fitting in” without interview anxiety getting in the way and making them give stilted answers where we, as interviewers, don’t get a chance to find out who these people are.
edit: sorry i added a bunch after posting. i’m having one of those days.
Honestly, it says more about the question than anything else.
A sibling comment suggested "most memorable" which I almost immediately had a good, engaging answer for.
We don't tend to associate positive feelings (favorite) with negative things (bugs, which sure are not always negative but usually are) so it's harder for our brains to decide on something being "good enough" to meet that bar.
(edit - favorite root cause of a reliability issue, not strongest held tech opinion)
Edit: Also, for people with good memories/fast recall.
I think this question is great, but a great interview should never lean too heavily on just one modality of assessment.
Questions like this are why I'm beginning to dread the whole hiring process. It's a great question in some situations, but absolutely dreadful in others.
If you catch me with it during a two-week sprint when I worked on an interesting bug, I'll have no problem answering it and the discussion will be fun for both of us. But if you catch me at a different moment, I'll draw a blank and start feeling pressured.
Yeah, bugs can be extremely rewarding and interesting, but not everyone will find them memorable enough to be able to talk about them in the context of an interview question.
For example, if you asked me that question right now, I would be hard-pressed to answer it. Sure, I've had interesting bugs, but I've spent the last several weeks leading a greenfield project and having to deal with project management bullshit I never signed up for in the first place, and interesting bugs are not in my "mental cache".
Which brings me to my biggest gripe with this kind of question: people like to be reasonably prepared for an interview, and throwing this kind of unexpected question can make them feel bad.
That doesn't mean that no one should ever ask questions like that. If the candidate explains that they can't think of the answer at the moment and why, and if the interviewer doesn't hold that against them (as long as the explanation is valid), then it's okay.
that's totally ok for me. that's why those are only two of the questions i usually ask, not all of them. i think saying "i don't know" is just as valid as any other thing.
as i mentioned elsewhere in this thread, these questions are "conversations starters" and the good data comes from the subsequent questions.
so if you said: "i can't come up with anything" i would probably ask about the last interesting project you worked on. or what was the last programming language you tried to learn.
interviews are not only for probing for tech knowledge, they are also about getting to learn about each other :)
the problem is i don't know that, and if it isn't worded accordingly i can't know that because i am not familiar with the interviewer.
to make this question work it would have be much broader, or a list of question, so that i can choose to talk about a bug or some other challenge, problem or solution and not feel under pressure to answer that specific question.
Something tells me this is not the case. I expect that you have passed up some very good developers, but it seems like that is not what you are looking for if those are the types of questions you're asking. Most people don't have a "strongest" or "favorite" anything.
- "what's the favorite bug you've ever fixed?"
A. I've gotten really good at identifying 'heisenbugs'. Ie where something randomly fails. I make a test suite to repeat something a hundred times and find out the failure ratio (eg, 30%). I then go looking for possible race conditions in the code and re-run the test till eg 30% drops to 0%. I've used this debugging pattern everywhere from frontend to infrastructure engineering.
"what's your strongest opinion in tech?"
A. 90s-style OOP is bad, Alan Kay's original concept was closer to the FP world's 'actor' model than it was 90s style OOP, and there is no reason to glue state to functions.
The opening question was:
"List all the C# primitive types"
The next question was:
"List all their sizes in bytes".
Such a pointless waste of time. I got them all right ( as far as I remember ), but it's just trivia that if you really need to know, you are better off keeping the reference handy rather than committing it to memory.
As far as I could tell, the whole thing was just set up to demonstrate how smart the interviewers were.
It devolved when later on I was berated because I said I'd google to check whether a System Timer Tick was 10ns or 100ns, I thought it was 100ns but I'd check if I was doing something where it mattered.
The interviewer took offence to the concept of googling.
In C they are not standardized but there are requirements on relative sizes.
Since C99 we also have `int32_t` and friends that expose sizes.
C# maps keywords to certain CLR types. "int" always maps to Int32. It's a guarantee in C# and I think a requirement of all languages targeting the CLR.
Also don't forget in C#, `decimal` is a primitive type too. How many bytes does a decimal take up? If I had to look that up, would you fire me?
Learning some numbers and names by rote doesn't mean you actually understand the trade-offs they imply.
How often has the size of a primitive come up in day to day programming in say... The last month?
When has one of your developers ever had to use this information to the point where it had to be memorized?
Especially when it's literally a 1 second search away.
• Types that have a type alias (that makes them special in the language), but that would include string and object.
• Value types that have a type alias. Closer to what Java does and would include most basic numeric types. But it would exclude System.Half and System.Int128 for example.
• Value types that the runtime knows about and might treat in a special way (e.g. by also having specific IL instructions for them). That would include most basic numeric types (and enums), but probably exclude boolean, decimal and the newer ones.
• Value types in general, as they all function similarly, regardless of whether it's bool, int, ValueTuple<float, ushort> or an enum. But that list is no longer finite.
But perhaps the following discussion about types in C# and .NET was what they're after. Who knows.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Lucky you.
> Programming is essentially a detective work of high level problem solving.
Agreed. What are the questions you ask to determine their detective abilities?
It can show the ability to read code, experience with any language or framework footguns, how to work with a malspecified problem (it is S.O. after all), etc, depending on the kinds of risks the screen is trying to drive down in your specific team
in my experience, talking to a candidate across a couple of rounds and asking some generic question that can create discussions, will get some answers. sometimes, designing a system together can help a lot (as always reminding the candidate that there are no wrong answers).
at the end of the day, interviewing is a flawed process and you will get it wrong -- the question i don't see being asked is: what do you do if you get wrong?
However, the rest of the questions are just as pointless too.
As a hiring manager and product owner, the level of familiarity that an engineer has with using debugging and diagnosis tools (e.g. as simple as how to attach and effeciently use a debugger) is 100x more valuable to the predictable delivery and quality of the things they're building than Programming 101 trivia.
Writing code is quite possibly the easiest, least fraught time-sucking milestone-missing part of software development. The morass of the entire rest of the SDLC is where ambitions and dreams go to die. Version control expertise, build system esoteria, correct configuration & setup of dependencies, understanding how to test, being able to do more than printf'ing your way out of a Russian nesting doll inspired paper bag. That sort of thing.
These questions are made to filter out the pure frauds. People who claim to have 10 years experience but have none. Those who claim to have a CS degree but it’s a fake diploma, etc. They aren’t meant to tell the good developers from the bad.
As said in the article, these questions are risky because they annoy experienced developers. But it’s also a waste of time having a person who never programmed in their life go through a deep interview about api design or architecture.
Maybe they land on using something like a debugger or wireshark or strace or whatever makes sense to dig into whatever horrible voodoo is plaguing them. The important thing is that they are creative and experienced at questioning or confirming their priors and eliminating thousands of paper cuts and yak barber shops for themselves, their team, and their organization, so that collectively everyone is enabled to operate at a high-level instead of everyone constantly bushwhacking their way toward eventual failure.
20 years ago I could answer the favorite language question pretty quickly without thinking about it. Back then it was Ruby. Now? I don't really have a favorite language anymore. They're all flawed in ways and they're just tools to get the job done. Which one to reach for depends on the problem domain.
Many of us here have been complaining about all this stuff and calling out the problems for over a decade. We've been right these interviews are terrible at testing candidates, and they've been right that it completely doesn't matter.
The fact we're still complaining means these companies are right about what works for them to stay competitive and stay in business.
But also, these little things aren't useful. But having been on the other side of the table, there are too many candidates you can't do basic programming, debugging, or logical thinking. So you dial it back, where do these people fall down? Often, they fall down at elementary questions like these "nano questions" and people who can do all these, these "nano questions" always known. They are proxy questions that act with a high degree of correlation to the people who I want.
I'm not doubting there are people who apply and just aren't qualified. But if your evidence that there's a ton of fraud is coming from a fraud detector which keeps finding fraud, confirming that you need the fraud detector, and showing you how good it is at finding fraud, how would you detect if it was finding fraud that isn't there?
In an unrelated context, after three years of being part of Hacker News, I still don’t fully understand how things work behind the scenes. I was genuinely surprised to see this submission make it to the front page (currently at #7). The surprise stems from the fact that I originally posted this story about four days ago, and it barely gained any traction at the time.
What’s even more puzzling is that it’s not listed under the "second chance" pool—neither on the first page nor the second, third, or fourth!
Hacker News, you certainly have a steep learning curve!
Thinking about it, asking a candidate to refactor a piece of code wouldn't be a terrible idea if executed correctly.
This comment is a perfect representation of why "the polymorphism one"is, in fact, a good question. OP immediately (and apparently exclusively) associated polymorphism with subtype polymorphism (and inheritance in particular), while ignoring other types of polymorphism.
> However, there is no precise technical definition of what the terms mean and different authors disagree about the implied meaning of the terms and the relative rankings of the "strength" of the type systems of mainstream programming languages.
What could have been the right answer?
With a bad interviewer, the right answer is whatever specific definition they’ve decided is correct, and if you don’t already know which one that is, too bad.
high-level vs. low-level language, functional vs. imperative programming, unit vs. integration test, list vs. array etc.