switch (ch) {
case '1':
case '4':
case '7':
switch(rem) {
case 0:
rem = 1;
break;
case 1:
rem = 2;
break;
...
break;
case '2':
case '5':
...The FizzBuzz that did not get me the job
131–140 of 460 posts
Re: The FizzBuzz that did not get me the job
#132Earlier quoted context omitted.
> if an interviewer says "I don't think that will be a good idea" just take the hint that it won't be what the expect and change it. 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 t…
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…
Re: The FizzBuzz that did not get me the job
#133Re: The FizzBuzz that did not get me the job
#134What 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…
"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.
Re: The FizzBuzz that did not get me the job
#135I get that smaller companies can't afford to mis-hire, but they are also not a FAANG - when I read this, I doubt I would have passed.
Re: The FizzBuzz that did not get me the job
#136I 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…
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.
Re: The FizzBuzz that did not get me the job
#137Interestingly, unlike many in this thread I would've avoided hiring this person based only on the code example. This code is almost unreadable to me, certainly to most on my team. I would request changes it if it was a PR going into production (ignoring that the problem itself is made up). The code I would've liked to see would be easy to read, easy to follow, and would make me understand the underlying rules that ma…
If the requirements of the exercise had been "write FizzBuzz" then I would agree: doing weird tricks like this rather than writing straightforward code is a red flag. But the requirements were "write FizzBuzz in ANY language. Then change it so it doesn't use use numbers (!!!). Stick to strict and unreasonable code length constraints." The only POSSIBLE interpretation is that the interviewers don't WANT straightforwar…
Re: The FizzBuzz that did not get me the job
#138I loved the article and would probably have hired this person. But as a suggestion to them: if an interviewer says "I don't think that will be a good idea" just take the hint that it won't be what the expect and change it. 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 ha…
> if an interviewer says "I don't think that will be a good idea" just take the hint that it won't be what the expect and change it. 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 t…
Re: The FizzBuzz that did not get me the job
#139Interestingly, unlike many in this thread I would've avoided hiring this person based only on the code example. This code is almost unreadable to me, certainly to most on my team. I would request changes it if it was a PR going into production (ignoring that the problem itself is made up). The code I would've liked to see would be easy to read, easy to follow, and would make me understand the underlying rules that ma…
If the requirements of the exercise had been "write FizzBuzz" then I would agree: doing weird tricks like this rather than writing straightforward code is a red flag. But the requirements were "write FizzBuzz in ANY language. Then change it so it doesn't use use numbers (!!!). Stick to strict and unreasonable code length constraints." The only POSSIBLE interpretation is that the interviewers don't WANT straightforwar…
This person aced some ridiculous requirements. The odds are good they're capable of writing simple, clear, non-clever code when asked to.
If the job requires simple, clear, non-clever code don't ask for FizzBuzz that can't use numerics.
Re: The FizzBuzz that did not get me the job
#140Earlier 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.
The author’s answer was clever, but also unconventional. The company was probably looking for someone that would write code in a shared codebase that other developers will need to contribute to and maintain. Thinking outside the box and not following suggestions might have raised a red flag that this person might be a loose cannon. In a small company, hiring someone smart but unwilling to follow directions can be det…
"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.