Live data from Hacker News

The FizzBuzz that did not get me the job

kranga.notion.site

271–280 of 460 posts

Re: The FizzBuzz that did not get me the job

#271

What 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…

Absolutely.

“What’s the difference between call and apply in JavaScript?”

“Ah well I can never remember which is which, but they both invoke a function with arguments but accept the arguments differently, whether an array or spread.” When you reach for it you really want to be asking if you should be using bind instead, especially because of the massive gotcha of how JavaScript does binding, but with ES6 arrow functions they’re often the best option to wrap a function call.”

“Candidate did not know the difference between call and apply”

Re: The FizzBuzz that did not get me the job

#272

Earlier 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.

Are you trying to insult me?

Re: The FizzBuzz that did not get me the job

#273

Since I'm in the process of seeking a job, I would like to share a somehow related experience in one technical interview, this time for a senior DevOps role. So, after the initial introductions and talking a bit about infra as code with Terraform, they interviewer asked a question: "What would you use if you cannot use Terraform for a project?" To which I initially answered, since it was a SENIOR position, with a war…

Maybe there's something in the air recently? Last year I had a similar experience. Senior Infrawhatever position, "take home assignment" manipulating the firewall on a standard Linux box, in the rejection mail I got negative points for having permissions checks, and my solution being too complicated for supporting both iptables and nftables, and so on.

¯\_(ツ)_/¯

Re: The FizzBuzz that did not get me the job

#274
post #226

I 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…

Honestly? It REALLY is.

This kind of typing in TS is used mostly for getting dynamically typed Javascript codebases under control.

I did this once for a state management library that was considered "impossible to add types to" by the authors themselves, and thanks to this I found several bugs in the library itself, and in our own codebase, due to subtle incorrect usage.

Just the fact that we got autocompletion across the whole app was worth the effort. Even the engineer that was against it ended up praising it.

I'm not the kind of person to say this but: maybe some things are not for everyone. Some people just have different interests and skills. Complicated things aren't less worth just because someone in the team can't understand them.

Re: The FizzBuzz that did not get me the job

#275
post #104

I know it's bad form to complain about technical issues with the site rather than engaging with its content, but I can't do the latter as I get redirected to a page telling me to activate javascript... even after activating js. Considering I expect the page itself to just be static text I'd appreciate if anyone could give a quick summary. Even the Wayback Machine can't show the page, for crying out loud.

> I get redirected to a page telling me to activate javascript...

...which is hosted on a different domain (notion.so), so if you didn't notice and temporarily allow that domain in NoScript, the actual page (hosted on kranga.notion.site) will still redirect you to the "Please Enable JavaScript" text on notion.so

Re: The FizzBuzz that did not get me the job

#277

Am I crazy or is “conversion to base 15” very much a numeric method/operation? Like sure the API itself may have string input/output, but under the hood there’s no way it’s not doing integer divisions and modulos.

From what I understand there was no change of base within the solution code. Author just used the base conversion function to prepare some test inputs.

"The input array must contain a string representations of the numbers. The programmer can use whatever representation they see fit"

Allowing arbitrary string based representation of numbers also means that whole task becomes a bit silly. Why stop at base 15, when you could use what I call the "FizzBuzz" number system. In fizzbuzz number system the divisibility by 3 and 5 is encoded in first symbols of number. Something like 1="1", 3="F", 5="B", 10="B2", 30="FB2", 1000="B200". Digits represent rest of the number you get after dividing it by 3 and 5 if possible.

Re: The FizzBuzz that did not get me the job

#278

I'm getting peeved by interviews that asks for tests (especially take home tests) The main issue that I see is that interviewers get extra picky with all the minor details and they fail candidates due to minor issues that would get solved in a code review or just with a bit more time And while fizzbuzz using strings only is cool, it seems it didn't add anything to the predictive power of the interview

> The main issue that I see is that interviewers get extra picky with all the minor details and they fail candidates due to minor issues that would get solved in a code review or just with a bit more time

You see a "minor issue that would get solved in a code review".

I see a production outage.

You cannot rely on others catching and fixing your bugs. It happens, but it's all about probabilities. You want to reduce the probability that something bad will happen. That means not just relying on more senior people to catch problems in your code, it also means relying on you to be careful.

Re: The FizzBuzz that did not get me the job

#279

What 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.…

> Be honest: if you were dealing with a monstrously complicated spec would you rather read straightforward code with comments like, "Have to special case -0 here, ugh" or see two lines that inexplicably make everything into base 15?

Unquestionably the latter. Especially if its behavior matched the spec flawlessly. Doubly so if I can demonstrably break it by modifying/removing those two lines.

I’m not totally sure why that’s controversial; of course, I understand that I might inherit this nonsense without the author around to explain themself but it sounds fun to be faced with that.

Re: The FizzBuzz that did not get me the job

#280

Earlier quoted context omitted.

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…

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.
Post reply on HN