4 ms·

This is random but I was recently rejected for a role from a company I find very interesting - https://www.overstory.com/ https://www.overstory.com/ - and when

This is random but I was recently rejected for a role from a company I find very interesting - https://www.overstory.com/ https://www.overstory.com/ - and when I asked, the engineering manager gave me clear, detailed feedback on why (I don't have experience with satellite imagery tools like STAC, I accessed dict members with x['a'] instead of x.get('a', {}), and I didn't go in to depth on my takehome assignment.). I really appreciate it and mention them since it's rare to get such helpful feedback. Though admittedly I think their takehome time estimate was optimistic. When I was at Auth0 we started checking the commit logs on candidate repos and it was clear that people were spending MUCH longer than we were asking on takehome exercises.

rand_r 3y ago
Depending on your perception, x.get is either error recovery (good) or a silent failure (bad). One is not necessarily better than the other; it depends on what you want. In my experience, x[] is usually the better choice because failing fast makes debugging easier. I hope no one is recommending x.get as a general practice, because that is pretty naive.
- orwin 3y ago
  You're right, but actually... If you're a very junior sw engineer reading this, who hasn't done a lot of python, use x.get(). Almost always, so for you, always. This doesn't apply if you're a scientist or mostly writing small scripts, but if you are doing SWE, always use x.get(). Once you've understood python you can use x[] in limited cases. Never in your unit or functional tests. I code using x[], but later on I replace a lot of them with getter (around my second refactoring, when I add type hints and tests) especially in library or code that'll be shared.
  - CalRobert 3y ago
    For what it's worth, I only use x.get when having a missing key is a normal and expected part of the process. If I need to be able to expect a key to be in the dict then I'll use x[] so I can get a useful exception for debugging. Though really, this should only happen with validated inputs, and as Python adopts more type hinting dealing with this should get easier over time.
  - Nimitz14 3y ago
    This is terrible advice LOL.
  - Ancalagon 3y ago
    Can you explain why? Non-python dev here.
- CalRobert 3y ago
  I've been around a while and I'm mentoring a junior dev, and one of the things that has come up is to fail as fast and as hard as possible. A silent failure is one of the worst things to have. And this is why I usually won't use .get on data that has presumably already been validated. But I was already rejected so I haven't been able to explain my logic :-). It's still nice to get their feedback, though. Funny enough, in Europe, you _should_ be able to get any written notes on you via GDPR.
FrustratedMonky 3y ago
:x['a'] instead of x.get('a', {}) This seems like splitting hairs. Sure, maybe x.get is better, but would that be a deal breaker? Know you are just giving quick example, but this just struck a cord. Are jobs really so hard to get that employers can be that nit-picky?
- CalRobert 3y ago
  If I've learned anything it's that a lot of the hiring process is extremely arbitrary. If someone asks "why do you want to work here?" and you say "money" you might get someone admiring your honesty or you might get someone who wants you to have a personal affinity for the company. And it can be hard to know which.
- kortilla 3y ago
  It’s not nit-picky because the behavior of the two is completely different when ‘a’ isn’t present. If the assignment is dealing with dirty/partial data or implementing APIs with optional fields, [] can be a complete deal breaker.
  - jameshart 3y ago
    Deal-breaker? Is there evidence that programmers who use [] simply cannot ever learn to use .get()? Once they have picked up the incorrect approach, their brains are simply broken and they can never learn that a different solution exists that is better used in certain situations? It would obviously be risky to hire someone who uses [] if that's the case. If not, though, it seems like it doesn't provide much of a clue as to the person's ability to perform in a technical role.
    - kortilla 3y ago
      > Deal-breaker? It’s a take-home test. I’m saying if the particular test called for dealing with a particular type of input and you didn’t do it, you failed. It’s that simple. If it didn’t, then it’s a pointless nitpick and shouldn’t ever be brought up as interview feedback.
    - 3y ago

rand_r 3y ago

Depending on your perception, x.get is either error recovery (good) or a silent failure (bad). One is not necessarily better than the other; it depends on what you want. In my experience, x[] is usually the better choice because failing fast makes debugging easier. I hope no one is recommending x.get as a general practice, because that is pretty naive.

orwin 3y ago
You're right, but actually... If you're a very junior sw engineer reading this, who hasn't done a lot of python, use x.get(). Almost always, so for you, always. This doesn't apply if you're a scientist or mostly writing small scripts, but if you are doing SWE, always use x.get(). Once you've understood python you can use x[] in limited cases. Never in your unit or functional tests. I code using x[], but later on I replace a lot of them with getter (around my second refactoring, when I add type hints and tests) especially in library or code that'll be shared.
- CalRobert 3y ago
  For what it's worth, I only use x.get when having a missing key is a normal and expected part of the process. If I need to be able to expect a key to be in the dict then I'll use x[] so I can get a useful exception for debugging. Though really, this should only happen with validated inputs, and as Python adopts more type hinting dealing with this should get easier over time.
- Nimitz14 3y ago
  This is terrible advice LOL.
- Ancalagon 3y ago
  Can you explain why? Non-python dev here.
CalRobert 3y ago
I've been around a while and I'm mentoring a junior dev, and one of the things that has come up is to fail as fast and as hard as possible. A silent failure is one of the worst things to have. And this is why I usually won't use .get on data that has presumably already been validated. But I was already rejected so I haven't been able to explain my logic :-). It's still nice to get their feedback, though. Funny enough, in Europe, you _should_ be able to get any written notes on you via GDPR.

FrustratedMonky 3y ago

:x['a'] instead of x.get('a', {}) This seems like splitting hairs. Sure, maybe x.get is better, but would that be a deal breaker? Know you are just giving quick example, but this just struck a cord. Are jobs really so hard to get that employers can be that nit-picky?

CalRobert 3y ago
If I've learned anything it's that a lot of the hiring process is extremely arbitrary. If someone asks "why do you want to work here?" and you say "money" you might get someone admiring your honesty or you might get someone who wants you to have a personal affinity for the company. And it can be hard to know which.
kortilla 3y ago
It’s not nit-picky because the behavior of the two is completely different when ‘a’ isn’t present. If the assignment is dealing with dirty/partial data or implementing APIs with optional fields, [] can be a complete deal breaker.
- jameshart 3y ago
  Deal-breaker? Is there evidence that programmers who use [] simply cannot ever learn to use .get()? Once they have picked up the incorrect approach, their brains are simply broken and they can never learn that a different solution exists that is better used in certain situations? It would obviously be risky to hire someone who uses [] if that's the case. If not, though, it seems like it doesn't provide much of a clue as to the person's ability to perform in a technical role.
  - kortilla 3y ago
    > Deal-breaker? It’s a take-home test. I’m saying if the particular test called for dealing with a particular type of input and you didn’t do it, you failed. It’s that simple. If it didn’t, then it’s a pointless nitpick and shouldn’t ever be brought up as interview feedback.
  - 3y ago