4 ms·

For tech interviews, whether someone cares about my speed is a nagging question in my mind. I can write code that runs, but is messy, uses short variables, and

For tech interviews, whether someone cares about my speed is a nagging question in my mind. I can write code that runs, but is messy, uses short variables, and generally is one big blob and doesn’t handle expansion very well or I can spend time to consider future needs and write sensible variable names. Not sure which is correct.

tibbar 5y ago
It tends to depend on how large and/or elitist the company is and how formalized the interview process as a result. In very rigorous interviews people are, ironically, less likely to dock you for style points unless they significantly slow you down or reflect a generally poor mental model; it will be assumed that you’re using a language that you’re less familiar with. Probably many people have taken the interview so you’ll be calibrated mostly on how far you got and how much help you needed to get there. In smaller shops it’s going to be more hit and miss because you don’t know the level of the candidates you’re up against, but probably style points, comments, and good structure will be weighed more highly.
telotortium 5y ago
It depends. I think your code should be readable - try to make good variable names if it doesn't slow you down, but as long as they're not actively misleading even code with short names like "x" will be comprehensible at the program sizes written during interviews - because the interviewer will need to review your code after the interview and making it comprehensible can only benefit you. Especially if you don't get it quite right, it's much better for you if your interviewer can look at your code and see the minor bug fix needed, versus having to take your nonfunctional code as given. On the other hand, don't waste much time on "future needs", at least for hour-long interviews - YAGNI definitely applies here.

tibbar 5y ago

It tends to depend on how large and/or elitist the company is and how formalized the interview process as a result. In very rigorous interviews people are, ironically, less likely to dock you for style points unless they significantly slow you down or reflect a generally poor mental model; it will be assumed that you’re using a language that you’re less familiar with. Probably many people have taken the interview so you’ll be calibrated mostly on how far you got and how much help you needed to get there. In smaller shops it’s going to be more hit and miss because you don’t know the level of the candidates you’re up against, but probably style points, comments, and good structure will be weighed more highly.

telotortium 5y ago

It depends. I think your code should be readable - try to make good variable names if it doesn't slow you down, but as long as they're not actively misleading even code with short names like "x" will be comprehensible at the program sizes written during interviews - because the interviewer will need to review your code after the interview and making it comprehensible can only benefit you. Especially if you don't get it quite right, it's much better for you if your interviewer can look at your code and see the minor bug fix needed, versus having to take your nonfunctional code as given. On the other hand, don't waste much time on "future needs", at least for hour-long interviews - YAGNI definitely applies here.