Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Could not agree more! This is the best way to see how they go about their work. The only problem is that this sometimes causes stress they are not used to and therefore do not show an accurate representation of their actual behavior.
fizzbuzz
And yes, what's up with that? I see that a lot recently. What happened to good 'ol foobar?
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
And yes, what's up with that? I see that a lot recently. What happened to good 'ol fooba
Fizzbuzz is a general class of coding challenges that's pretty popular because it's a) easy to understand, b) trivial to verify without even needing to run the code, and c) actually shows some basic understanding of the language in question (namely control flow and IO) while still managing to be completely useless otherwise.
The general form of the problem statement is:
Write a program that iterates over a sequence of numbers (possibly a fixed sequence, but usually taken as input) and:
If the number is a multiple of X print 'fizz'
If the number is a multiple of Y print 'buzz'
If the number is a multiple of both X and Y print 'fizzbuzz'
I actually remember when that trend started. It precipitated off an article that made the rounds on LinkedIn many years ago, about hirees who could not actually code, but could fake their way through the interview.
The author made the point that you should at minimum verify the applicant's claimed skills with something that would be trivial to write during any interview, such as a fizz-buzz.
Unfortunately, as with Ben Franklin and Daylight Savings Time, the idea was taken too literally! Hiring managers took the suggestion and ran with it, implementing literal fizz-buzz challenges in interviews, contrary to the author's actual point.
So, disaster #1: Non-coders learned how to fizz-buzz, so as to fool interviewers.
Many other hiring managers did get the point, and came up with unique, simple challenges that could fit within the interview. Unfortunately, this part of the disaster was on the would-be applicants. Modern code golfing was born, obstensibly to help programmers prep for interviews, but...
**Disaster #2: Code golfing sites inadvertently nullified the point of the coding challenges.
Unaware that their weeding technique was now pointless, companies started formalizing code golfing challenges and offloading them to the front of the process, to save time during interviews. The same sites that allowed anyone to practice these challenges saw an opportunity to cash in at the expense of companies.
Disaster #3: The process devolved from something useful to an exercise in futility that screened nothing, and ultimately helped no one (except the fakers).
The trend was now firmly established, and no one seemed to remember the original point. Fizz-buzzing and code golfing became a normal part of the fake programmer's acting repertoire.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Could not agree more! This is the best way to see how they go about their work. The only problem is that this sometimes causes stress they are not used to and therefore do not show an accurate representation of their actual behavior.
And yes, what's up with that? I see that a lot recently. What happened to good 'ol foobar?
Fizzbuzz is a general class of coding challenges that's pretty popular because it's a) easy to understand, b) trivial to verify without even needing to run the code, and c) actually shows some basic understanding of the language in question (namely control flow and IO) while still managing to be completely useless otherwise.
The general form of the problem statement is:
Write a program that iterates over a sequence of numbers (possibly a fixed sequence, but usually taken as input) and:
I actually remember when that trend started. It precipitated off an article that made the rounds on LinkedIn many years ago, about hirees who could not actually code, but could fake their way through the interview.
The author made the point that you should at minimum verify the applicant's claimed skills with something that would be trivial to write during any interview, such as a fizz-buzz.
Unfortunately, as with Ben Franklin and Daylight Savings Time, the idea was taken too literally! Hiring managers took the suggestion and ran with it, implementing literal fizz-buzz challenges in interviews, contrary to the author's actual point.
So, disaster #1: Non-coders learned how to fizz-buzz, so as to fool interviewers.
Many other hiring managers did get the point, and came up with unique, simple challenges that could fit within the interview. Unfortunately, this part of the disaster was on the would-be applicants. Modern code golfing was born, obstensibly to help programmers prep for interviews, but...
**Disaster #2: Code golfing sites inadvertently nullified the point of the coding challenges.
Unaware that their weeding technique was now pointless, companies started formalizing code golfing challenges and offloading them to the front of the process, to save time during interviews. The same sites that allowed anyone to practice these challenges saw an opportunity to cash in at the expense of companies.
Disaster #3: The process devolved from something useful to an exercise in futility that screened nothing, and ultimately helped no one (except the fakers).
The trend was now firmly established, and no one seemed to remember the original point. Fizz-buzzing and code golfing became a normal part of the fake programmer's acting repertoire.