I'm a developer not a compiler(news.radio-t.com)
news.radio-t.com
I'm a developer not a compiler
https://news.radio-t.com/post/i-m-a-developer-not-a-compiler
114 comments
I believe you meant `strings.Split(s1, s2)`, but I would have also accepted `s1.split(s2).collect::<Vec<&str>>();`
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.
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.
my two favorite questions for interviews:
"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.
"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.
> if they say "none" and "none", i know what to expect.
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.
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.
Those are excellent questions! I'm going to try and answer for the sake of chatting while I take a break:
- "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.
- "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.
I ask "what do you think about tests / what's your favorite test framework" and "what is your favorite os / what os do you use at home"
I like to do as much as possible in the type system so I can avoid writing tests.
I have a couple of favourite ones but one I always think of immediately is a time when I was tasked with fixing some dashboard.
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.
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.
I'd follow-up with questions on how you debugged that, how you'd do it now, what tooling you were missing, the testing strategy that led to this... I'd say it can be pretty interesting
you totally got it btw -- because questions should be conversation starters, not just "question -> answer" ad infinitum.
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.
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.
The bug is never the interesting part. The follow on questions are where the data is. How did you find it? How did you fix it? What made it memorable? Did it change the way you code?
> "what's the favorite bug you've ever fixed?"
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.
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.
It’s great phrasing, if you’re filtering for people who enjoy solving problems. Many of my favorite parts of software development are the parts I curse while they’re challenging (if they’re challenging for good reason, or even just for amusing/absurd reasons).
Maybe better phrasing would be "what's the most satisfying bug you've fixed?" or "which bug after being fixed gave you the most satisfaction?"
I definitely have a "favorite" but that's because it was my first user-facing race condition error in a picture messaging app where part of the resolution was an official letter to someone's spouse to explain that they image they received was not, in fact, the one that our user was trying to send to them.
All questions like this are really saying “tell me about yourself as an engineer. Here’s a prompt.”
“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.
“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.
"favorite bug" is perfect.
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.
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.
Yeah, “bugs are so painful that I suppress the memory” is not someone I want to hire. I want people who get excited when you bring them a weird bug, and who have a depth of experience to bring in when debugging gets hard.
The opinion question will probably tend to weed out good candidates too, however. Interviewers and interviewees being human and all, it can over-emphasize superficial disagreements, where those differences of opinion may actually be valuable to a team if they come up in a more relevant context.
The point of the question is not to superficially disagree though, the point is to see somebody speak with passion about something they should have knowledge of.
The problem is that the person asking the question is a flawed easily biased human just like everyone else on this planet. Someone with a strong opinion that they disagree with will leave a more negative opinion than someone with a strong opinion they agree with. So it's not a question on passion or tech but on reading the interviewer and then figuring out how to sell them.
A strong opinion does not have to be about what tech stack to use for best results, that depends on the goal. It could also be a few notches above the actual tech. My strongest opinion would be about the usability of what I'm creating, not just what the user wants but to figure out what they really want. Sometimes they are so blind to the actual problem that the solution they want isn't quite fixing the problem in the most efficient way. Especially if they don't know enough about the tech to know other ways of fixing the workflow to their liking.
That's almost a non-answer in the context of an interview for a technical role.
The longer I've been in tech and the more I learn, the less strong opinions I have. There are things you learn that should be done a certain way, but if the rationale behind that is strong/ubiquitous enough, it's not really an opinion any more. For example, I could say 'metrics/analytics/monitoring is super important... etc.' now the interviewer can decide to either agree with this fairly obvious/ubiquitous 'opinion', or decide this point is not interesting/controversial enough.
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.
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.
This was similar to my reaction to that question, and how I'd respond to it in the interview (with curiosity around what they're trying to get out of it). It's not that I don't have strong opinions, but they are necessarily couched in context. Strong opinions lacking in context are a sign of a lack of experience. Sometimes unit tests are a must, and in other cases they are an absolute waste of time. Sometimes microservices are the right call, and others they are an unnecessary complexity. The more experience in this field I get, the more gray and amorphous my opinions become, and "it depends" is the default, if not interesting, answer.
i agree with that. as a young person i had a number of strong opinions. i am still kicking myself for insisting that a mailinglist server written in C would be better than one in python, based on the language alone. my opinion was just blind prejudice despite not being strong in C, and always having preferred languages like pike, python or javascript.
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.
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.
> "what's the favorite bug you've ever fixed?"
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 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.
> "what's the favorite bug you've ever fixed?"
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?"
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?"
Bugs in nontrivial software aren’t potholes. They’re more like sinkholes. Seemingly small inconveniences can open up to a much more interesting world underneath.
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.
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.
I'm amazed when people can remember specific details like that from decades ago. If you asked me to describe the specific leak I was chasing when I learned to use a memory profiler, there's no way I could tell you. It's just something I know now, and I use that knowledge when I need it.
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.
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.
You don't remember "normal" bugs, you remember the hellish one..
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..
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..
There's several bugs from some 8+ years ago that I remember fairly well, because they were truly interesting.
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.
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'm amazed when people can remember specific details like that from decades ago.
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.
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.
> 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.
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.
Remembering bugs is not necessarily and indicator for passion. I know I love what I do, and have since I was really young, but I do not keep track of bugs or even feats—they just become a rolling base of knowledge (experience). At least in my case, it is just how my brain works.
You’re saying something different from what I said. While they sound similar, “a passion for your work” is not the same as “your passion is your work”. It’s similar to the difference between “I like that hobby and put effort into it” and “this hobby is the love of my life”.
It’s more of a memory test than anything. I can easily believe that some people happen to remember bugs in more detail than others, for whatever reason. I’m not sure it makes sense to draw inferences from this about their ability as engineers.
It sounds harsh to say this, but why not? All else being equal, I’d rather hire & work with engineers with a good memory for engineering.
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.
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.
You can test people's memory if you want to, but it doesn't seem like that was the original intention behind the question. I'd suggest giving people advance notice for questions like this so that they can look through their past work and pick out some interesting cases. That way you don't select for people who randomly happen to remember something interesting within 30 seconds, or (more likely) people who are good at making things up. Surely the real point of the question is to talk about something interesting that someone has worked on, not to administer an ad-hoc and unscientific test of their memory.
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.
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.
i disagree. i've been a dev for about 17 years now, and i remember a bunch of random stuff that i had to fix that were super interesting.
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?).
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?).
> That would be like asking a driver, "what's your favorite pothole you've ever driven over?"
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.
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.
I think the question would have been better with “favorite” replaced with “most memorable” because I do have a most memorable pothole I hit.
Potato potahto. The point of any interview question is to get to know the candidate. Your interviewer won’t know what the perfect framing of any given question is for you personally. They just want you to tell them about yourself - in this case the prompt is to tell a story about an experience debugging.
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.
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.
When I was still driving to/from work every day I had every bump and pot hole mappend up in my brain. Here I need to be more to the middle line, there I go over on the left side and directly over to the right side as far as possible. And so on. Yes, it was a horrible road :-)
My favorites were from back when I would get them from product teams that had already had a good crack at them, with fixes like painting the device black, learning a new algorithm, modifying the os core, and so on. Didn’t always succeed but it was great fun. I once found a bug in golang, memorable but less fun as it got fixed right away after I reported it.
Most bugs, once you fix them, are "oh, that was so five minutes ago".
A few bugs are really interesting. I can still describe my most interesting bug, in detail, and it was about 13 years ago.
A few bugs are really interesting. I can still describe my most interesting bug, in detail, and it was about 13 years ago.
I remember when we were using an experimental SDN router, it was 0'ing the MAC address field in the packets, pretty fun to debug
Oooooh that reminds me of when Realtek printed a bunch of NICs with identical MACs.
I disagree. One of the coolest things I ever made professionally was born from the need to fix several deeply interconnected bugs.
I love these questions. I usually ask some variation of them. The other question I always ask is “What was your first job?” - the way they describe that experience can tell you a lot about a person.
How quickly do people typically respond?
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?
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?
> Does that say anything about me, according to your filters?
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.
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.
the first one: depends on experience! i had a guy answer with a kernel nevel bug that honestly, i didn't understand the fix.
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.
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.
> there's something i always tell every single candidate i've ever interviewed: there are no wrong answers
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.
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.
i disagree with you 100%.
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.
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.
> 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.
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.
on the spectrum of “right <————> wrong” answers…
… 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.
… 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.
Chickens absorb wifi.
(edit - favorite root cause of a reliability issue, not strongest held tech opinion)
(edit - favorite root cause of a reliability issue, not strongest held tech opinion)
I think these questions are both more of a filter for good storytellers than anything technical.
Edit: Also, for people with good memories/fast recall.
Edit: Also, for people with good memories/fast recall.
I agree - but it’s nice to have good communication skills on your team. I’ve performed over 400 technical interviews, and one of my big takeaways is that you want lots of different kinds of challenges for candidates. Programming. Knowledge tests. Debugging. Whiteboard problems. Story telling. And so on.
I think this question is great, but a great interview should never lean too heavily on just one modality of assessment.
I think this question is great, but a great interview should never lean too heavily on just one modality of assessment.
Or in other words - A cultural fit.
> "what's the favorite bug you've ever fixed?"
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.
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 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 :)
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 :)
if the interviewer doesn't hold that against them
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.
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.
[deleted]
I had an interview last year that left such a bad impression on me it still puts me off interviewing.
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.
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.
Interestingly enough, there are no primitive types in C#; that's a Java term. I'd probably ask for what definition they're after because I can think of a few:
• 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.
• 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.
It was 18 months ago, I may have misremembered the exact term the used. They wanted this list essentially:
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
If I was an interviewer, I would want any programmer to know these things. If you don't, then likely you know programming by pattern matching, rather knowing the spec. Leaning by pattern matching is a fine way to start, but a professional programmer, you need to understand the language. These details are a proxy for knowing the language fully. Believe it or not, knowing these things without looking them up, while not useful on your own, if you don't know these things, you don't know the language to the level at which I need you to know it. Full stop.
I've been in tech for almost 20 years now. I've worked in all sorts of industries, small companies, start-ups, big companies, you name it and I've been there. I'm currently in FAANG. I've been tech lead, in management, and even offered c-level positions in the past. There has not been a single time in my entire career where such a thing was even remotely true. Having been the interviewer before on many occasions, if I heard a candidate speak this way, I would absolutely not hire them regardless of how well they performed otherwise. This reeks of "I can't work well with others, so it's my way or the highway". It's very toxic and I question if you're trolling at this point.
I'd rather the candidate shows an acquaintance with profiling and debugging tooling. If they're good with those they'll figure out which data structures aren't a good fit once it starts to matter.
Learning some numbers and names by rote doesn't mean you actually understand the trade-offs they imply.
Learning some numbers and names by rote doesn't mean you actually understand the trade-offs they imply.
The size of primitives in bytes is something that will rarely matter and when it does, you can look it up.
Don't they also dependon the architecture you are programming? 8-16-32-64 bit computers? Or did they standardise the names since I learned C (and never used it) 30-40 years ago?
This was about C#, not C or C++. So it's a little more involved. The CLR, which C# targets, has explicitly sized types. There is no "int", there's only "Int32", which is a signed 32-bit integer.
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.
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.
It was in C#, not C.
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.
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.
I could imagine a team that needed it, but most professional programming work does not require this level of memorization, I'd have to see the job description to know which side to take in this argument.
[flagged]
[deleted]
In C# it's not called `i32`, it's called `int`.
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?
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?
This is asinine.
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.
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.
This isn't about knowledge.
If you can't compute that a 32-bit integer is 4 bytes, or have the knowledge that an int in c# is 32 bits and a long is 64-bits, then no, you don't actually know enough to be on a team. And yes, it does come up and yes, it does matter.
Can you provide some examples where this comes up?
Luckily i never had to go through these interviews to get some work.
I'll be hiring programmers next year and only two things matter to me: their code - i want to see how clean they are, how they think, how they structure the logic and flow. And how capable they are for solving a problem. That's it. Nothing else truly matters. Programming is essentially a detective work of high level problem solving. I have couple of questions where i present a problem and ask for a solution - not code, just how they would solve it. And there is no bad answer, but i am looking for a particular way of thinking/solving things, so we're more in sync and that's about it.
> Luckily i never had to go through these interviews to get some work
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?
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?
My interview at Atomwise introduced me to a fun way: pick a Stack Overflow question that includes some code, use the dev-tools to nuke any answers, and print the question (player's choice about leaving any clarifying comments intact). Then have said candidate answer the question for you. Obviously it requires some curation to find the not-facepalm-stupid questions, but I'd bet there are plenty in each language
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
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
> Agreed. What are the questions you ask to determine their detective abilities?
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?
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?
Own up to it and give a healthy severance as quickly as you can.
You don't care to filter out the jerks?
Love this attitude. I’d love to chat about applying when the time comes!
The "nano" questions are silly and tell you nothing useful about the candidate other than I guess their level of candor in being subordinate to obsequious lines of questioning.
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.
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.
Then a good nano question would be if they know what a debugger is or how they use it. Or any of those very generic questions that any half decent programmer will know, but others won’t.
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.
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.
Sure, though I'd ask more open ended questions about a problem to see where they go with it.
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.
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.
That’s the recruiter’s job, not the interviewing engineer’s. Once a candidate gets time with an engineer, the assumption should be that they are at least kind of good, and not an outright fraud. A good enough fraud might get through this, but a genuinely good engineer might not get through the nano questions.
I never had any success working with recruiters. I have only had success when doing everything from screening CV’s to the end. I think having a ”chain” with HR, Recruiters etc is an antipattern.
We can't be friends. Printf is literally the best.
> My favorite phone interview question? “What’s your favorite language?” followed by “What are it’s weaknesses?”
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.
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.
I think the point about the question is that both of those answers can be very interesting and spark conversation about your knowledge about, and approach to, computer programming as problem solving.
Yep. 20 years ago it would show that the OP is at a stage where they love what Ruby is doing with code readability and cool ActiveSupport mixins etc. but maybe hasn't considered there are some performance limitations that hit a lot of the early Ruby success stories, now it would show a more experienced engineer that is aware of those nuances.
I think some of this is true for ML interviews as well, e.g., interviewers asking for specific library incantations and the precise mathematical expressions. Most good ML people I know think in terms of the assumptions an algorithm makes, known results that might apply (and therefore inform the practicality of a current approach), latency, time to train, the human workflow impacted, etc. When it comes to discussing the math., they tend to think in terms of proportionalities, e.g., "if I increase k, I would expect recall to increase..." and intended outcomes, e.g., "this step smoothes the loss landscape". If you have a broad knowledge of an area, its is impossible to remember details.
These companies are following the universally efficient strategy for life, to be as bad at everything as you can get away with. Interviews like this aren't good at anything they're meant for, but the companies that use them keep succeeding, so why would they stop?
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.
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.
Yes. On principle, survival in many ways is "right".
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.
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've been the guy who nailed it, and I've also been the guy who proves that frauds are everywhere and resumes are meaningless because he can't do FizzBuzz.[0]
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?
[0] https://news.ycombinator.com/item?id=16915511
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?
[0] https://news.ycombinator.com/item?id=16915511
OP here (not author).
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!
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!
2003-2009 it was quite common to be asked questions like: method foo of class bar takes three parameters, name them, tell their types and what does the method returns.
baz, qux and fyo?
Thinking about it, asking a candidate to refactor a piece of code wouldn't be a terrible idea if executed correctly.
Thinking about it, asking a candidate to refactor a piece of code wouldn't be a terrible idea if executed correctly.
[deleted]
> I dislike the polymorphism one, simply because it is so closely tied to most OO languages and inheritance that most people–when overriding or overloading a method, for instance–use it without ever thinking “oh! this is polymorphism in action!”
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.
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.
I saw the question about weak and strong typing and then realized that i wouldn't know the answer, either. So i looked it up on wikipedia, second sentence there:
> 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?
> 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 good interviewer, the right answer is anything that indicates you understand the underlying ideas of types and how they work. If someone says “I thought strong typing was when you use it for weightlifting” but they can still describe types being known at compile time versus runtime, type punning, checked versus unchecked conversions, etc., that’s still great.
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.
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.
There's so many other things that are like this too where there is no precise universal definition of the difference but many people think their own personal definition is the correct one:
high-level vs. low-level language, functional vs. imperative programming, unit vs. integration test, list vs. array etc.
high-level vs. low-level language, functional vs. imperative programming, unit vs. integration test, list vs. array etc.
Agree
[deleted]
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) ...