Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The FizzBuzz that did not get me the job

kranga.notion.site

Post reply on HN
Print view View original

231–240 of 460 posts

Re: The FizzBuzz that did not get me the job

#231

Post by bluGill »

James_K wrote: post #193
z3t4 wrote: post #168

I think this might be a troll post, but here's my comment anyway. The reason why you didn't get this job is because they filtered out themselves, it was not you that was bad, it was them thinking you where too smart for them. It took a lot of time for me to figure out this, that in a relation you want someone that are on the same level. I used to think that companies want to hire the smartest people... But no, they w…

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…

There is a lot more than ability to code that you should care about when hiring. In an interview I won't know what you do in the real world. I need a problem you can for sure do in an hour even if you have never seen it, with time left over. Fizzbuzz is good because it is weird enough that you have to do something you won't like for long term moaintenance, but not hard.

Re: The FizzBuzz that did not get me the job

#232

Post by kijin »

sasmithjr wrote: post #217
macNchz wrote: post #205

Earlier quoted context omitted.

There’s a spectrum of reasonableness with technical interview questions—the process described in this post is unreasonable, but I think plain old fizzbuzz is about as reasonable as it gets. It’s actually pretty “real world” if the candidate will be writing code in their job. It’s not a trick question nor does it require memorization or study to prepare. You’re not being given 20 minutes to solve something that requir…

The only thing that might be tricky about FizzBuzz is if the person doesn't know about the modulo operator. I can't remember the last time I used it in production code; I use it far more thinking about FizzBuzz than I do anywhere else.

If I didn't have the modulo operator, I would just check whether division resulted in a round number. I wouldn't rate someone who understands this basic principle lower than someone who just happens to know about the modulo operator.

Bonus points if you use Python and demonstrate that you know the difference between the / operator and the // operator. That's much more useful in day-to-day work.

Re: The FizzBuzz that did not get me the job

#233

Post by phlakaton »

darkwater wrote: post #102
constantcrying wrote: post #67

Earlier quoted context omitted.

Then ask . Ask the candidate if he has experience in some teams, ask what he would do if someone else was challenging his technical decisions. Ask him what he would do if he was ordered to do something which he believes was a bad technical decision. Instead of talking the company relies on easily misinterpreted hints that he might or might not be someone able to work in a team. People can be both self confident and a…

Agree as a general rule BUT candidates can (and some WILL) lie to those questions. See how they react naturally although in a simulated scenario can give you a better idea. But you should do both things, probably in 2 different interviews.

I think the lie is in thinking FizzBuzz is going to give you any insight into such matters.

Put aside your paranoia and just talk to your candidates. Ask them thoughtful questions that invite thoughtful answers. Probe gently to get at more challenging questions. Trust your ability to discern when they're BSing you.

Re: The FizzBuzz that did not get me the job

#234

Post by James_K »

wiseowise wrote: post #223
James_K wrote: post #188

Earlier quoted context omitted.

Close, it's what you might call a "job" where someone pays you to do what they say.

If by job you mean acting as a circus bear.

This reply seems very witty until you realise that there are actual people whose job it is to act in a circus. In the real world, a job is mainly being told to do things that you don't really want to do, but deciding to do them anyway because you're getting paid.

Re: The FizzBuzz that did not get me the job

#235

Post by whstl »

em-bee wrote: post #225
darkwater wrote: post #201

Earlier quoted context omitted.

Yes, they explicitly mentioned it in the rejection mail. I quote: "the answers regarding terraform vs Ansible were overcomplicated". Obviously I'm biased towards myself, but I've been an interviewer as well and if someone develops on their own an answer like I did, they would pass the interview with flying colors, because they would have shown me that they understand what's behind the thing. Again, it's my side of th…

nah, it's pretty clear, they shared their side of the story in what you quoted. damn, that's got to hurt. it feels like failing a test in school because the teacher is pedantic, not because the answer is wrong. maybe they were looking for an excuse but at least you are not left guessing otherwise. that's the only thing i can think of that would be worse.

I interviewed every engineer in my previous company for three years, often together with a lead dev.

It's amazing how the less experienced interviewers take it personally when a candidate answers with something that's unknown beyond their skill level.

Re: The FizzBuzz that did not get me the job

#236

Post by umvi »

Am I the only one that thinks TypeScript types are a terrible choice?

