6 ms·
> fucking nightmare for no reason Absolutely! To add, the amount of nit-picking that happens is staggering. I was downgraded from strong-hire to lean-hire beca
by devnull3 5y ago
> fucking nightmare for no reason
Absolutely! To add, the amount of nit-picking that happens is staggering. I was downgraded from strong-hire to lean-hire because:
1. I did not use classes in Python. That problem could easily be solved using simple functions. The feedback I got was "candidate does not know idiomatic use of modules & classes"
2. I did not use one of python's standard lib functions and instead I coded it myself (I could not remember it at that instant)
3. I could not spot a scenario in the first 5-7 min of interview. I eventually spotted it and coded it well within the time limit.
Somehow I felt that I am supposed to feel grateful for lean-hire
- wwweston 5y ago> 1. I did not use classes in Python. That problem could easily be solved using simple functions. The feedback I got was "candidate does not know idiomatic use of modules & classes" Apparently they missed this classic HN discussion: https://news.ycombinator.com/item?id=3717715 https://news.ycombinator.com/item?id=3717715
- aix1 5y agoDid you choose Python or were you asked to use Python by the interviewer?
- devnull3 5y agoI chose Python because its faster to code
- aix1 5y agoIt's quite a common pattern these days: I often see candidates who choose a language because they think it's better suited for interviews, not because they know it well (we leave the choice of programming language to the candidate). Sometimes this works well, sometimes it really backfires on them. Coding is one of key rubrics on which we assess software engineering candidates, and if the only signal I have is that they don't know know their chosen language very well, it's hard to justify scoring that rubric highly.
- TheOtherHobbes 5y agoThe root comment is saying the interviewee knows the language well enough to consider one solution better than another solution. And this was misinterpreted by the interviewer as not knowing the language. An effective interviewer would have asked "Why are you doing it this way?" instead of assuming - wrongly - it was all the candidate knew. This actually matters. Before you even get to coding skill you want people who can parse reality accurately, and not make incorrect assumptions about what's happening in front of them - either out of narcissism and arrogance, or because of poor communication skills, or because they're following a set process which is bureaucratic and inflexible and operates with a poor signal to noise ratio. (Among other possible reasons.)
- devnull3 5y agoI really well versed with Python, Golang & Rust. I will not choose Rust for interviews. For me, Python is much more productive in an interview setting. But I get what you are saying though.
- aix1 5y agoI didn't mean to imply that this applied to your case. Just a general observation (rather frustrating for someone like me, who wants candidates to do well but not that infrequently sees them being let down by their own choices).
- paganel 5y ago> The feedback I got was "candidate does not know idiomatic use of modules & classes" Many googlers probably haven't read this blog-post from some time ago [1]: "Python Is Not Java". I mentioned that at my first interview for a Python programmer job ~15 years ago, i got hired (truth be told the interview was for a small-ish startup, not for a behemoth like Google). [1] https://dirtsimple.org/2004/12/python-is-not-java.html https://dirtsimple.org/2004/12/python-is-not-java.html
- bostik 5y ago> I could not spot a scenario in the first 5-7 min of interview. This is endemic and part of a much wider malignancy in the tech interviews. Cram two medium-to-high difficulty questions in the span of 45 minutes and require the candidates to solve them both on the spot. In other words, you have at most 20 minutes to work out a complete solution to any given problem. In practice that means that you need to come up with the correct base solution in the first 2-3 minutes, because there is no time to actually work through the problem. I call these types of interviews Epiphany Lottery.
- rejectedandsad 5y agoThey’re IQ tests, it’s that simple.
- grumple 5y agoThey are memorization tests at best. At worst they test which candidates have been unemployed most recently so they can cram leetcode study.
- jasonladuke0311 5y ago> At worst they test which candidates have been unemployed most recently so they can cram leetcode study. Or which ones are young and single with no responsibilities outside of work. Which is likely a feature, not a bug.
- rejectedandsad 5y agoI mean that describes me. But if you don’t have the mental acuity and length of short term memory required to solve these problems…
- devnull3 5y ago> correct base solution in the first 2-3 minutes Not only correct solution but also generate alternatives to showcase what other things you know to get strong-hire. Example: This problem was asked in Google: https://leetcode.com/problems/cat-and-mouse/ https://leetcode.com/problems/cat-and-mouse/ It is actually based on a paper [1]. Plus it seems it is expected that one needs to know about 'alpha-beta' pruning algos for such problems. If you solve this using dfs ... its basically gtfo [1] https://www.semanticscholar.org/paper/Undirected-Cat-and-Mouse-is-P-complete-Huq/2ee617f10fa115a94ff7b59a6120ff33dd1dde87?p2df https://www.semanticscholar.org/paper/Undirected-Cat-and-Mou...