4 ms·
I'm doing a lot of interviewing at a big five company, but speaking personally and unofficially - when it comes to code, I'm looking for fluency more than anyth
by Shish2k 8y ago
I'm doing a lot of interviewing at a big five company, but speaking personally and unofficially - when it comes to code, I'm looking for fluency more than anything else. At the phone screen level (which I assume is where you're at), the questions I ask are in the same complexity ballpark as fizzbuzz (ie the task will be fully specified in 5 sentences and assumes no prior knowledge), and I expect a candidate to be able to implement that without having to google for "how do I access an array element in <language that the candidate has freely chosen and claims to have mastered>?". The bar for on-site interviews is somewhat higher, but for the first round of interviews, just "do they struggle with basic syntax" is enough to filter out a remarkably large number of people...
Also (again personal opinion) - python is the most practical language for doing interview questions, because interviews are heavily time-constrained and python allows the developer to go from idea to implementation in the shortest amount of time. I'm not going to penalize anyone for their language choice, but somebody who completes the task in 5 minutes and then spends 25 minutes getting bonus points for things like "what if the input data is larger than RAM?" is going to come across stronger than someone who spends 30 minutes on parsing the input and runs out of time before they get to the algorithm.
- shoo 8y ago> python is the most practical language for doing interview questions, because interviews are heavily time-constrained and python allows the developer to go from idea to implementation in the shortest amount of time. i'm not sure if python is the best, but it's a very strong choice. python also has a lot of built in data structures that are relatively non-broken and highly useful for the archetypical algorithm-prototyping interview questions e.g. if you are using a language that only lets you use strings or ints as keys for dicts/hashmaps - instead of say letting you use immutable compound values as keys, or a language that doesnt give you set data-structures which support basic set operations (contains, equal, subset, superset, intersect, union, etc), or a language that requires you to write a paragraph of OOP-boilerplate to encode e.g. a list of pairs of values, you're making life harder for yourself than necessary. also, i claim without evidence that prolonged and continuous exposure to working with languages that dont offer sensible data structures, or only offer broken data structures, may over time hamper your ability to think and problem solve clearly.