Hacker News Reader

Comment by kardianos | Hacker News Reader

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.

View on HN

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.

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.

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.

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]

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?

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.

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?

Reply on news.ycombinator.com