Live data from Hacker News

The FizzBuzz that did not get me the job

kranga.notion.site

301–310 of 460 posts

Re: The FizzBuzz that did not get me the job

#301
post #182

Earlier quoted context omitted.

In general, any made up problem (i.e., with no real utility) is just a puzzle and I would prefer to walk out unless I do need the/a job. What a pity when interviewers can't even think of a real world problem for an interview. Most interviewers are like that. No wonder, the industry has the candidates solve various coding problems, and once hired, all the candidates end up dealing with is company politics or other slo…

The person who invented FizzBuzz [1] did so because he was interviewing senior developers and a consistently high proportion could give really convincing explanations about their programming skills but, when it came down to it, could not program. And that doesn't just mean they were a bit rusty because they had been focusing on the big picture or managing people etc. Instead, they literally couldn't write a for loop…

I always give an option to either use some online REPL or local environment for FizzBuzz-like tests.

It's always good to see how they deal with tools.

But the number of candidates that can't run a script locally or on a website and ask if they can put inside their Rails project responding to some query is astounding. For Typescript positions I get better results.

Re: The FizzBuzz that did not get me the job

#302

Earlier quoted context omitted.

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.

Yea, there is way too much “everyone below me in [skill | cleverness | intelligence | creativity] is a drone (or NPC)” attitude in tech. Not saying OP thinks this, but the word use is kind of icky.

I use it deliberately to invoke these negative connotations. I am not commenting on the skill, creativity, or any other aspect of the drones. I think it's just a fairly basic fact that most of us are drones. We go to work, we do what we're told, we get paid. There's no shame in it. Being a drone is an honest living. It just seems that many here are in denial of that. They think that every worker is going to be a special snowflake doing their own creative little thing instead of a small cog in big machine that has to fall in line with every other part.

I think it's just out of touch with reality. If you are applying for a job, then they probably want someone who does what their told reliably and predictably, and you probably want to get paid. So you should show them that you are capable of doing what you're told reliably and predictably. You exchange your time for money and everybody benefits. It's just a waste of everybody's time if you are going to rage against this process—insist on not doing what you are told and then get angry when the result is not getting paid.

Re: The FizzBuzz that did not get me the job

#303
post #26

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

Interviewer was wrong. Interviewee learned that interviewer is happy to advance incorrect ideas and stifle innovation.

Re: The FizzBuzz that did not get me the job

#304

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

Interviewer was wrong however.

Re: The FizzBuzz that did not get me the job

#305
post #237

Did the interviewer caution about the candidate's direction because they cared about the candidate and wanted to help, or because the solution was unique, unfamiliar and made them feel uncomfortable? If you tightly script your interview, but then present it as open-ended and flexible: that's on you. My take if I was interviewing (and forced to use this approach): appreciate what a interesting interview this was, expl…

Yeah, I'm pretty sure the typescript solution was way beyond the skill level of the interviewer. Which is fine. But what's unacceptable is that a lot of people in our industry are not mature enough to admit when they don't know something, and instead just chalk it off as "unreadable" or some other adjective.

I was once interviewed by someone who is quite famous in the industry, even then, and he looked at my program for his test and said “This can’t possibly work.” And then later I got the job offer because he’d figured it out and it totally worked.

Re: The FizzBuzz that did not get me the job

#306

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…

Yes, it’s nice to get paid, but I probably wouldn’t enjoy working with people who think Ansible and Terraform are interchangeable.

Re: The FizzBuzz that did not get me the job

#307
post #224
post #134

Earlier quoted context omitted.

This rule alone would make me walk out: "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.

I think this one is pretty outrageous: > Mutating array operations are forbidden. Arrays cannot have content appended or removed after initialization. In a language like C, one could interpret this rule as making arrays containing anything other than 0 or a fixed-length list of expression be forbidden. And, in any case, who comes up with what are essentially style rules that are the same regardless of language?

Eh, this strikes me as reasonable - essentially declaring const inputs, working in a functional paradigm.

Re: The FizzBuzz that did not get me the job

#308
post #182

Earlier quoted context omitted.

In general, any made up problem (i.e., with no real utility) is just a puzzle and I would prefer to walk out unless I do need the/a job. What a pity when interviewers can't even think of a real world problem for an interview. Most interviewers are like that. No wonder, the industry has the candidates solve various coding problems, and once hired, all the candidates end up dealing with is company politics or other slo…

The person who invented FizzBuzz [1] did so because he was interviewing senior developers and a consistently high proportion could give really convincing explanations about their programming skills but, when it came down to it, could not program. And that doesn't just mean they were a bit rusty because they had been focusing on the big picture or managing people etc. Instead, they literally couldn't write a for loop…

I'm curious, when was the FizzBuzz problem invented? And how did it get publicized to the wider world?

If you can come up with a URL the Internet Archive will probably have a copy.

Re: The FizzBuzz that did not get me the job

#309

Earlier quoted context omitted.

Why? It is a simple fact that people only go to work because they get paid. You can verify this for yourself by seeing how many people continue to work for a company after it has stopped paying them.

Because it’s absurdly reductionist and in my experience suggests either a poor work ethic or a lack of empathy or both. Additionally your argument isn’t logical. An unwillingness to do something for free isn’t equivalent not wanting to do it. You’ve moved the goalposts.

Well okay, let's walk the goalposts back. Suppose there was some radical UBI scheme in place and now you get paid the same amount for working as you would for not working. There is no financial incentive to do any piece of work, but also no financial punishment for not working. Do you think most people would still go to their jobs? I think no. Most people are only motivated to work by the financial reward they get from working, not some fundamental desire to sit in an office for hours of the day.

Quite frankly, I see people with your attitude as the real bad ones to work for. Expecting people to have a work ethic beyond what you pay them for, or to pretend to be passionate about whatever you're selling, these are the real red flags you should look out for when applying to a job. Not someone expecting you to do what you're told. I am exchanging my labour for money, and I think both parties understanding that is the bedrock of good professional relationship.

Re: The FizzBuzz that did not get me the job

#310
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…

The FizzBuzz story did go down a rabbit hole, but this sort of TS type extravagance in small doses can help with maintainability. E.g., I wanted to enforce that the keys in a config object couldn’t have consecutive uppercase letters, because they would be automatically translated to camel case when looked up as environment variables (so awsAPIKey would become AWS_A_P_I_KEY, ugh). No need for a lint rule or whatever, you can do that with TS types in a few lines!
Post reply on HN