3 ms·
10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user. I recently tried to set expectations in a coding interview that
by bt848 7y ago
10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user.
I recently tried to set expectations in a coding interview that was scheduled for 3 hours. I told them that was enough time to read the spec, develop a simple test case, and begin or possibly complete an implementation of part of the spec. I also told them that I wasn't interested in a shop that hired people based on their ability to dash off broken, untested code in half a day. It seems to me that this kind of coding test (especially for someone with 25 years of open-source contributions) can only lead to bad things. I'd be glad to meet people like the author who have a practical view on Brooks and LOC/h.
- josephg 7y agoI've been doing tech interviews professionally for a large tech interview platform that you would have heard of. We have a timed coding challenge, but code quality is something we explicitly look for. Making slow but steady process with good testing is a great signal for us too, even if they don't get very far through our challenge within the allocated time. That said, occasionally we have people who work very quickly and somehow still have great code. Thats an even better signal.
- p1necone 7y agoI hope it's communicated that they're not expected to finish. If I was given a coding challenge with a time limit I would assume I was expected to finish inside the time limit and make any sacrifices that needed to be made to achieve that - including ignoring testing and hoping I just don't make too many mistakes.
- aidenn0 7y agoAssuming GP is talking about what I think he is, then yes they tell you ahead of time.
- stkdump 7y agoMost coding interview challenges I came along are of limited complexity. I think it is important to clarify that reading, discussing the spec, writing tests a priori is something you would do in a real world coding task, but interviewers are usually more interested in the ability to discuss different approaches to solve them with their expected pros/cons, explain why some approaches won't work, prototype one out with some clean code and explain your thinking while writing the code. An experienced developer usually won't make a lot of mistakes for simple problems that require unit tests to see. If they do, the interviewer will make them aware and play the role of the testing, just to see how the candidate would react and solve the problem.