Hacker News Reader

Comment by CalRobert | Hacker News Reader

This is random but I was recently rejected for a role from a company I find very interesting - 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.

View on HN

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.

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.

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.

Can you explain why?

Non-python dev here.

This is terrible advice LOL.

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.

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

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.

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.

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.

Learn! You aren't hiring people to learn. They must know everything they will ever need on day 1. (Forget what it says about your company - you only do things that people at other companies have been doing for years...)

I once got rejected because my solution to an interview question didn't use recursion. I had spent the previous 5 years doing embedded work on hardware where stack overflow was a real possibility - we had a real aversion to recursion if we could avoid it.

Fortunately I was in a situation where I'm not too bothered about not getting the job but admittedly it would have been nice to have this chat with them.

I am _very_ familiar with the advantages and disadvantages of both approaches and would, of course, adapt to house style, but where I am now we set up a nice pipeline in Dagster with a whole lot of boxes for assets, and at the risk of being non-technical I want the box with the bug to be the one that turns red. If I use x[] I get that. If I use x.get the red box could be three modules downstream because of a NoneType Exception.

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

It is completely nit-picky, as others have said, both methods have pluses/minuses, so how does the interviewer know the internal preference of the hiring company? Unless the question was specifically "how would you do this lookup if you have Dirty data". Then maybe missing using a default value is something. But even then, maybe you hit an invalid value, you should fail, or if you are providing defaults then there should be some follow up on, what is a good default, how will defaults be reported out, etc....

That’s not nit picky. One throws a fucking exception.

Whether it's better to throw an exception or end up with None is what's unclear. Either can be better depending on the situation.

Reply on news.ycombinator.com