4 ms·
1) We will also need to hire a 'pretentious <-> English' translator just to communicate with this guy. He's probably also very opinionated and difficult to get
by Falkon1313 12y ago
1) We will also need to hire a 'pretentious <-> English' translator just to communicate with this guy. He's probably also very opinionated and difficult to get along with.
2) His state-of-the-art code won't work on any of our deployed systems without lengthy and expensive upgrading or backporting.
3) We'll have to get all of our clients to upgrade their systems, or spend a ton of money and time adding compatibility layers.
4) None of our other developers will be able to maintain his code, and hiring someone to replace him would not be easy or cheap.
5) If we need to hire a 3rd-party agency for something, they wouldn't be able to work with him or his code either. It could cost us a fortune.
He may be brilliant, but basically, we'll have to treat everything that he does as disposable, just as we would with a clueless newb who knows nothing about programming. And we can't entrust him with anything important.
- picks_at_nits 12y agoThe story is really about what’s wrong with this process. You say the candidate should have written production code. And yet, this isn’t a production problem, it’s a made-up CS101 problem. How does it make sense to ask a CS101 question, but not accept a CS101 answer? Likewise, how does it make sense to give a CS101 answer without knowing what the interviewer is looking for in an answer? How do we know this is the code this person would write in production if we don’t give him a real-world problem to solve and ask him to solve it in a real-world way? If it’s legit to assume that this person only knows how to write theoretical code from one answer, it’s also legit to assume that the company only has theoretical problems to solve from one question. In reality, it’s insane to presume anything from one answer. If you want to know what this person writes in production, you ask about that. This is an experienced programmer being interviewed, how does it make sense to terminate the interview after asking one poorly-given question? Really, this is about a failure to communicate on both sides. For questions like this, if you don’t make it clear what you are looking for, you aren’t really testing their technical competence, you’re testing their ability to guess the answer you’re looking for. Likewise, if you aren’t given clear guidance about what kind of answer the interviewer is seeking, your responsibility is to ask for guidance, not to rush off and give the answer you think suits your agenda for showing off or for sparking the conversation you want to have. Failing either or both parties actually talking to each other, this isn’t a technical question at all.
- beaknit 12y ago"if you don’t make it clear what you are looking for, you aren’t really testing their technical competence, you’re testing their ability to guess the answer you’re looking for" ^ +1 Google stopped doing this for a reason. Give people real problems to solve, then dive deep on their answer. Unless you're interviewing for an algorist, this is a waste of everyone's time.