Good leadership starts with clearly communicating expectations. If your boss can not say "I want you to use this tool" or "use whatever you seem fit", but instead hints to you as to some possible drawbacks of certain tools he is bad at his job.
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.
Yeah as an interviewer if the type-heavy solution wasn’t what I wanted to look at I would’ve asked the candidate to pretend like they don’t understand the type system and adjust the solution accordingly.
Actually though if they wanted to test for debugging ability, presenting some real code with defects would have worked a lot better than this.
That last part is key. Way better than FizzBuzz from scratch, best interview results I've seen come from giving a candidate a pre-made solution or architecture document that technically works but with glaring issues and just talking about their opinion on it, coding or pseudocoding optional for presenting solutions.
>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.
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.
It is not uncommon for self-taught people to develop weird fixations on particular niche tech. Even if their understanding is thorough, they don't have the experience to know when their tool is appropriate. 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. He wrote a fair amount of seemingly sophisticated code and sounded smart until you really got down to details and realized how nonsensical it all was. The worst part is if such a person becomes a manager and YOU have to be the one to fight for the right solution with them. I think that guy talked his way into management after I left the company, and I pity anyone who has to work under him.
The way you figure these things out is talking about them. Plenty of people like to solve challenges in weird ways and might even see the suggestions that it is inappropriate as a challenge.
>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.
>Plenty of people like to solve challenges in weird ways and might even see the suggestions that it is inappropriate as a challenge.
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.
>The whole point of the interview is to get hints about the candidate.
Which it didn't accomplish at all, because the interviewers refused to do the single most important thing. Actually talking with their candidate about these things. Instead they are relying on psychoanalysis to divine some secret meaning in his actions.
I am not arguing that your interview shouldn't try to figure out the personality or professional approach of a person, but that this particular interview made it near impossible to do so. Simply because they refused to talk about the things they wanted to know.
You make it sound so much more mysterious than it is. The candidate rejected polite social cues to not go down the path he did. He came up with an oddball, brittle, and undebuggable solution. They said what they wanted for this fairly simple problem. It's not a guess at some secret, it's a simple observation that the candidate is not right for the job.
I strongly disagree. I’ll take the opportunity to wildly diverge when the chance naturally presents itself. It’s how I can show the interviewer that I’m a creative person who comes up with interesting alternatives and can also be fun to work with.
For example, I was asked to do FizzBuzz once. I laughed, said we’ve both done this dozens of times, and would they like to have fun with it? We ended up building this wild thing with recursive Python generators and itertools and a state machine or something. I don’t remember the details a decade later, except that the interviewer thought it was hilarious, and I taught them some Python (“wait, that part there, does that actually work?!”, and they paused me to test it on their laptop).
I got the job.
As a candidate, you’re interviewing them, too. If the person is a martinet who can’t look deviate from the script even slightly, and you have other options, do you really want to work with them? That sounds joyless.
Sometimes going off script is OK but that is not what they wanted here, it seems. Besides I guess that if this interview ever happened, the "solution" might not be the reason that they weren't hired. But the numerous hints that the candidate got suggest that they wanted a normal solution. Asking someone to deliver a solution within some reasonable constraints is not "joyless" and disregarding these constraints on purpose over and over is not "smart."
> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.
Wrong. They put in silly rules like "Max of 30 lines" and "Mutating array operations are forbidden". These do not describe industrial-grade rules. They describe an academic, esoteric challenge. And then when he provides them with it, they punish him for his creativity by adding in bullshit rules retroactively e.g. "Hardcoding matrices is forbidden."
You just sound upset that he's able to walk the walk but you WANT him to be just a bullshitter.
> 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.
The choice is not limited to made up toy problems vs not testing coding skills at all. You can give them real problems to solve.
> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.
Hahaha, and how exactly do you write an 'industrial-grade' FizzBuzz? ;)
> 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.
Oh but it is. If I were to ask you, the expert, to draw a blue line with red ink and then attempt to draw conclusions from your behaviour based on that question, could I ever get a valid assessment of you? If a test is faulty, so are its results. Garbage in, garbage out.
Interviewing is no trivial task. It is an attempt to test how well someone will do a thing without having them actually do it. By definition, that is impossible. Still, we can try to get good enough results by minimising the number of differences between our test environment (interview) and production (the job). That will involve:
a) making the interview environment resemble the job as much as possible (no hazing, minimal pressure on the candidate, writing code in and IDE instead of a whiteboard, etc.)
b) presenting the candidates with coding tasks that match what the company does on a daily basis (take a suitable bug you had in your codebase, touch it up a bit with more issues, have them fix it; pair program with them to add a new feature to your codebase, etc.)
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.