Also reminded me of my compiler class, we had some homework to write a pascal/C transpiler and a friend of mine somehow managed to implement it via bison errors(?). The teacher was not happy but had to agree it worked and gave him full marks.
I'd like to underline this just in case the author reads the thread. He really does seem great and I wish all the best to him, but reading between the lines is a useful skill regardless of this specific situation. He says he doesn't speak English well, that might have played a role in the misunderstanding, but "I don't think that will be a good idea" is not a suggestion, it's an order.
Which gets at the real risk, maybe valid, that someone super smart who isn’t the best communicator will go and make a bunch of code that no one else in the company can reason about. Maybe you get a really nice explanation of the type system, or they are aware this is an esoteric approach but used it anyway because you said anything goes and it’s cool.
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.
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.
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.
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.
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? ;)
Obligatory: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
> 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.)
Some concrete examples:
- https://rachelbythebay.com/w/2022/03/19/time/ (it suffices to read the first two paragraphs)
- https://quuxplusone.github.io/blog/2022/01/06/memcached-inte...
I disagree. This is not a fair ask, especially for a programming position. Programming and maths in particular puts a lot of emphasis on attention to detail.
If he can write it in X, and there's no rule against it, and the job gets done well, then there is no issue. Arguing any further of it is unproductive. He's applying for software development, not for public relations.
> "I don't think that will be a good idea" is not a suggestion, it's an order.
Then it should be a rule. "Reading between the lines" sounds like an excuse to me for bullshit criteria. It should be written, it should be explicit, and it should be known. If the interviewer is uncomfortable writing it down as a rule then that tells me they KNOW that it's too silly or pedantic. This whole idea of unwritten rules is a double standard designed to weed out neurodivergent or autistic individuals who are more than capable of fulfilling job requirements and, to me, seems like a potentially illegal form of discrimination that violates disability civil rights laws.
It's not all up to the interviewee to decipher everything. Both should be trying a bit to get to the same understanding, prior to setting off to work.
Anyway, the company will be wasting money when the communication works out poorly, so it's ultimately up to them.
And the reason for the hesitance was a worry that it would have trouble with future rules, which turned out to be completely unfounded.
But after living in the UK for a bit, in the UK that is most likely an order.
I also think the interview setup and management were poor.
Or because the candidate realized that they've messed up, and by dropping the issue can at least salvage the next XY minutes of the interview by not going down the wrong rabbit hole.
"Could you tell me more about this?" and "Are you sure about this?" are invitations for providing the rationalization for your answers. "I'm not sure that's a good idea" is a very unsubtle, but polite way of hinting that the you have gone way off the map.
As an interviewer, I want my candidates to succeed. I want them to put their best foot forward. I've asked my question over a hundred times, and I've seen many ways that people have solved it, correctly or no. If I'm giving them this suggestion, it means that I know that they are going down one of the many, many wrong garden paths.
In France, professors would literally say "You are wrong." as an invitation to explain yourself better. There are only 500km between London and Paris, but the culture behind these words is the complete opposite.
That's just patently untrue. The literal translation is "ik denk niet dat dat een goed idee is" and the better translation would be "dat is niet de bedoeling".
If I got told in an interview "dat is niet de bedoeling" I'd be damn sure to rework my solution because they're clearly trying to coax me towards whatever they're looking for. And in a way it is actually a nice thing of them, because they could just say nothing and fail me out of that round of interviews.
"We'd like you to explore this path and show how you would deal with problems that occur there" is much easier to interpret than the passive aggressive tone of "I don't think .."
I would also go with my idea and see how the manager reacted: there is only so much micromanagement I'm willing to tolerate at work. Interviews go both ways.
Yep, as an interviewer I hated when I’d try to gently (then not so gently) nudge a candidate in a direction because I could see they were going down the wrong path and they insisted they knew best or refused to listen to my advice. I’m not looking for “loyal foot soldiers” who follow my every order, and I’m not looking for people to kiss my butt or blow smoke up it, but the audacity to push back on an interviewer multiple times when they’re trying to help you… (NOT what I think happened in the OPs case, I’m thinking of my own experience here).
For me it was a massive red flag. If I can’t get you to listen to my advice in a scenario where most people are trying their hardest to be “attractive” to a company then what’s going to happen when I ask you to change something in a PR? Or tell you that the approach you are taking is not going to work?
That and the person who argued with me about tabs and spaces after I made a joke about it and then proceeded to email me with more sources as to why one was better than the other. Honestly, this person was younger and I don’t think they meant to be so abrasive, but it came across very “know-it-all” and one thing I don’t like is people who come into a company and start trying to change things or do things “their way” without first getting the lay of the land and understanding _why_ things were done the way they were (aka Chesterton's Fence).
You are interviewing them too.
I would also have hired the candidate.
My reasoning is that the company advertised a position for a senior engineer with 4 years experience. Leaving aside title inflation and whether someone with 4 years experience is actually a senior engineer, and leaving aside the really dumb test, that position requires communication skills, common sense, maturity, and just generally knowing what's going on. A candidate who misreads the situation in an interview so badly that they can't take the interviewer's unsubtle hints is going to mess up other communication within the company, has likely never been on the other side of an interview before, and is at risk of allowing the kind of "clever" code that destroys companies.
Again, this is only a problem for a senior engineer. I want junior and mid-level engineers to be clever and enthusiastic. Senior engineers are meant to understand that I have five interviews this week and their attempt to channel Aphyr[0] is going to make my life harder when I want to talk about their thoughts on maintainability.
[0] https://aphyr.com/posts/342-typing-the-technical-interview
All that being said, I would not be able to take the OP's side until I heard the interviewers side of the story as well.
FizzBuzz is the mind-killer.
Instead of talking the company relies on easily misinterpreted hints that he might or might not be someone able to work in a team. People can be both self confident and able to create a cheeky solution and be sociable people with decent team skills.
If your hiring process relies on psycho analysis of the candidates, it probably will not work very well.
But you should do both things, probably in 2 different interviews.
disscussions here universially show no evidence anyone knows it exists much less what it is. I at least know it evists but I don't know how to find it
Put aside your paranoia and just talk to your candidates. Ask them thoughtful questions that invite thoughtful answers. Probe gently to get at more challenging questions. Trust your ability to discern when they're BSing you.
It gives off strong “your answer might be correct but it’s not on my answer key so I’m marking you wrong” teacher vibes. Avoid at all costs.
The problem of “What does this do?” is prevalent enough, and occurs often enough under pressure, without adding excessive niftiness into the mix.
I do still like the solution though.
"Numeric types, number literals and their associated methods and operations are forbidden".
If this is how the interview behaved, I'm pretty sure this is a company that expects developers to write code in a certain way but doesn't really know how to guide them.
Kudos to the author, but shame on the interviewer.
if someone starts careening through the task using brainfuck, they ain’t thinking like a senior dev at day job i.e. simple, clear, easy to follow and maintainable code writing.
i don’t care how clever you are. i need to know you’re not going to rewrite the frontend in your first week because of a “big brain” moment [0]. using python or something simple without being told to helps me feel like you won’t do that, and that i might be able to trust you on day 0.
expectations on seniors are higher
Also, this still properly fits the "you're interviewing the company as well" paradigm. If the author wanted a company that values cleverness or can deal with people who go unbeaten paths, they now know it wasn't the right place.
It's not good, but it's an accurate reflection of the work environment.
But if you're doing anything unique, or experimental they might be a great fit.
Most of us are doing the second.
Anyone saying "you gotta check divisibility without math" on the job would get laughed out of the room.
Of course. They can write (as in, natural language, not "just" code). In my opinion always the second most important skill for every knowledge worker, regardless of what their actual job is
If I'm interviewing someone and they give me a right answer that wasn't even in my copy of "the teacher's answer book", I realise they're good and let them ace it.
It maybe be that there was a personality clash and they simply didn't think the candidate was a good fit for the team. Been there, and understand that. Or they maybe got butt-hurt that the candidate's answer broke their test. Either way, the candidate is better off not working there.
That was forbidden, check the rules given by the interviewer.