• 0 Posts
  • 64 Comments
Joined 3 months ago
cake
Cake day: March 23rd, 2025

help-circle

  • A friend of mine was applying for a job where they required “at least 5 years knowledge with Angular version X.Y.Z” (can’t remember the exact version, but they asked for all three numbers).

    He said “I’ve got 7 years of knowledge with version X-2 to X+2”.

    The HR person was like “But you don’t have 5 years of knowledge with version X.Y.Z, so you don’t fit for the job”.

    The real fun part was that version X.Y.Z had only been out for two years at that time.







  • I once had a company give me an assignment that sounded very much like what you are describing. They said I should allocate 10h at once to implement a real-life task that they had and that their developers “already solved”.

    At that point I only wrote a handful messages with their recruiter and hadn’t even spoken to a human there. I didn’t even know anything about the team, my potential boss or the project at that time.

    I didn’t even answer back, just ghosted them. I’m not going to spend multiple hundreds of Euros of my time just for some assignent to maybe qualify for an interview.




  • You always have to balance: Do you want the user to have “some” user experience, or none at all.

    In the case of image viewers or browsers or stuff, it’s most often better to show the user something, even if it isn’t perfect, than to show nothing at all. Especially if it’s an user who can’t do anything to fix the broken thing at all.

    That said, if the user is a developer who is currently developing the solution, then the parser should be as strict as possible, because the developer can fix stuff before it goes into production.





  • Yeah, could totally be a regional difference.

    I had the same thing when negotiating for salaries too, so it wasn’t just when talking to people, but it was in a more official way as well, and I even got it in my contract like that.

    When I was working as a tutor, my contract listed my pay in hourly pay, because I worked varying hours and I was paid by the hour. On my entry-level job my contract was in monthly before-tax pay, but negotiations were with monthly after-tax pay. And my later jobs were all in yearly before-tax pay, which might also have been relevant that way because in some of these jobs I had yearly bonuses and/or part of the payment in stock I got once a year. So with these yearly figures in there, probably it just made sense make everything yearly.



  • In Europe people use annual gross salary when they earn enough too.

    Monthly after-tax is usually used by lower income people, where low short-term numbers really matter (“Can I make my rent this month?”, “Can I afford to buy/do this small thing this month?”), while annual gross salary is used by people who make a lot of money, where the day-to-day financials don’t matter, but long-term stuff does, and where you also generally have much higher tax pay backs.

    I used per-hour salary when I was in university and only worked a few hours per week. I switched to monthly after-tax when I got into an entry-level job that paid quite little, and when I got to higher-paying senior/expert level jobs, I started using yearly figures.




  • You basically defied the whole NaN thing. I may even agree that it should always throw an error instead, but… Found a good explanation by someone:

    NaN is the number which results from math operations which make no sense

    Well, technically this is the explanation, it really isn’t a good one.

    x + 1 with x not being defined also doesn’t result in a NaN but instead it throws a reference error, even though that undefined variable isn’t a number either. And x = 1;x.toUpperCase(); also doesn’t silently do anything, even though in this case it could totally return "1" by coercing x to a string first. Instead it throws a TypeError.

    It’s really only around number handling where JS gets so weird.

    Yeah but actually there can be many interpretations of what someone would mean by that. Increase the bytecode of the last symbol, or search for “1” and wipe it from string. The important thing is that it’s not obvious what a person who wrote that wants really, without additional input.

    That’s exactly the thing. It’s not obvious what the person wants and a NaN is most likely not what the person wants at either. So what’s the point in defaulting to something they certainly didn’t want instead of making it obvious that the input made no sense?

    A similarly ambiguous situation would be something like x = 2 y. For someone with a mathematical background this clearly looks like x = 2 * y with an implicit multiplication sign. But it’s not in the JS standard to interpret implicit multiplication signs. If you want multiplication, it needs to explicitly use the sign. And thus JS dutifully throws a Syntax Error instead of just guessing what the programmer maybe wanted.

    Anyway, your original suggestion was about discrepancy between + and - functionality. I only pointed out that it’s natural when dealing with various data types.

    My main point here was that if you have mathematical symbols for string operations, all of the acceptable operations using mathematical symbols need to be string operations. Like e.g. "ab" * 2 => "abab", which many languages provide. That’s consistent. I didn’t mean that all of these operators need to be implemented, but if they aren’t they should throw an error (I stated that in my original comment).

    What’s an issue here is that “1” + 1 does a string concatenation, while “1” - 1 converts to int and does a math operation. That’s inconsistent. Because even you want to use that feature, you will stumble over + not performing a math operation like -.

    So it should either be that +/- always to math operations and you have a separate operator (e.g. . or ..) for concatenation, or if you overload + with string operations, all of the operators that don’t throw an exception need to be strictly string-operations-only.