• 0 Posts
  • 190 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle
  • Can’t speak for everywhere, but in the US, if your first questions are about salary, they’re going to be left wondering if you’re even qualified for the job and if money is all you care about. Even if it is (which is fine most of the time), that’s not really the impression you should give if your goal is to be hired.

    Asking about salary later on is usually a much better idea. You know whether you actually are interested in working there, the interviewer knows if they are interested in you, and wanting money it isn’t the first impression you give.

    As for Python - leetcode style interviews are common, but almost always worthless. The only real value the company gets from something like that is to check that you actually can write code. They’re pointless beyond that, and a company doing leetcode interviews should be a red flag.



  • No.

    Although I think it’s a symptom of a larger problem. At the very least, consider Rider (or for non-C# code, VS Code/Codium/your terminal editor of choice).

    At work, we have to use VS for C# development though, due to us having VS licenses and not Rider licenses. I guess we could use VS Code for C# dev, but I could also use Morse code to type, and neither of those sound like a good time when you take our work tooling into account.






  • Another couple missing:

    • every language uses gendered nouns/verbs/adjectives/pronouns/etc
    • no language uses gendered nouns/verbs/adjectives/pronouns/etc
    • pronouns referring to people are always gendered
    • pronouns are always singular (1) or plural (2+)

    A fun language to learn regarding these is Hawaiian, where the language uses a-class and o-class rather than masculine and feminine, and which you use is largely based on how much control you have over it.







  • Usually the serialization/deserialization code, I keep with the model. The part where a file or whatever comes in, I leave that to the caller to decide on. In other words, the model knows how to serialize and deserialize itself, but not where it’s being serialized to or deserialized from.

    Then again, in C#, it’s usually just a couple attributes on my model, and in Rust, it’s usually just a couple derives. It’s rare I actually write much, if any, serialization logic by hand.







  • I’ll be honest. I’ve written async code in Rust for years and I don’t think I’ve used select at all. I tend to drop into manually implementing Future before that point. Either way, the issues related to that macro still exist, but the author seemed to call it out and link to an article about it (which doesn’t seem disingenuous at all to me).

    As for cancellation, the fact that you can cancel tasks by default in Rust has come up far more for me than any issues with unintended cancellation (which I don’t remember ever coming up, honestly). What I find myself wanting in other languages (especially JS) is the ability to both control when the task starts executing (for initialization logic or to prepare the task and pass it somewhere before it starts executing) and when it stops executing (early termination, for example with debouncing). I don’t get that by default in other languages, or often even at all in JS (unless I pass an abort controller everywhere).