Live data from Hacker News

Subverting the software interview (2021)

nliu.net

21–30 of 80 posts

Re: Subverting the software interview (2021)

#21
post #2

Probably didn't pass the interview. The implementation was rather simplistic and low quality. Here's a better enterprise version: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... Though the fact that it was written some years ago might be a weakness. Some interviewers might prefere a more modern, distributed solution.

This github org needs more leetcode examples in that style

Re: Subverting the software interview (2021)

#23
post #2

Probably didn't pass the interview. The implementation was rather simplistic and low quality. Here's a better enterprise version: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... Though the fact that it was written some years ago might be a weakness. Some interviewers might prefere a more modern, distributed solution.

Or serverless

Re: Subverting the software interview (2021)

#24
post #2

Probably didn't pass the interview. The implementation was rather simplistic and low quality. Here's a better enterprise version: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... Though the fact that it was written some years ago might be a weakness. Some interviewers might prefere a more modern, distributed solution.

What about observability?

Re: Subverting the software interview (2021)

#25
post #13

Gorgeous. I'm not versed well enough in the theory to validate his code, but I know enough to see where he's going with this. As an aside, there's a lot of rightful complaining about the interview process. I've been on both sides and it sucks either way. As a hiring manager for a small company, we never had the 'process' that bigger companies have, so it was always a seat of the pants decision. Not my favourite thing…

> validate his code > by Naomi Liu

https://en.wikipedia.org/wiki/Naomi_Uemura

Re: Subverting the software interview (2021)

#26
post #19
post #13

Gorgeous. I'm not versed well enough in the theory to validate his code, but I know enough to see where he's going with this. As an aside, there's a lot of rightful complaining about the interview process. I've been on both sides and it sucks either way. As a hiring manager for a small company, we never had the 'process' that bigger companies have, so it was always a seat of the pants decision. Not my favourite thing…

You could have at least clicked on the LinkedIn link before assuming the author was a guy... https://www.linkedin.com/in/naomi-w-liu/

The name Naomi might have been a dead giveaway.

Re: Subverting the software interview (2021)

#27
> You have a tendency to overengineer things.

Overengineering is an actual problem. For a tiny example, I'll see things like:

    enum MAGIC = 67;  // explanation
    ...
    foo(MAGIC);
The use of MAGIC is the only one, and is far removed. A better solution is:

    foo(67);  // explanation
because it improves locality.

I also see things like an object fleshed out with all kinds of member functions that are never used.

Re: Subverting the software interview (2021)

#28
post #19
post #13

Gorgeous. I'm not versed well enough in the theory to validate his code, but I know enough to see where he's going with this. As an aside, there's a lot of rightful complaining about the interview process. I've been on both sides and it sucks either way. As a hiring manager for a small company, we never had the 'process' that bigger companies have, so it was always a seat of the pants decision. Not my favourite thing…

You could have at least clicked on the LinkedIn link before assuming the author was a guy... https://www.linkedin.com/in/naomi-w-liu/

My bad, should’ve used “their”.

Re: Subverting the software interview (2021)

#30
post #2

Probably didn't pass the interview. The implementation was rather simplistic and low quality. Here's a better enterprise version: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... Though the fact that it was written some years ago might be a weakness. Some interviewers might prefere a more modern, distributed solution.

A multi core one, with lockless data structures.

Better, with CRDTs.
Post reply on HN