Live data from Hacker News

The FizzBuzz that did not get me the job

kranga.notion.site

451–460 of 460 posts

Re: The FizzBuzz that did not get me the job

#451
post #387

Earlier quoted context omitted.

> but writes incredibly well! The post actually has a lot of small grammatical errors typical of someone not so fluent in English: >> My reasoning went as follow: // My reasoning went as follows . >> Is there any other numbers where this happens? // Are there any other numbers >> I didn’t had paper at hand // I didn't have (any) paper on hand. I'm not here to proofread a fun blog post but it's far from incredibly wel…

I didn’t even notice the typos when reading it... I did notice how well the text flows, how easy it is to read. I (not a native speaker either) probably don’t make that many grammatical errors, but I envy their ability to just write . I can’t do that, I struggle with every word in long form writing. These small errors are easily addressed with a final pass in e.g. DeepL Writer.

> I struggle with every word in long form writing.

So does every good writer. A full workload for a fast fiction writer is ~1000 words a day. That's, like, an aspiration for most full-time professional novelists.

There's a (probably legendary) story about Oscar Wilde telling someone who asked what he'd done that day, "I spent this morning putting a comma in, and this afternoon taking it out again."

Good writing is hard. LLMs may someday be able to write well, but they're nowhere near it yet. (They can write mediocre prose, which is considerably better than the median human, but I expect something like the 80-20 rule will come into play long before they're truly good.)

Anyway, I'm trying to tell you that you write well, and that you shouldn't feel bad (quite the contrary!) that you have to work at it.

(This comment took me eight minutes to write.)

Re: The FizzBuzz that did not get me the job

#452

Earlier quoted context omitted.

Since I read the constraint to allow for single digit numeric values*, I guess they are looking for a solution similar to: function isDivisibleByThree(num: string): boolean { let mod3 = "012012012012"; let modulo = "0"; for (const digit of num) { modulo = mod3[Number(digit) + Number(modulo)]; } return modulo === "0"; } If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep…

> If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep everything in string representation. Yeah uh I guess you missed the SUM_TABLE part of the article? That's what they're doing. And that's why the rule against matrices was added. That version of the code is 80% checking if "the sum of the individual digits is divisible by 3", 20% the rest of the fizzbuzz.

The constraint only states not to use hard coded matrices as I read it. Here is a version with number addition removed, this works fully on strings.

  function isDivisibleByThree(num) {
    let modulo, mod3 = "012012012012";
    for (const digit of num) {
        [modulo] = mod3.slice(modulo).slice(digit);
    }
    return modulo === "0";
  }

Re: The FizzBuzz that did not get me the job

#453

Earlier quoted context omitted.

> If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep everything in string representation. Yeah uh I guess you missed the SUM_TABLE part of the article? That's what they're doing. And that's why the rule against matrices was added. That version of the code is 80% checking if "the sum of the individual digits is divisible by 3", 20% the rest of the fizzbuzz.

The constraint only states not to use hard coded matrices as I read it. Here is a version with number addition removed, this works fully on strings. function isDivisibleByThree(num) { let modulo, mod3 = "012012012012"; for (const digit of num) { [modulo] = mod3.slice(modulo).slice(digit); } return modulo === "0"; }

Using slice twice is pretty clever. That might work.

But my real point is they did have the digit sum insight. Their code was already doing your previous suggestion, and if there's a compact way to slice in typescript types it could be adapted to this new method by replacing SUM_TABLE and changing one other line.

The only difference is that they're doing a sum modulo 9 instead of modulo 3, but both of those work fine.

Re: The FizzBuzz that did not get me the job

#454
post #393

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…

Agree. While the solution is impressive, the choice of using the type system severely hampers the ways the code can be deployed. Instead of taking dynamic input, the DATA array must now be encoded up-front in an unexpected number-base and run within the tsc compiler. It limits the number of members in the team that can maintain it. Finally, he was lucky there were no further silly requirements like send a PDF report…

There are two things that make it hard to maintain.

One is choice of language, which is supposed to not matter because it's just an interview exercise where you can pick any language.

The other is the contortions around not using numbers.

Anything stemming from those two factors should not be held against the candidate. It definitely shouldn't be labeled as "scratching your own itch".

Re: The FizzBuzz that did not get me the job

#455

Earlier quoted context omitted.

The constraint only states not to use hard coded matrices as I read it. Here is a version with number addition removed, this works fully on strings. function isDivisibleByThree(num) { let modulo, mod3 = "012012012012"; for (const digit of num) { [modulo] = mod3.slice(modulo).slice(digit); } return modulo === "0"; }

Using slice twice is pretty clever. That might work. But my real point is they did have the digit sum insight . Their code was already doing your previous suggestion, and if there's a compact way to slice in typescript types it could be adapted to this new method by replacing SUM_TABLE and changing one other line. The only difference is that they're doing a sum modulo 9 instead of modulo 3, but both of those work fin…

I see what you mean now, you are right. My only intention was to demonstrate that a TS solution is possible - one that does not rely on the type system but one that still observes all the constraints listed. I think this was questioned by some in the thread (but not you).

Re: The FizzBuzz that did not get me the job

#456
post #341

Earlier quoted context omitted.

> I was never asked to write a fizzbuzz until last week. > A month has passed and I got no response, no feedback, nothing… It reads like fiction because it is.

A more generous interpretation is that they started writing this a week after the event, while it was still fresh, but didn't finish it until a month had passed. Or perhaps it was a week ago when they realized they had been ghosted. Timelines needn't be linear.

I think my interpretation was more generous, despite the time incoherence I deem it a good piece of fiction.

Re: The FizzBuzz that did not get me the job

#458
post #216

Earlier quoted context omitted.

The only thing I can think of is they were fielding for them to say "that's not possible" and push back, potentially as a way to gauge if they would reject unreasonable client expectations or something.

Then it's a stupid way to check for it, because it was possible and trivial enough to implement in a short time frame with a "rewrite" in the middle and no attempt to meassure pushing back in other ways when the first one failed

Yea still absolutely unreasonable, but it's the only way it even makes sense for me

Re: The FizzBuzz that did not get me the job

#460
post #151
post #133

Earlier quoted context omitted.

I assume you haven't looked at Switzerland?

As someone that lived two years in Switzerland and still goes there regularly, don't forget how much things actually cost, the high value is artificial given how much even basic supermarkt good cost.

> the high value is artificial given how much even basic supermarkt good cost

Compared with which location?

My experience is that you're way better off in Zurich than, say, London where you'll end up having similar costs. https://livingcost.org/cost/london/zurich illustrates that. Zurich seems similar to San Jose: https://livingcost.org/cost/san-jose-us/zurich.

Prices in most supermarkets are high, but I've come to understand this as most consumers being price-indifferent for groceries, at least in Zurich, because it represents little of their overall costs anyway. If you want to save on groceries, Lidl is way cheaper than Coop/Migros, but many consumers prefer convenience. That's not even including the case of people living in Basel / Geneva who buy groceries in Germany / France such that Swiss prices don't matter to them.

Post reply on HN