There are multiple ways to read that suggestion. It can also be read as the interviewer saying he does not believe in the technical depth of the candidate, which can be taken as a challenge.
It would also have been better to give a choice of a few selected languages. As that means the interviewer can be much better prepared.
Actually though if they wanted to test for debugging ability, presenting some real code with defects would have worked a lot better than this.
>There are not really multiple ways to read "I don't think that's a good idea" in an interview. If your "technical depth" leads you to an inappropriate solution, it doesn't matter if it's right. Just because this solution worked for FizzBuzz and all their rules does not mean it's maintainable. It's obvious to most senior people that such a weird solution is brittle and overkill, even if they can't come up with a rule to break it. But here's a simple one: Output FizzBuzz if all the rules are passed, except if there is a database entry matching the number. Good luck solving that with some bullshit type theory, and good luck to anyone who comes behind this guy to add that rule to his Rube Goldberg code.
"What set of tools would you choose to build <normal software project>? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?". Both are infinitely more telling about the candidate.
Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
>For example, I worked with one mostly self-taught guy who wanted to rewrite everything in a niche compiled language, including things that really should be done in scripting languages like Python or shell. Thankfully nobody else let him do that. But deep down I think he didn't accept that he was wrong, and on multiple occasions he expressed that he thought the average person on the team was woefully inexperienced. In fact, it was him that was woefully inexperienced, because he didn't understand how inappropriate and even flat-out wrong his solutions were.
I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
That's absolutely not the way to approach an interview. "Let me try to do things the exact way you clearly don't want, just to see if we can." Is the candidate going to try to do their next job this way? What are you going to do when their egotistical attempts to solve problems in clever ways despite your advice and even instructions bites YOU?
>"What set of tools would you choose to build <normal software project>? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?". Both are infinitely more telling about the candidate.
I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most people. If you're talking about someone with no working experience and who claims to be self-taught, you really have to make them write code.
>Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise. He was in the mood to do an academic exercise, and that's what he did. The interviewers seriously don't know what he will do in the workplace. That's why they're trying to make him write some code in such a way. Self-taught people are more of a risk in that they often overcomplicate (or oversimplify) things.
>I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
Good for you? I'm not talking about silly problems. I'm talking about someone who wanted to rewrite our build system in a compiled language, and our Python unit test driver in a different compiled language. He wanted to use inappropriate "fun" languages at work. I'm not categorically against using interesting new languages and tools, but when there is ZERO benefit to doing so and nobody else knows said languages, it is not to be done.
>The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them. The candidate wanted to show off his knowledge of type theory despite pretty obvious hints that the interviewers didn't want that. That means he has bad social skills or else he has an ego issue. The fact he blogged about it in such a way to brag about his solution suggests he does have an ego problem. There's also a healthy chance that the whole story is fiction, just to advertise himself as a self-taught "genius" who is turned down for being "too good" lol.
