5 ms·
Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.
by taxman22 2y ago
Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.
- necovek 2y agoI disagree: if you are demonstrating your mastery of a language (and with Python, these things are important: using appropriate syntax is the difference between dog slow code and fast code), you should use idiomatic patterns like the above. Another of Python features is a great REPL: when unsure or confused by an interviewer, I'd just fire python from shell and type in 'x' == 'x' == 'x' to confirm and demonstrate it does the right thing (or write tests). Obviously, the interviewer should be careful not to sidetrack the candidate much, and let them do the work and attempt to help only if things don't work out.
- mozman 2y agoIn the real world you iterate, profile, and optimize
- necovek 2y agoI am definitely a subscriber to not doing premature optimization, but in Python, there is a huge difference between found = searched_key in list(large_dict) vs found = searched_key in large_dict But also compare: searched_key in large_dict.keys() # O(1) and searched_value in large_dict.values() # O(n)
- carlmr 2y agoSo much this. Write code that you can reasonably expect to not be slow af, while not sacrificing readability. Then profile and optimize if necessary.
- nerdponx 2y agoIn this case the candidate evidently didn't understand it either, but was repeating a pattern they had seen before, which IMO is a form of anti-mastery: don't do things that you don't understand, especially when you're supposed to be demonstrating your skill and understanding.
- necovek 2y agoHaving a candidate understand all of the edge cases of a language syntax is a very high bar to clear: there is a lot of programmer between a "master" and "anti-master". I've used Python for 20+ years, and while I'd confidently use a == b == c or 1 < a < 10, I didn't know the specifics and wouldn't use it in cases like 10 > a < 8 (or really, any other case chaining supports). I believe myself to be an expert at Python and I'll explain differences between different loop types (while/for, ranges/iterators/generators, list comprehensions, functools, external C libraries like pandas or numpy), I think I wouldn't be confused only because I am aware I don't know the details and have a quick way to prove it works.
- nerdponx 2y agoMaybe I interpreted the article differently than you did. I got the impression that the candidate was repeating the x == y == z pattern because they'd seen it in other people's code and was pretty sure it worked, not because they knew about comparison chaining. At minimum I'd expect a candidate to be able to clarify that (x == y) == z is not the same thing, not just "idk it works whenever I do it". My reaction to that was: at some point, you do need to at least be able to reason about your own code. In a more generous light, yes, I agree with everything you wrote. The precise details of comparison chaining are out of scope and I'm sure that most Python developers (myself included) don't know or remember them.
- necovek 2y agoI agree that anyone (including an obviously juniorish candidate) using it should be able to explain it to an extent, but maybe not if you confidently and wrongly claim it doesn't work as an interviewer :)
- sgarland 2y agoThis is my opinion as well, but unfortunately isn’t always held by others. I once interviewed and by dint of knowing Python’s itertools module, absolutely destroyed the interviewer’s questions that they clearly thought would take some time to do. I was told later that while I “obviously knew Python quite well, it didn’t give a good signal for my capabilities.”
- carlmr 2y ago>I once interviewed and by dint of knowing Python’s itertools module, absolutely destroyed the interviewer’s questions that they clearly thought would take some time to do. If I see such a situation I usually ask the interviewer whether they want a concise solution using libraries or they want to see how I would do this if I had to do it from scratch. Or I just offer both, I show that I can do it, but that I know it would be easier to do with x. I think this is a great opportunity to show you're a good communicator as well as a problem solver.
- sgarland 2y agoFair point.
- throwaway313373 2y agoBut it's not a "trick", it's just a normal Python code. I don't think that anyone who main programs in Python would perceive it as some kind of cool/unusual trick and not just normal code.
- phrenq 2y agoI suspect the interviewer would have likely been fine if they’d been able to explain chained comparisons and how they work. I would probably consider the interviewer using them without understanding them to be a negative signal.
- recursive 2y agoIf you're used to python, you wouldn't consider it to be a trick. If you're giving interviews, and evaluating code in a language you don't know, don't be so confident it's wrong. Ask the candidate how it works.
- nerdponx 2y agoIn this case the candidate also didn't know.
- ball_of_lint 2y agoI've used python for ~2y now and I'd balk at and rewrite this statement, considering it unclear at best.
- recursive 2y agoThat's an entirely reasonable point of view. The important part here is that there are a substantial fraction of python developers that don't share your sentiment.
- Waterluvian 2y ago“Language specific tricks” are the entire value proposition of there being more than one language.
- Der_Einzige 2y agoMy usage of "yield" (alongside knowledge of "prange" from numba) in an interview instead of return has sealed the deal on a 200K offer (ML role circa 2020). "Confusing" the interviewer is a totally valid strategy! It's the only strategy when python async is involved!
- jyounker 2y agoIt's not a trick though. It's normal Python code. It's so common that you don't even think about it. It's just how equality comparisons work in the language.