[deleted]
The FizzBuzz that did not get me the job
291–300 of 460 posts
Re: The FizzBuzz that did not get me the job
#292Earlier quoted context omitted.
This rule alone would make me walk out: "New rules will be revealed one by one. The candidate should note them as there won’t be shown again" This feels more like a Squid Game parody than an interview. I interview people from all walks of life. I would definitely not have hired some of the best engineers I worked with if I was trying to be too clever and quirky when giving out requirements.
> if I was trying to be too clever and quirky... You buried your lede IMO. The interviewers had this cute game and when the developer didn't play by the planned rules (build up a monsterous collections of branching on top of a for loop) they were screwed. Issues: * rules revealed one by one. Spec changes and is always incomplete, but you never even hear about changing spec that your existing solution already handles.…
> artificially handicapping developers
> punishing creativity
A similar thing happened to me once in an interview. They said use any language, but were a TS shop. I went with Python, which is hardly esoteric. The interviewers were seemingly unaware of the breadth and depth of Python’s stdlib, and so I demolished their questions in short order. I don’t remember specifics, only that I used heapq for something, and itertools for something else.
The reply afterwards was along the lines of, “while you clearly have a solid grasp on Python, we didn’t get good signals from the interview.”
It’s very much worth noting that this was for an infra role, DBs specifically. The most advanced algorithm I’ve ever had (and “had” is a stretch) to use is Levenshtein.
Re: The FizzBuzz that did not get me the job
#293Earlier quoted context omitted.
At work, would you rather have a boss that makes you implement dumb ideas? Or would you prefer a boss who recognises that your idea is better, then rewards you for it? You are interviewing them too. I would also have hired the candidate.
I probably wouldn't have hired the candidate, at least for the position as stated. 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 kn…
The interesting contrast, though, is that the blog post demonstrates strong communication skills and self awareness.
Re: The FizzBuzz that did not get me the job
#294Earlier quoted context omitted.
I don't think this has much to do with intelligence. Imagine you were an interviewer, and you had two candidates. One passes the test using a well put together orthodox solution, and the other does so using an unorthodox one. Which would you hire? I think we like to imagine we would prioritise the more creative of the two, but practically you may struggle to run a business where everyone has their own ideas about how…
In my experience, everyone who has ever invoked "drones" to describe a subordinate hires the absolute worst candidates. They never get far enough in interviewing to the made up situation you are describing, they hired someone terrible long ago.
Yea, there is way too much “everyone below me in [skill | cleverness | intelligence | creativity] is a drone (or NPC)” attitude in tech. Not saying OP thinks this, but the word use is kind of icky.
Re: The FizzBuzz that did not get me the job
#295Code looks simultaneously impressive, elegant, and monstrous. Are such snippets found in TS codebases? Would like to see how it compares to a more conventional approach. Still, cool code. (Even if weren't hired.)
https://hasura.io/blog/how-typescript-template-literal-types...
Access to template literals at type-level is available since TS 4.1.
Re: The FizzBuzz that did not get me the job
#296I will go against the grain and say I do not consider OPs fizzbuzz solution to score particular well on readability or maintainability. And these were the only two stated core requirements. The solution is clever and demonstrates solid knowledge of TS. However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers…
This is also one of those things that can be quite tricky to modify down the line when you need to add a new feature or whatnot. This problem is of course very artificial and it doesn't sound like the interview was particularly well done, but I can kind of see what they were trying to do with "keep code maintainable as it evolves". And even if you are a TS-wizard with a Ph.D. in typing: is it really worth all the cog…
I thought domain modelling through types is considered standard in functional programming?
(see for example Scott Wlaschin)
Re: The FizzBuzz that did not get me the job
#297Earlier quoted context omitted.
Keep in mind that they came up with this solution after the interviewers forbid the use of numeric types and math while still keeping a limit of 30 lines. What do you expect? I found the solution impressive given the circumstances. At this point I would have thrown the towel.
I think the interviewers were looking for the key insight that a number is divisible by 3 iff the sum of the individual digits is divisible by 3. That is easy to verify, even constrained to using single digit data types. To be clear, I am not saying this was a great interview question and I agree the solution OP came up with is impressive.
> a number is divisible by 3 iff the sum of the individual digits is divisible by 3
And how do easily verify this divisibility when "Numeric types, number literals and their associated methods and operations are forbidden?"
Re: The FizzBuzz that did not get me the job
#298If the interviewers thought the hardcoded sum table was cheating, they surely should have said that demanding the inputs come in base 15 was also cheating. (I think base 15 is the best solution though. The instant I saw the rule that permitted the dev to choose the input representation, I knew this would be the way to go.)
But if the interviewers have to be persuaded that 0 is divisible by 3, I guess you can't expect too much from them. Or anything from them.
Re: The FizzBuzz that did not get me the job
#299What's the plan for the candidate choosing C when they hit rule 7 and simultaneously have to use strings but the `char` type is banned? How are they supposed to loop through the input array without an increment operation? Pointers are basically also numerical types, are those banned as well?
That's the point at which most sane people would tell the interviewer to "GTFO".
If they're hiring for some hyper unique role where they have to deal with some contrived AI in a dark room and they have to do it because someone's got a gun to their heads and they have to invent calculus to solve FizzBuzz in under 14.5 minutes otherwise the memory is corrupted and the world explodes, then sure they can ask such a contrived interview question.
Until then, this company is either crazy, bored, not looking to hire a candidate, or simply fictional and made up by the author to tell a feel-good story that makes them look like the Einstein-equivalent for programmers.
Re: The FizzBuzz that did not get me the job
#300What a genuinely terrible interview. Seems like a great way to learn absolutely nothing about the candidate. I would have walked out half way through. These types of questions are very telling of an organization which is extremely insecure in its own abilities. For anyone who is a somewhat experienced programmer it is not hard to tell if someone else knows what he is talking about. You do not need to waste 45 minutes…
> Seems like a great way to learn absolutely nothing about the candidate. They learned that as the spec became more complicated and twisted, his code got more and more clever. I guarantee that there were other candidates whose code got simplified and more commented as the spec grew. They even gave both a general hint: > An example of this was that a 50 lines solution with a line of 110 characters would be considered.…
Depends on the requirements. If they’re a complex tangle of special cases and heuristics, I want the code as imperative or low level as possible so that I can tweak the fine details with precision. If they’re clearly set rules, I want the code as declarative or high level as possible (even if it becomes a strange DSL) so that I have confidence it matches the rules,that it enforces invariants and that adding new rules won’t introduce edge cases in existing ones