I'm a developer not a compiler

https://news.radio-t.com/post/i-m-a-developer-not-a-compiler

by redbell • 2 years ago

73 109 2 years ago

Terr_• 2 years ago

As I've worked with more different languages over my career, I've become less and less able to answer those syntax / standard-library questions, simply because there are so many half conflicting memories of other ways to do it.

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

evanmoran• 2 years ago

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.

indulona• 2 years ago

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.

UncleOxidant4• 2 years ago

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?

mdaniel• 2 years ago

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

fernandotakai7• 2 years ago

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?

BurningFrog• 2 years ago

You don't care to filter out the jerks?

rewgs• 2 years ago

Love this attitude. I’d love to chat about applying when the time comes!

abhgh• 2 years ago

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.

fernandotakai7• 2 years ago

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.

MortyWaves• 2 years ago

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.

williamdclt• 2 years ago

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

shemnon422• 2 years ago

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?

UncleOxidant4• 2 years ago

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

eyelidlessness2• 2 years ago

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

fatnoah• 2 years ago

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.

Brian_K_White2• 2 years ago

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

josephg6• 2 years ago

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.

eyelidlessness2• 2 years ago

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.

smithcoin2• 2 years ago

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.

shemnon422• 2 years ago

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

do_not_redeem3• 2 years ago

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

nkrisc• 2 years ago

I think the question would have been better with “favorite” replaced with “most memorable” because I do have a most memorable pothole I hit.

fernandotakai7• 2 years ago

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

plasticchris• 2 years ago

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.

josephg6• 2 years ago

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.

gopalv• 2 years ago

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.

1337shadow2• 2 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

ryukoposting• 2 years ago

I disagree. One of the coolest things I ever made professionally was born from the need to fix several deeply interconnected bugs.

AnimalMuppet• 2 years ago

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.

smithcoin2• 2 years ago

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.

jddj• 2 years ago

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?

fernandotakai7• 2 years ago

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.

mynameisvlad4• 2 years ago

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.

wiredfool• 2 years ago

Chickens absorb wifi.

(edit - favorite root cause of a reliability issue, not strongest held tech opinion)

the__alchemist• 2 years ago

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.

josephg6• 2 years ago

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.

Moru4• 2 years ago

Or in other words - A cultural fit.

CodeMage• 2 years ago

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

fernandotakai7• 2 years ago

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

stronglikedan• 2 years ago

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.

1337shadow2• 2 years ago

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"

teaearlgraycold• 2 years ago

I like to do as much as possible in the type system so I can avoid writing tests.

nailer3• 2 years ago

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.

UncleOxidant4• 2 years ago

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.

markild• 2 years ago

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.

nailer3• 2 years ago

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.

throwaway426682• 2 years ago

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.

alkonaut2• 2 years ago

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.

throwaway426682• 2 years ago

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.

LadyCailin• 2 years ago

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.

Brian_K_White2• 2 years ago

We can't be friends. Printf is literally the best.

bulatb2• 2 years ago

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.

kardianos4• 2 years ago

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.

bulatb2• 2 years ago

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

zeroq• 2 years ago

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.

codr7• 2 years ago

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.

xnorswap2• 2 years ago

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.

kardianos4• 2 years ago

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.

bena2• 2 years ago

The size of primitives in bytes is something that will rarely matter and when it does, you can look it up.

Abekkus• 2 years ago

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.

cess11• 2 years ago

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.

mynameisvlad4• 2 years ago

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.

y-c-o-m-b• 2 years ago

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.

ygra• 2 years ago

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.

xnorswap2• 2 years ago

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

revskill• 2 years ago

Our brain is a compiler.

mihaaly• 2 years ago

Agree

redbell• 2 years ago

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!

blueflow• 2 years ago

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?

wat100002• 2 years ago

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.

Asraelite• 2 years ago

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.

pdpi2• 2 years ago

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.

I'm a developer not a compiler

Related Stories