His solution is clever, but if that's indicative of how he's going to do engineering work at my company, I guess that means I can expect clever solutions for everything, which usually leads to esoteric, architect astronaut code bases that will be difficult for his non-clever colleagues to grok/maintain.

"Now the easy part! I just have to encode the numbers in base 15 and I could apply the 2 and 5 rule to 3 and 5!" Encoding things in base 15 is too clever for me.

Back to the original statement I made: TS types are a terrible choice because TS types are not debuggable. If you get too fancy with them, you need a god in TypeScript to debug because you cannot set breakpoints inside of types and step through to see how generics and constraints propagate (as would be required by a mere mortal in order to debug).

"Hey, there's a bug in Joe's fizzbuzz function, but he's out on PTO, can you fix?"

"Sure, I'll step through with a debugger real quick... Oh wait, it's 100% typescript types, I can't step through with a debugger. I took a look but it looks like it's encoding numbers into base 15 for some reason... I don't want to break anything further, let's just wait for Joe to get back"

"Actually, can you just re-write it using normal conditional flow logic? We want more than just Joe to be able to touch the code."

Re: The FizzBuzz that did not get me the job

#237

Post by whstl »

skeeter2020 wrote: post #166

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.

Re: The FizzBuzz that did not get me the job

#238

Post by Mawr »

wakawaka28 wrote: post #164
constantcrying wrote: post #144

Earlier quoted context omitted.

The way you figure these things out is talking about them. Plenty of people like to solve challenges in weird ways and might even see the suggestions that it is inappropriate as a challenge. >There are not really multiple ways to read "I don't think that's a good idea" in an interview. If your "technical depth" leads you to an inappropriate solution, it doesn't matter if it's right. Just because this solution worked…

>Plenty of people like to solve challenges in weird ways and might even see the suggestions that it is inappropriate as a challenge. That's absolutely not the way to approach an interview. "Let me try to do things the exact way you clearly don't want, just to see if we can." Is the candidate going to try to do their next job this way? What are you going to do when their egotistical attempts to solve problems in cleve…

> I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most people. If you're talking about someone with no working experience and who claims to be self-taught, you really have to make them write code.

The choice is not limited to made up toy problems vs not testing coding skills at all. You can give them real problems to solve.

> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.

Hahaha, and how exactly do you write an 'industrial-grade' FizzBuzz? ;)

Obligatory: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

> The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them.

Oh but it is. If I were to ask you, the expert, to draw a blue line with red ink and then attempt to draw conclusions from your behaviour based on that question, could I ever get a valid assessment of you? If a test is faulty, so are its results. Garbage in, garbage out.

Interviewing is no trivial task. It is an attempt to test how well someone will do a thing without having them actually do it. By definition, that is impossible. Still, we can try to get good enough results by minimising the number of differences between our test environment (interview) and production (the job). That will involve:

a) making the interview environment resemble the job as much as possible (no hazing, minimal pressure on the candidate, writing code in and IDE instead of a whiteboard, etc.)

b) presenting the candidates with coding tasks that match what the company does on a daily basis (take a suitable bug you had in your codebase, touch it up a bit with more issues, have them fix it; pair program with them to add a new feature to your codebase, etc.)

Some concrete examples:

- https://rachelbythebay.com/w/2022/03/19/time/ (it suffices to read the first two paragraphs)

- https://quuxplusone.github.io/blog/2022/01/06/memcached-inte...

- https://blog.jez.io/bugsquash/

Re: The FizzBuzz that did not get me the job

#239

Post by whstl »

umvi wrote: post #236

Am I the only one that thinks TypeScript types are a terrible choice? His solution is clever, but if that's indicative of how he's going to do engineering work at my company, I guess that means I can expect clever solutions for everything, which usually leads to esoteric, architect astronaut code bases that will be difficult for his non-clever colleagues to grok/maintain. "Now the easy part! I just have to encode the…

His solution was clever because the problem was artificial, constrained, and required him to be creative.

He went to a solution he knew well, and the interviewer didn't ask to change.

If you solve this problem and use strings to do fizzbuzz instead of modulo, would you accept me saying that you're a doofus that doesn't know coding simply because you didn't do it the normal way?

Re: The FizzBuzz that did not get me the job

#240

Post by whstl »

BearOso wrote: post #214
whstl wrote: 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.

Personally, I think it's literally unbelievable. It reads like fiction.

There's someone else in this thread who did the same problem 4 days ago and the story seems to match.
Post reply on HN