[HN Gopher] The FizzBuzz that did not get me the job
___________________________________________________________________
The FizzBuzz that did not get me the job
Author : Andugal
Score : 415 points
Date : 2025-01-21 20:15 UTC (4 days ago)
(HTM) web link (kranga.notion.site)
(TXT) w3m dump (kranga.notion.site)
| jcz_nz wrote:
| Very clever! Also, I'd steer absolutely clear of any company that
| does this.
|
| This doesn't assess anything meaningful, it's an ego trip for the
| interviewer. Ugh.
| phkahler wrote:
| Yep. All those extra rules missed the entire point of FizzBuzz
| - people who have trouble writing code fail at even simple
| thing like FizzBuzz.
|
| The extra rules presented sequentially and their interactions
| might have revealed more about both parties, but it's hard to
| tell without seeing them in person.
| bootsmann wrote:
| Disagree, this is a significant step up from the leetcode-style
| programming puzzles that other companies do. It doesn't bank on
| the interviewee knowing the specific trick that makes the
| puzzle work and instead tries to somewhat test the skills that
| are more significant for the job at hand like debugging,
| refactoring and dealing with changing requirements.
| Mawr wrote:
| That was likely the thought process of the interviewers,
| however wrong.
|
| FizzBuzz works well enough as a lowest common denominator
| screening test, but it doesn't scale up. At its core, it's an
| entirely made up problem with no relevance to anything you
| may ever do at a job. How do you evaluate requirements for a
| problem that is not real?
|
| The higher level the skills you want to test, the more
| realistic your questions have to get.
| bluGill wrote:
| A real job is often simialar to fizzbuzz in that there is
| no eligant solutians. There are several solutions but they
| all have some special case. a real world problem would take
| you a week to solve though and so we can't give them to you
| in an hour.
| pclowes wrote:
| Most leetcode questions are just asking if you can recognize
| the same 15 core CS algorithms in different situations and
| pick the right one.
|
| A few have a trick or insight but I haven't ran across those
| in interviews.
| raphman wrote:
| Oh, I guess a few of these additional rules might prove helpful
| for weeding out people who just memorized FizzBuzz but don't
| know much more.
|
| However, all of these "don't use the right tools" and "write
| extremely compact code" rules mostly select for people who are
| good in code golf, not for people who can solve actual business
| problems or write maintainable software.
|
| And it seems like this was the only programming challenge in
| the whole interview?!
| IshKebab wrote:
| I think it's supposed to test refactoring and debugging
| abilities, but it just didn't work and they didn't know what to
| do. Anyway trying to argue that 0 is not a multiple of 3 is a
| big red flag.
| TZubiri wrote:
| Here's my attempt, if OP can read this:
|
| https://github.com/TZubiri/fizzbuzz2.0
|
| Apologies to the employers that I uploaded it to Github, but I
| was trying to keep my green squares thingy streak. I didn't
| upload the requirements so that it's harder to google/scrape into
| an LLM.
|
| My first note is that, the quality of the code was very high,
| evidently the code worked and it did so in a manner that
| introducing changes either required little or no effort. It is
| unfortunate that the interviewers were annoyed by this rather
| than satisfied, it reads as if the interview process was written
| by one person and the interview was executed by someone else and
| was trying to check some boxes and get to his lunch.
|
| My second note is that, while not incorrect, the approach was a
| bit academic and certainly harder for others to read. The
| functional approach is not the most common and definitely not as
| easy to read as the procedural approach. The interviewer,
| potentially a coworker, would be reading this and thinking that
| he would have to read this as part of their job. I don't see any
| upside to a functional approach here, perhaps in cases with more
| complexity if I were keen to this approach the pros and cons
| would be weighted more closely, but it feels overkill.
|
| In a sense it reminds me of the satirical
| https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... .
| Where it takes the POV of someone overengineering the fizzbuzz
| with javalike GO4 patterns.
|
| Third, yes, the requirements are very weird and don't correlate
| very well with real problems, in some scenarios it forces the
| developer to do some weird things to the point where you are not
| sure how someone will evaluate you. If I were an employer I
| wouldn't be able to distinguish between someone that does 10 ifs
| in a row because he doesn't know how to use more expressive
| language constructs, or because he is trying to avoid an array or
| whatever fucky condition was placed.
|
| Finally, requirement 7, to not use numerical literals and
| functions, indeed does require to reimplement some basic math,
| but it was not necessary to implement all of the math. You
| implemented base 10 addition. My solution just implemented signle
| digit base 3 addition with overflow. I think overimplementing is
| a common trap in programming, where you find a solution in 1
| minute, and then spend 60 minutes implementing that solution,
| whereas if you spend some time looking for more efficient
| solutions, you might cut that implementation and debugging time
| in the long run.
|
| I wouldn't say that the approach was wrong, it certainly would
| have bode well with more academic types that value functional
| approaches, perhaps if they use functional languages like F#,
| haskell, Scala, Clojure, etc.. But a javascript shop just screams
| pragmatism and lack of love for the programming language, I don't
| think you read the room here.
|
| Oh and also, definitely make an AWS account and play with the
| free tier, just launch a vm (ec2). AWS was hugely influential in
| terms of design and pricing in the SaaS industry. Remember that
| AWS was the first big Cloud provider Google and Azure followed,
| so it's not as important to make an account with the other big
| cloud providers.
|
| Best of lucks! I'm sure you'll find something.
| whstl wrote:
| You would also fail this specific task, as you clearly missed
| the first requirement that says maximum of 30 lines.
| KingOfCoders wrote:
| I love FizzBuzz as an interview question and then dive into tail
| recursion and compiler optimization. I learned a lot from
| candidates. I miss my interviewing days.
| ElectRabbit wrote:
| They solved a lot of our problems we didn't find good solutions
| for!
|
| (/s)
| KingOfCoders wrote:
| I never had, sadly, compiler optimization problems, I mostly
| did simple web database frontends for 30 years. Code monkey
| stuff.
| ibloomt wrote:
| If you are still looking for a job -> ping me
| em-bee wrote:
| unfortunately i am not as clever as the author, otherwise i
| would have liked to ping you.
| sd9 wrote:
| The interviewers would've been a lot happier if they'd just
| prescribed a language up front.
| riffraff wrote:
| 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 had to agree it worked and gave him full marks.
| sjducb wrote:
| At work, would you rather have a boss that makes you implement
| dumb ideas? Or would you prefer a boss who recognises that your
| idea is better, then rewards you for it?
|
| You are interviewing them too.
|
| I would also have hired the candidate.
| tcbawo wrote:
| The author's answer was clever, but also unconventional. The
| company was probably looking for someone that would write
| code in a shared codebase that other developers will need to
| contribute to and maintain. Thinking outside the box and not
| following suggestions might have raised a red flag that this
| person might be a loose cannon. In a small company, hiring
| someone smart but unwilling to follow directions can be
| detrimental. Kudos to the author, though, for being quick
| thinking and creative.
| xnickb wrote:
| Then that expectation should be communicated clearly, not
| via some obscure passive aggressive subtones, don't you
| find?
| a1j9o94 wrote:
| Ideally yes, but most people in corporate settings don't
| communicate clearly. So if they have a culture of
| dropping hints, and you don't take them you're not going
| to do well at the company.
|
| It's not good, but it's an accurate reflection of the
| work environment.
| Angostura wrote:
| Then don't say" "the interviewer noted that I could even
| use esoteric programming languages but advised me against
| because there would be lots of rules that would be hard to
| follow"
| dijksterhuis wrote:
| this is a good filter.
|
| if someone starts careening through the task using
| brainfuck, they ain't thinking like a senior dev at day
| job i.e. simple, clear, easy to follow and maintainable
| code writing.
|
| i don't care how clever you are. i need to know you're
| not going to rewrite the frontend in your first week
| because of a "big brain" moment [0]. using python or
| something simple without being told to helps me feel like
| you won't do that, and that i might be able to trust you
| on day 0.
|
| expectations on seniors are higher
|
| [0]: https://grugbrain.dev/
| constantcrying wrote:
| 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 able to create a cheeky solution _and_ be sociable
| people with decent team skills.
|
| If your hiring process relies on psycho analysis of the
| candidates, it probably will not work very well.
| darkwater wrote:
| 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.
| bluGill wrote:
| There is plenty of research on interviews and how to
| prevent them - or so the interview trainers hr made me
| take classes from before I was allowed to interview
| anyone.
|
| disscussions here universially show no evidence anyone
| knows it exists much less what it is. I at least know it
| evists but I don't know how to find it
| phlakaton wrote:
| 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.
| yujzgzc wrote:
| Even in the candidate's own telling, it is obvious that
| they misread very strong signals from interviewers. I've
| sometimes been that overly clever programmer and I've had
| to deal with it too, on the one side it's great that they
| bring energy and brains, but it is exhausting. At some
| point when moving fast you just want to have some people
| that you can go "hey just fix this bug wouldya" and trust
| that they're _not_ going to come back with a clever but
| convoluted and inefficient hack.
| bartread wrote:
| Exactly. On one level I loved this solution but it's
| definitely "clever code" and, unless there is a
| particularly strong requirement driving it (e.g.,
| performance), I don't particularly like clever code in
| production systems.
|
| The problem of "What does this do?" is prevalent enough,
| and occurs often enough under pressure, without adding
| excessive niftiness into the mix.
|
| I do still like the solution though.
| makeitdouble wrote:
| Yes.
|
| Also, this still properly fits the "you're interviewing the
| company as well" paradigm. If the author wanted a company
| that values cleverness or can deal with people who go
| unbeaten paths, they now know it wasn't the right place.
| nmfisher wrote:
| Normally I'd give the company the benefit of the doubt for
| the reasons you point out, but not in this case. If you're
| asking increasingly convoluted/unrealistic/impractical
| questions, you can't complain that the response wasn't
| practical.
|
| It gives off strong "your answer might be correct but it's
| not on my answer key so I'm marking you wrong" teacher
| vibes. Avoid at all costs.
| whstl wrote:
| The interview was also very clever and unconventional.
|
| "Numeric types, number literals and their associated
| methods and operations are forbidden".
|
| If this is how the interview behaved, I'm pretty sure this
| is a company that expects developers to write code in a
| certain way but doesn't really know how to guide them.
|
| Kudos to the author, but shame on the interviewer.
| Gee101 wrote:
| No point in dying on every hill. Sometimes letting people get
| their way today (even if you don't agree) could be long term
| win for you.
| strken wrote:
| I probably wouldn't have hired the candidate, at least for
| the position as stated.
|
| My reasoning is that the company advertised a position for a
| senior engineer with 4 years experience. Leaving aside title
| inflation and whether someone with 4 years experience is
| actually a senior engineer, and leaving aside the really dumb
| test, that position requires communication skills, common
| sense, maturity, and just generally knowing what's going on.
| A candidate who misreads the situation in an interview so
| badly that they can't take the interviewer's unsubtle hints
| is going to mess up other communication within the company,
| has likely never been on the other side of an interview
| before, and is at risk of allowing the kind of "clever" code
| that destroys companies.
|
| Again, this is only a problem for a senior engineer. I _want_
| junior and mid-level engineers to be clever and enthusiastic.
| Senior engineers are meant to understand that I have five
| interviews this week and their attempt to channel Aphyr[0] is
| going to make my life harder when I want to talk about their
| thoughts on maintainability.
|
| [0] https://aphyr.com/posts/342-typing-the-technical-
| interview
| phlakaton wrote:
| If you want to assess communication skills, common sense,
| maturity, just generally knowing what's going on, or any
| other senior engineering quality, I advise you steer hard
| away from FizzBuzz.
|
| FizzBuzz is the mind-killer.
| rbetts wrote:
| The interesting contrast, though, is that the blog post
| demonstrates strong communication skills and self
| awareness.
| skeeter2020 wrote:
| If you're building some sort of basic, crud app you shouldn't
| hire this candidate, or at least recognize they are a project
| - is that what you want?
|
| But if you're doing anything unique, or experimental they
| might be a great fit.
|
| Most of us are doing the second.
| whstl wrote:
| I mean, the interview requirements are quirky and
| unconventional as heck.
|
| Anyone saying "you gotta check divisibility without math"
| on the job would get laughed out of the room.
| blharr wrote:
| 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.
| qsort wrote:
| > 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 the misunderstanding,
| but "I don't think that will be a good idea" is not a
| suggestion, it's an order.
| xnickb wrote:
| Smells like poor management to me.
|
| "We'd like you to explore this path and show how you would
| deal with problems that occur there" is much easier to
| interpret than the passive aggressive tone of "I don't think
| .."
|
| I would also go with my idea and see how the manager reacted:
| there is only so much micromanagement I'm willing to tolerate
| at work. Interviews go both ways.
| 317070 wrote:
| Yeah, it's an English thing. A literal translation in Dutch
| would mean "explain yourself here", and if you'd change tack
| because of the question alone, it would seem like you really
| lack self-confidence.
|
| But after living in the UK for a bit, in the UK that is most
| likely an order.
| vkou wrote:
| > and if you'd change tack because of the question alone,
| it would seem like you really lack self-confidence.
|
| Or because the candidate realized that they've messed up,
| and by dropping the issue can at least salvage the next XY
| minutes of the interview by not going down the wrong rabbit
| hole.
|
| "Could you tell me more about this?" and "Are you sure
| about this?" are invitations for providing the
| rationalization for your answers. "I'm not sure that's a
| good idea" is a very unsubtle, but polite way of hinting
| that the you have gone way off the map.
|
| As an interviewer, I want my candidates to succeed. I want
| them to put their best foot forward. I've asked my question
| over a hundred times, and I've seen many ways that people
| have solved it, correctly or no. If I'm giving them this
| suggestion, it means that I know that they are going down
| one of the many, many wrong garden paths.
| 317070 wrote:
| I know, I have now spent enough time in the Anglosphere
| to understand this cultural code. But I do want to
| emphasize that, yes, if you only know English as a
| language, that that subcontext is not obvious.
|
| In France, professors would literally say "You are
| wrong." as an invitation to explain yourself better.
| There are only 500km between London and Paris, but the
| culture behind these words is the complete opposite.
| throwaway173738 wrote:
| That phrase in English has a strong connotation of the
| recipient screwing up somehow though, so I'd probably say
| "that's not what I was looking for in this case. Try
| something else."
| hardlianotion wrote:
| In the UK, it's not at all cut and dried - depends more on
| the personality of the person saying it. Could be lazy
| assertion of control, an attempt to help or an implied
| challenge.
|
| I also think the interview setup and management were poor.
| jorvi wrote:
| > Yeah, it's an English thing. A literal translation in
| Dutch would mean "explain yourself here",
|
| That's just patently untrue. The literal translation is "ik
| denk niet dat dat een goed idee is" and the better
| translation would be "dat is niet de bedoeling".
|
| If I got told in an interview "dat is niet de bedoeling"
| I'd be damn sure to rework my solution because they're
| clearly trying to coax me towards whatever they're looking
| for. And in a way it is actually a nice thing of them,
| because they could just say nothing and fail me out of that
| round of interviews.
| constantcrying wrote:
| Good leadership starts with clearly communicating
| expectations. If your boss can not say "I want you to use
| this tool" or "use whatever you seem fit", but instead hints
| to you as to some possible drawbacks of certain tools he is
| bad at his job.
|
| There are multiple ways to read that suggestion. It can also
| be read as the interviewer saying he does not believe in the
| technical depth of the candidate, which can be taken as a
| challenge.
|
| It would also have been better to give a choice of a few
| selected languages. As that means the interviewer can be much
| better prepared.
| wakawaka28 wrote:
| [flagged]
| constantcrying wrote:
| 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 for FizzBuzz and all their rules does not
| mean it's maintainable. It's obvious to most senior
| people that such a weird solution is brittle and
| overkill, even if they can't come up with a rule to break
| it. But here's a simple one: Output FizzBuzz if all the
| rules are passed, except if there is a database entry
| matching the number. Good luck solving that with some
| bullshit type theory, and good luck to anyone who comes
| behind this guy to add that rule to his Rube Goldberg
| code.
|
| "What set of tools would you choose to build <normal
| software project>? And why would you choose them over
| alternatives?" or "We here at X make use of Y a lot, have
| you worked with Y or alternatives? What did you think
| about Y or alternatives?". Both are infinitely more
| telling about the candidate.
|
| Someone's choice for a contrived joke problem will not
| reflect their choices for a real software project.
|
| >For example, I worked with one mostly self-taught guy
| who wanted to rewrite everything in a niche compiled
| language, including things that really should be done in
| scripting languages like Python or shell. Thankfully
| nobody else let him do that. But deep down I think he
| didn't accept that he was wrong, and on multiple
| occasions he expressed that he thought the average person
| on the team was woefully inexperienced. In fact, it was
| him that was woefully inexperienced, because he didn't
| understand how inappropriate and even flat-out wrong his
| solutions were.
|
| I worked with people who liked to solve silly problems in
| silly ways, but when it came to real projects always
| preferred mature languages and libraries which focused on
| long term support, stability and maintainability.
|
| The problem with the interview is that instead of talking
| about the subjects, they themselves want to rely on
| subtle hints about the candidate. Which may not mean
| anything.
| wakawaka28 wrote:
| >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
| clever ways despite your advice and even instructions
| bites YOU?
|
| >"What set of tools would you choose to build <normal
| software project>? And why would you choose them over
| alternatives?" or "We here at X make use of Y a lot, have
| you worked with Y or alternatives? What did you think
| about Y or alternatives?". Both are infinitely more
| telling about the candidate.
|
| 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.
|
| >Someone's choice for a contrived joke problem will not
| reflect their choices for a real software project.
|
| The interviewers tried to tell him to approach it like an
| industrial-grade solution, not a weird academic exercise.
| He was in the mood to do an academic exercise, and that's
| what he did. The interviewers seriously don't know what
| he will do in the workplace. That's why they're trying to
| make him write some code in such a way. Self-taught
| people are more of a risk in that they often
| overcomplicate (or oversimplify) things.
|
| >I worked with people who liked to solve silly problems
| in silly ways, but when it came to real projects always
| preferred mature languages and libraries which focused on
| long term support, stability and maintainability.
|
| Good for you? I'm not talking about silly problems. I'm
| talking about someone who wanted to rewrite our build
| system in a compiled language, and our Python unit test
| driver in a different compiled language. He wanted to use
| inappropriate "fun" languages at work. I'm not
| categorically against using interesting new languages and
| tools, but when there is ZERO benefit to doing so and
| nobody else knows said languages, it is not to be done.
|
| >The problem with the interview is that instead of
| talking about the subjects, they themselves want to rely
| on subtle hints about the candidate. Which may not mean
| anything.
|
| 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. The candidate wanted to show off his
| knowledge of type theory despite pretty obvious hints
| that the interviewers didn't want that. That means he has
| bad social skills or else he has an ego issue. The fact
| he blogged about it in such a way to brag about his
| solution suggests he does have an ego problem. There's
| also a healthy chance that the whole story is fiction,
| just to advertise himself as a self-taught "genius" who
| is turned down for being "too good" lol.
| constantcrying wrote:
| >The whole point of the interview is to get hints about
| the candidate.
|
| Which it didn't accomplish at all, because the
| interviewers refused to do the single most important
| thing. Actually talking with their candidate about these
| things. Instead they are relying on psychoanalysis to
| divine some secret meaning in his actions.
|
| I am not arguing that your interview shouldn't try to
| figure out the personality or professional approach of a
| person, but that this particular interview made it near
| impossible to do so. Simply because they refused to talk
| about the things they wanted to know.
| wakawaka28 wrote:
| You make it sound so much more mysterious than it is. The
| candidate rejected polite social cues to not go down the
| path he did. He came up with an oddball, brittle, and
| undebuggable solution. They said what they wanted for
| this fairly simple problem. It's not a guess at some
| secret, it's a simple observation that the candidate is
| not right for the job.
| Mawr wrote:
| > 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/Fi
| zzBuzzEnterpris...
|
| > 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/
| kstrauser wrote:
| I strongly disagree. I'll take the opportunity to wildly
| diverge when the chance naturally presents itself. It's
| how I can show the interviewer that I'm a creative person
| who comes up with interesting alternatives and can also
| be fun to work with.
|
| For example, I was asked to do FizzBuzz once. I laughed,
| said we've both done this dozens of times, and would they
| like to have fun with it? We ended up building this wild
| thing with recursive Python generators and itertools and
| a state machine or something. I don't remember the
| details a decade later, except that the interviewer
| thought it was hilarious, and I taught them some Python
| ("wait, that part there, does that actually work?!", and
| they paused me to test it on their laptop).
|
| I got the job.
|
| As a candidate, you're interviewing them, too. If the
| person is a martinet who can't look deviate from the
| script even slightly, and you have other options, do you
| _really_ want to work with them? That sounds joyless.
| wakawaka28 wrote:
| Sometimes going off script is OK but that is not what
| they wanted here, it seems. Besides I guess that if this
| interview ever happened, the "solution" might not be the
| reason that they weren't hired. But the numerous hints
| that the candidate got suggest that they wanted a normal
| solution. Asking someone to deliver a solution within
| some reasonable constraints is not "joyless" and
| disregarding these constraints on purpose over and over
| is not "smart."
| dustingetz wrote:
| what is this good leadership you speak of, where did you
| encounter that?
| throwaway173738 wrote:
| Yeah as an interviewer if the type-heavy solution wasn't
| what I wanted to look at I would've asked the candidate to
| pretend like they don't understand the type system and
| adjust the solution accordingly.
|
| Actually though if they wanted to test for debugging
| ability, presenting some real code with defects would have
| worked a lot better than this.
| phreack wrote:
| That last part is key. Way better than FizzBuzz from
| scratch, best interview results I've seen come from
| giving a candidate a pre-made solution or architecture
| document that technically works but with glaring issues
| and just talking about their opinion on it, coding or
| pseudocoding optional for presenting solutions.
| jajko wrote:
| That's part of good senior/manager skills unfortunately.
| These sort of subtle hints happen all the time, it looks bad
| if folks keep missing them. Ie British are famous for them,
| you'll rarely experience straight talk to the bone.
| megous wrote:
| If company is trying to hire people in other
| countries/cultures to save some buck, they should be mindful
| that communication may be a bit more of an issue, and try
| harder, too. Otherwise they'll have the same issue after
| hiring and not just during interviews.
|
| It's not all up to the interviewee to decipher everything.
| Both should be trying a bit to get to the same understanding,
| prior to setting off to work.
|
| Anyway, the company will be wasting money when the
| communication works out poorly, so it's ultimately up to
| them.
| plasticchris wrote:
| If the interviewer were better they would instead ask: if no
| one else on the dev team knows the type system how do you
| handle that situation?
|
| Which gets at the real risk, maybe valid, that someone super
| smart who isn't the best communicator will go and make a
| bunch of code that no one else in the company can reason
| about. Maybe you get a really nice explanation of the type
| system, or they are aware this is an esoteric approach but
| used it anyway because you said anything goes and it's cool.
| lowbloodsugar wrote:
| Interviewer was wrong. Interviewee learned that interviewer
| is happy to advance incorrect ideas and stifle innovation.
| hahn-kev wrote:
| Yeah I agree. You should be demonstrating how you would write
| code in the job. Based on devs I've worked with, I don't think
| a pure type solution as presented is very maintainable.
| XorNot wrote:
| On the job I don't have lines of code restrictions, and can
| use math functions.
| whstl wrote:
| > You should be demonstrating how you would write code in the
| job
|
| That was forbidden, check the rules given by the interviewer.
| gota wrote:
| > would probably have hired this person
|
| Of course. They can write (as in, natural language, not "just"
| code). In my opinion always the second most important skill for
| every knowledge worker, regardless of what their actual job is
| raffraffraff wrote:
| There is a power imbalance between interviewer and interviewee.
| If an interviewer really wants to, they can throw you the
| equivalent of "what number am I thinking of" and watch you
| struggle through 50 tries before your brain runs out of glucose
| and you go blank.
|
| If I'm interviewing someone and they give me a right answer
| that wasn't even in my copy of "the teacher's answer book", I
| realise they're _good_ and let them ace it.
|
| It maybe be that there was a personality clash and they simply
| didn't think the candidate was a good fit for the team. Been
| there, and understand that. Or they maybe got butt-hurt that
| the candidate's answer broke their test. Either way, the
| candidate is better off not working there.
| prinny_ wrote:
| But it was a good idea! The interviewer just didn't expect a
| rock solid idea on the OP's part. It seems the interviewer was
| more interested in creating a hard interview rather than
| finding a good engineer. And while we're on that, I firmly
| believe that giving a business-agnostic pull request "spiked"
| with errors, brad practices and tricky to find bugs and asking
| the interviewing party to review it is going to tell you much
| more about them than leetcode-interviewing them.
| joshstrange wrote:
| > 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.
|
| Yep, as an interviewer I hated when I'd try to gently (then not
| so gently) nudge a candidate in a direction because I could see
| they were going down the wrong path and they insisted they knew
| best or refused to listen to my advice. I'm not looking for
| "loyal foot soldiers" who follow my every order, and I'm not
| looking for people to kiss my butt or blow smoke up it, but the
| audacity to push back on an interviewer multiple times when
| they're trying to help you... (NOT what I think happened in the
| OPs case, I'm thinking of my own experience here).
|
| For me it was a massive red flag. If I can't get you to listen
| to my advice in a scenario where most people are trying their
| hardest to be "attractive" to a company then what's going to
| happen when I ask you to change something in a PR? Or tell you
| that the approach you are taking is not going to work?
|
| That and the person who argued with me about tabs and spaces
| after I made a joke about it and then proceeded to email me
| with more sources as to why one was better than the other.
| Honestly, this person was younger and I don't think they meant
| to be so abrasive, but it came across very "know-it-all" and
| one thing I don't like is people who come into a company and
| start trying to change things or do things "their way" without
| first getting the lay of the land and understanding _why_
| things were done the way they were (aka Chesterton's Fence).
| lowbloodsugar wrote:
| Interviewer was wrong however.
| bhaney wrote:
| > I don't think it would be fair to name and shame them.
|
| I disagree, but of course that's entirely up to you.
| FridgeSeal wrote:
| The more time that goes on, the more I think as a community we
| should unashamedly be name-dropping anywhere that has poor
| practices, bad comms, or bad behaviour.
|
| Neglecting to name them just lets them get away with it.
| chengiz wrote:
| He cannot name and shame them because this did not really
| happen.
| James_K wrote:
| Do you think you'll make it to the interview stage of the
| hiring process if the interviewer looks on your personal
| website and finds that you wrote an entire blog post calling
| out your last interviewer by name? I would not risk inviting
| such a person.
| sjducb wrote:
| I think you're an A player. You were rejected by a B player that
| was looking to hire C players.
|
| Apply to other companies. In this case it's not you, it's them.
| croes wrote:
| To be fair, we only heard one side of the story
| pclowes wrote:
| I think if that was an honest description of the interview
| question then that alone indicates insecure B players _at
| best_.
| cwmoore wrote:
| "What a terrible day to have ears!"
| stevoski wrote:
| I predict that very soon you are going to be offered a remote job
| paying more than EUR50,000/year.
|
| That's due to this excellent post about your excellent abilities
| and reasoning appearing on HN.
|
| !Mucha suerte!
| bowsamic wrote:
| That isn't much money, even for Europe
| stevoski wrote:
| I'm referring to specifics in the article. The interview was
| for a remote job paying EUR50K/year.
| scandox wrote:
| Well it's all relative dude
| quectophoton wrote:
| 50k EUR/year for me would be like 2900 EUR/month after all
| taxes. Monthly expenses in the part of Spain I live in are
| ~800 EUR (rent + food + electricity + water + 1Gbps
| internet).
|
| 2900 - 800 = 2100 EUR to do whatever I want with. Even if I
| decide to put half of that into savings, that's still ~1000
| EUR to spend freely, and any unspent money would go into
| savings too at the end of the month.
|
| Or in other words: With a salary like that I would be able to
| pay a family member's full monthly expenses if they are in
| rough times, and still have leftover for myself.
| bowsamic wrote:
| Fair enough I'm just saying I live in Germany and just
| entered my first software position and get 73k, and I don't
| live in Berlin or anything. I suppose in Spain living
| expenses are much cheaper. Your monthly expenses including
| food are less than my rent. Tho I still think I have more
| than 2100 left over after expenses
| quectophoton wrote:
| Yeah to be fair I don't live in a big city or any
| touristic location where monthly expenses could easily
| double, but it's still nice and comfy enough that I don't
| plan on moving even if money weren't an issue.
| em-bee wrote:
| 73k as a junior? (your first software position)
|
| that sounds like a major exception. the average for
| juniors in germany is 50k or below.
| bowsamic wrote:
| I have a PhD, maybe that's the difference. I asked for
| 65k but they refused and gave me 73k
| em-bee wrote:
| ah, yes, that's probably it. also typical german. don't
| pay for the role, but for the formal qualification.
| pjmlp wrote:
| I am active in DACH space since 2003, and I am surprised
| that isn't between 50k and 60k for a junior position.
|
| More to you, but that isn't a common entry level, at
| least for companies whose main business isn't selling
| software.
| intelVISA wrote:
| DACH is like the reverse Silicon Valley?
| pjmlp wrote:
| Including healthcare, vacation days, maternity leave, no
| calls after work or during vacations, not being on call
| unless paid for and is on the contract, unions,...
|
| Yep, the exact opposite.
| pjmlp wrote:
| It certainly is for those of us in Southern Europe, many
| people have no idea how good they have it.
| em-bee wrote:
| really? i have seen very few positions in europe offering
| more than 50-70k a year, and i looked at hundreds. that
| includes seniors.
| hiq wrote:
| I assume you haven't looked at Switzerland?
| pjmlp wrote:
| 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.
| em-bee wrote:
| i have only seen few offers from switzerland, and i
| didn't see anything that stood out. i am only looking at
| remote jobs though. that may skew my perception. i did
| notice that switzerland had a higher average compared to
| the rest of europe when looking at statistics.
| tgv wrote:
| 50k for a junior dev isn't much, but it isn't low either.
| Software companies and larger ones might pay a bit more,
| smaller ones and those that have a small IT staff a bit less.
| That's the salary situation in the country. It's not the USA.
| bowsamic wrote:
| I live in Germany
| jodrellblank wrote:
| Median household income in the UK is EUR41k (PS34.5k).
|
| Top 5% richest income in UK is EUR81.3k (PS68.4k).
|
| https://www.ons.gov.uk/peoplepopulationandcommunity/personal.
| ..
| jschoe wrote:
| Europe has quite low salaries actually. While in the US you
| can very easily earn 200k++ as a completely average tech guy,
| that achievement is basically impossible in Europe.
| leoff wrote:
| I've created a joke Python library, hoping that I would get asked
| to code it in an interview. No luck so far
|
| https://github.com/leoffx/fizz
| belter wrote:
| I get the point, but update your library to support entries
| higher than 100. :-)
| isaacremuant wrote:
| I think the joke is that it's hardcoded. It's definitely
| easier to implement it for n numbers yourself.
| dmd wrote:
| Love the implementation. Don't let anyone convince you to
| change it.
| kmoser wrote:
| Reminds me of this purposely over-engineered Java version:
| https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
| sixothree wrote:
| I used to give fizz buzz with zero additions. Just write me a
| fizz buzz in c#. We didn't actually want to take up a lot of the
| interviewee's time. There were other tests, tests better than any
| programming tests. They had to take like one for SQL and one with
| nothing but logic puzzles, the latter of which is most indicative
| of whether a person will be competent at the job.
|
| Fizz buzz just lets me see their coding style (single letter
| variables, lack of curly braces after ifs, comments, platform -
| console, web, service) and whether they're willing to allow
| simple mistakes into their finished product. So many mistakes.
|
| But it's the least I can do to get some information out of a
| candidate who is already overburdened by the process.
| whstl wrote:
| A 2 minute Fizz Buzz at the beginning of the interview is great
| to filter people who managed to fool the recruiter.
|
| It is also a cool opportunity to "talk shop" if they go for a
| strange solution.
| yosito wrote:
| This article describes everything that's wrong with tech hiring
| these days. There is zero evidence that success on these
| arbitrary programming riddles have any correlation with success
| on the job, and yet we force candidates through a gauntlet of
| completely unrealistic brain teasers solving problems that they
| will literally never have to solve on the job.
|
| I've recently completed half a dozen 2-4 hour coding challenges,
| gotten a perfect score according to the tests provided, and after
| a couple of weeks, gotten a boilerplate rejection email.
|
| What's the point?
| em-bee wrote:
| i agree. this solution is to clever for its own good. but those
| requirements were essentially asking for a clever solution. if
| the challenge can't be solved without being clever then it is
| the wrong challenge.
|
| this interview tells me that the candidate is smart and knows
| typescript well, but it doesn't tell me if they can write code
| that is clear enough so that a junior can understand and modify
| it. because the latter is the reality of work. a year from now,
| a junior will be asked to adapt this code to say replace 3 with
| 7 or something like that, and they will probably not be able to
| it without having to rewrite all of it from scratch.
| belter wrote:
| Somebody was interviewing somewhere else and they played a man-
| in-the-middle attack on you? :-)
| pnw_throwaway wrote:
| How much of the article did you read? They were looking for a
| senior, with more than twice the experience the poster has.
| Being able to pump out algos is only part of the job.
|
| While there a solution is clever, it's not terribly
| maintainable and likely didn't fit the bill.
|
| Beyond that, things like soft skills matter for senior roles.
| The author can write, there's no denying that, but we don't
| know how well they can explain the why of their solution. It's
| very likely the interviewers wanted more traditional functions
| that were unit-testable.
| constantcrying wrote:
| >While there a solution is clever, it's not terribly
| maintainable and likely didn't fit the bill.
|
| Why invite him then?
|
| >Beyond that, things like soft skills matter for senior
| roles.
|
| Then _talk_. Ask him. Psychoanalysis of the solution of a
| stupid brain teaser will not answer your questions.
| pnw_throwaway wrote:
| I feel like there's a disconnect in this thread. The things
| I mentioned are pretty standard fare.
|
| If you don't mind me asking, are you a senior level
| engineer?
| Cthulhu_ wrote:
| I've worked for companies in NL whose tech interview wasn't
| nearly this involved but the wages offered were comparable or
| better; I seriously doubt any of the skills asked or demonstrated
| in the interview would actually be necessary for this job, not
| when it's just node which in all likelihood means it's mostly
| REST like APIs and some business logic. (I'm making some sweeping
| generalizations here)
| adhamsalama wrote:
| You need an enterprise FizzBuzz implementation to pass the
| interview.
|
| https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
| lcnPylGDnU4H9OF wrote:
| It needed to be less than 30 lines, not more than 30 files.
| squiffsquiff wrote:
| To me, the rules given to you are pure gatekeeping. The fact that
| even after they had given successively more restrictive rules for
| what should be a trivial program they then verbally restricted
| you further confirms this. I would question whether this was
| actually an interview for a real job or not but in any case it's
| not you it's them.
| chvid wrote:
| Asking a trivial question is a simple way to test a person's
| basic skill but also more importantly his ability to communicate
| and work with others who may not have the same level of
| expertise.
|
| If you use it as a chance to make a mockery of the interview
| process/interviewer then perhaps that is not a good idea if you
| actually want the job.
| krior wrote:
| Maybe its a cultural difference, but I fail to see how this
| solution is "mockery".
| ocular-rockular wrote:
| But the interview process _is_ a mockery.
| constantcrying wrote:
| The interview deserves to be mocked. It wasn't someone being
| asked a few trivial questions, but 45 minutes of being asked to
| go through ridiculous hoops.
|
| If you are concerned about a candidates team skills. _Talk_ to
| them, do not interpret it based on, how they engage with some
| stupid coding puzzles.
| haspok wrote:
| > ...the first time in life I spoke english.
|
| Well, there you go. Typescript can only get you so far. Unless
| you want to be a low-paid code monkey, time to learn natural
| languages.
|
| ps. I have many Spanish colleagues, and I have a hard time
| understanding them in general (when they speak English). Only one
| other nation is worse, the French...
| kaoD wrote:
| > I have many Spanish colleagues, and I have a hard time
| understanding them in general.
|
| As a Spaniard I'm curious, why's this?
|
| I think I'm pretty well understood (worked remote for US and NL
| for years) but maybe just in case I can make life easier for my
| interlocutors.
| haspok wrote:
| It may not help that there are more of them, and of course,
| among themselves they speak Spanish. One of them then turns
| to me and asks something switching to English, he keeps his
| speech mostly unchanged (speed, enunciation, pronounciation),
| except he is putting supposedly English words one after the
| other...
| tgv wrote:
| The Spanish accent in English is --simply put-- atrocious.
| I've met many Spaniards, and only a few had a clear,
| understandable accent. Even academics with British or US
| post-docs may not speak clearly. Nor flight-attendants, for
| that matter (juecom odi flai tu asterda).
|
| I only know a few French, but I had a colleague who (although
| not of the French nationality) was born and raised there, and
| apparently was taught English literature through reading Les
| Hauts de Hurlevent. Yes, Wuthering Heights, in French.
| ch_123 wrote:
| If this coding test was what they used to assess the quality of
| candidates, I would say that the author of this article dodged a
| very large bullet by not getting hired.
| camel-cdr wrote:
| I've got a hard time imagining they were going for a solution
| other than you adjusting the base.
|
| That seems to be what all restrictions, especially #7, lead to
| and it is a concept everybody that understands how module works
| should understand.
|
| > 15. Hardcoding matrices is forbidden.
|
| This was definitely meant to nudge you into the direction of
| adjusting the base.
|
| The excessive number of rules was really weird, surely they
| could've just asked you to consider simpler a solution.
|
| > Asked the interviewer if it was OK to rewrite it using only
| types, she asked her partner and he told me it was but that he
| couldn't see the point of it and advised me it would not be the
| right tool for the problem given that there would be many more
| rules
|
| I suppose this might've been such a hint.
| throwaway-12341 wrote:
| I have almost 30 years of experience and I would never have
| thought of changing the base. I would have failed that part of
| the test.
|
| But I am confident that I would have been very productive in
| the type of work they actually perform in reality
| vogr wrote:
| > I've got a hard time imagining they were going for a solution
| other than you adjusting the base.
|
| I agree that this is probably what they were going for, but it
| still seems a bit ridiculous that the conversion from numbers
| to the chosen representation is not subject to the same rules
| (i.e., you can call `.toString(15)`, and this definitely uses
| numbers under the hood!). If this is allowed, then you could
| also encode your numbers as the string "{n % 3}{n % 5}" and be
| done with it. Or if they wanted a unique encoding, "{n}{n %
| 3}{n % 5}" would work too!
| xboxnolifes wrote:
| The toString wasn't used in the solution. It was used in
| creating the solution. Encoding the numbers as your given
| string exceeds the max length of an encoded character per the
| rules.
| lowbloodsugar wrote:
| The problem is that adjusting the base selects for two kinds of
| people:
|
| 1. People who have come across that trick before.
|
| 2. People who have a lightbulb moment in the 45 minutes of the
| interview.
|
| Now, given that someone has passed the test, what is the
| probability that it is because of 1 or 2? The VAST majority who
| pass the test will fall into category 1.
|
| The test manages to have both low sensitivity and low
| specificity. Well done!
|
| Most likely, the interviewers are completely unaware that the
| solution is only obvious to their uncurious minds because
| someone else told them the answer. They don't appear to have an
| understanding of where quantum-leap ideas come from, or how to
| foster them.
| kmoser wrote:
| I would have thought to create the matrix on the fly with a
| loop. Not as clever as changing the base, of course, but
| wouldn't that have been acceptable?
| shusaku wrote:
| Crazy answers to fizzbuzz is a great genre of fiction, but there
| is so much backstory here I'm half believing this really
| happened.
| hihiandrew wrote:
| Can imagine the interviewers squirming as they lose control to an
| OP candidate.
| FridgeSeal wrote:
| Dude casually whips out types and succinctly defeats half their
| puzzles is a pretty amazing mic drop moment.
|
| Hope the author finds a good job somewhere that recognises and
| appreciates their skill.
| revskill wrote:
| "Clever" alone is not enough. It's also about clarity and
| scalability. But it's a requirement for start.
| whstl wrote:
| "Clever" was a requirement.
|
| If they wanted clarity, they would allow for fucking numbers
| and modulo operator.
|
| They wanted a solution and the candidate produced one.
|
| Or did they just want to know if he knows how to program?
| Because he also did demonstrate that.
| mgaunard wrote:
| Normally, you learn during high school that when you take any
| exam, you should not reply with the best or smartest answer, but
| with the answer the teacher expects.
|
| The same applies to interviews.
| ch_123 wrote:
| If you are interviewing for a job - the "answer the teacher
| expects" can tell you a lot about the company you are
| potentially going to work for, as can the exam which you are
| given to prove your worth.
| eunos wrote:
| Job market kinda suck for employee so cant be picky I guess
| constantcrying wrote:
| Stupid questions deserve stupid answers.
| mystifyingpoi wrote:
| But that was the correct answer after all: screw the interview,
| have fun trolling the interviewers (you won't get the job
| anyway), then write a cool blog post and post it here. There is
| already someone in this thread asking for contact.
| BeFlatXIII wrote:
| Discrimination against the neurodivergent.
| martimchaves wrote:
| Cool read! I loved it when you changed the numbers to base 15, I
| thought that was a beautiful solution.
| wjholden wrote:
| Came here say the same thing, I had never thought of nor heard
| of using base 15 for digit tricks before!
| constantcrying wrote:
| What a genuinely terrible interview. Seems like a great way to
| learn absolutely nothing about the candidate.
|
| I would have walked out half way through. These types of
| questions are very telling of an organization which is extremely
| insecure in its own abilities.
|
| For anyone who is a somewhat experienced programmer it is not
| hard to tell if someone else knows what he is talking about. You
| do not need to waste 45 minutes of someone's time on whether they
| can correctly interpret and execute some joke requirements.
| ali_piccioni wrote:
| Wittgenstein's ruler in action.
| alkyon wrote:
| Failing this interview saved the candidate from working for a
| crappy company, doubling their salary isn't really worth it.
|
| Why on earth would the interviewer think that 0 is not a
| multiple of 3 and 5?
| arp242 wrote:
| It sounds like they're currently unemployed(?)
|
| But even if they weren't: going from 22k to 50k is a massive
| difference. People are willing to put up with a lot of
| bollocks for it. Dismissing that so easily is a really
| privileged attitude.
| cgriswald wrote:
| A person doesn't have to be privileged to value things
| differently than you think they should.
| alkyon wrote:
| "I could already see my salary doubling in front of my
| eyes"
|
| Where do they mention that they're unemployed now?
|
| A sufficiently strong candidate can afford to wait a litle
| bit more.
| arp242 wrote:
| They also mentioned being fired. But who knows. It's not
| that important for what I wanted to say.
| quietbritishjim wrote:
| "I could already see my salary doubling in front of my
| eyes"
|
| I thought by this they meant (half jokingly) that this
| potential employer would double the eventual offer
| because at that point they had just proved how amazing
| their skills are. Not that they would double their
| existing salary, and so it doesn't necessarily imply they
| have an existing job.
| whstl wrote:
| 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.
| skeeter2020 wrote:
| > if I was trying to be too clever and quirky...
|
| You buried your lede IMO. The interviewers had this cute game
| and when the developer didn't play by the planned rules
| (build up a monsterous collections of branching on top of a
| for loop) they were screwed. Issues:
|
| * rules revealed one by one. Spec changes and is always
| incomplete, but you never even hear about changing spec that
| your existing solution already handles.
|
| * artificially handicaping developers. This is the opposite
| you want; it's a bad smell if developers are not offloading
| to rock solid libraries and language features
|
| * punishing creativity. You're getting a great view into how
| this person works and thinks; isn't that a primary purpose of
| all interviews?
|
| * anti-lookup / matrix. Some of the most efficient solutions
| use this aprooach, or an inherient property of the desired
| state/input (data as code). This is super-common in game
| development; John Carmack would have failed this interview
| too.
| whstl wrote:
| Yeah, this was definitely a case of the interviewer looking
| for its soulmate.
|
| It is frustrating but it's not personal, it's just someone
| bad at their job.
|
| This only happened once to me: I got a feedback of "jumped
| straight into a cloud-based solution". The funny part is
| that it was a company that made tooling for cloud services.
| Naturally they went bust.
| James_K wrote:
| It's meant to be a test of creativity. You will while
| programming encounter limitations, so the interview tests
| your ability to handle that. Any limitation in the
| interview will be artificial because it's a test rather
| than an actual job.
| sgarland wrote:
| > artificially handicapping developers
|
| > punishing creativity
|
| A similar thing happened to me once in an interview. They
| said use any language, but were a TS shop. I went with
| Python, which is hardly esoteric. The interviewers were
| seemingly unaware of the breadth and depth of Python's
| stdlib, and so I demolished their questions in short order.
| I don't remember specifics, only that I used heapq for
| something, and itertools for something else.
|
| The reply afterwards was along the lines of, "while you
| clearly have a solid grasp on Python, we didn't get good
| signals from the interview."
|
| It's very much worth noting that this was for an infra
| role, DBs specifically. The most advanced algorithm I've
| ever had (and "had" is a stretch) to use is Levenshtein.
| roland35 wrote:
| It's downright disrespectful! It would make for an
| interesting game show maybe, but certainly not an interview
| BearOso wrote:
| Personally, I think it's literally unbelievable. It reads
| like fiction.
| whstl wrote:
| There's someone else in this thread who did the same
| problem 4 days ago and the story seems to match.
| ChosenEnd wrote:
| > 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.
| mark-r wrote:
| 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.
| amluto wrote:
| 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?
| sdenton4 wrote:
| Eh, this strikes me as reasonable - essentially declaring
| const inputs, working in a functional paradigm.
| thrance wrote:
| I think it's the opposite actually, Squid Game is a parody of
| this, with employers making you jump through hoops for their
| amusement so you can earn your keep.
| whstl wrote:
| Damn, you're totally right.
| TomMasz wrote:
| Designed to weed out anyone who might not follow orders. Was
| this a cult?
| James_K wrote:
| Close, it's what you might call a "job" where someone pays
| you to do what they say.
| wiseowise wrote:
| If by job you mean acting as a circus bear.
| James_K wrote:
| 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.
| cgriswald wrote:
| I wouldn't accept an employee or a boss who thought this
| was a reasonable definition of a job.
| James_K wrote:
| 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.
| cgriswald wrote:
| 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.
| James_K wrote:
| 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.
| cgriswald wrote:
| You haven't moved the goalposts back. You just used more
| words to suggest that people won't be willing to do work
| for free. That doesn't speak to whether they want to do
| the work or not. People can want to have a job but also
| want to reap some external reward from that job.
|
| But I know, you've reduced it to such a degree that you
| can't think clearly about it any other way. So, to humor
| you: I know a woman who won the lottery at a young age,
| but kept her job as a waitress for decades because she
| wanted to be a waitress. I know retirees who have started
| new careers. I know retirees who have gone back to doing
| the same work they did before. None of these people
| needed money. They all did jobs. Nevermind volunteering,
| which, while you will probably argue isn't a job, _is_
| evidence that people will work for reasons other than
| financial incentives. Please note, these people aren 't
| outliers, they're just people who even you have to
| believe are working for reasons other than money.
|
| Regardless, the fundamental problem with your argument
| besides trying to prop up a poor definition of 'job' is
| that you're conflating needing _any_ job with needing _a
| particular_ job. Lots of people are doing the job they
| want to be doing. Lots of people have other choices.
|
| > 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.
|
| We definitely do not have the same definition of 'work
| ethic' if this is what you took from my words.
| James_K wrote:
| > I know a woman who won the lottery at a young age, but
| kept her job as a waitress for decades because she wanted
| to be a waitress
|
| This is a lovely anecdote, but practically speaking most
| people do not have such enjoyable jobs. The world needs
| septic tank specialists and web developers and telephone
| sanitisers and accountants. Most of the things that need
| doing aren't all that desirable to do on their own. This
| is not to say that you can't take joy in doing them
| anyway, after all one must imagine Sisyphus happy, but
| merely that given ultimate choice, most people would not
| choose their current working arrangement. For instance
| within the field of programming, most people probably
| have something else they'd rather work on than what they
| do for living. Your millionaire waitress probably
| wouldn't want to work behind the fryer at MacDonalds.
|
| > We definitely do not have the same definition of 'work
| ethic' if this is what you took from my words.
|
| Clearly. In my view, work ethic is unrelated to enjoyment
| of your job. Someone with a good work ethic would be
| willing to do jobs that they don't enjoy, and would
| complete them at a similar standard to the work they do
| enjoy. It's easy to have a good work ethic when doing
| something you want to do; the real test of it is the
| things you don't want to do.
| cgriswald wrote:
| So, you still haven't made your case for your original
| claim. You're ignoring my argument I think because it's
| not reductive enough for you to see. And you just sent a
| paragraph about a single example among several examples
| which I specifically disclaimed as exemplary and highly
| visible as if that somehow is negated by your
| hypotheticals.
|
| You are following that up by, I guess, trying to convince
| me that I should ignore my experiences in favor of your
| reductive arguments that are based largely on definitions
| that I don't agree on in the first place.
|
| What are we even doing here?
|
| What you experience internally is not evidence of what
| "the real world" is actually like. You may very well have
| an amazing work ethic and view your jobs as strictly
| transactional (and that's irrespective of _enjoyment_
| which is reductive of the many reasons people want to do
| their jobs). Honestly, I believe that about you. But that
| internal view is far from universal regardless of work
| ethic.
|
| I understand you've convinced yourself that the UBI and
| other hypotheticals are proof but they're only proof if
| you're already subscribed to those reductive views.
| "Wants" don't work that way and if they did we'd be able
| to reduce them further and say that people _do_ want to
| do their jobs evidenced by the fact that they do them.
| James_K wrote:
| > I understand you've convinced yourself that the UBI and
| other hypotheticals are proof but they're only proof if
| you're already subscribed to those reductive views
|
| Far from reductive, my theory is fully explanatory.
| People have a certain way they would like to spend their
| time (what they want to do) then for every step you take
| away from that, you need to compensate them with
| something (usually money). Obviously in the real world
| there is the threat of starvation when you don't work, so
| factoring that in a lot of people will be forced to
| accept a lower premium for their time.
|
| > What you experience internally is not evidence of what
| "the real world"
|
| This is not an internal experience. I interact with many
| people on a daily basis. They work in many places.
| Stocking store shelves, sales, secretaries, janitors,
| etc. These people all would rather be doing something
| else, but work because they are paid. Likewise many
| people do take joy in those same jobs, but if I ask them,
| there are other things they would rather be doing. The
| issue is that those things don't pay. It is my assertion
| that almost all jobs are like this. People sacrificing
| their time and enjoyment for money, which may then bring
| them more enjoyment in the future.
|
| > people do want to do their jobs evidenced by the fact
| that they do them
|
| My point is that people don't want the job, they want the
| money the job provides. If you gave them the money, they
| would start working a different job that they like
| better. The same way I don't really want to eat healthy,
| but I do because I like being fit. If I could be lean and
| eat like a pig, I would certainly do it. People will
| often do things they don't want to in exchange for
| rewards. This is the distinction between work and
| pleasure. Things you want to do vs. things you do for the
| reward. Then there are some things which are a mix. Where
| you are moderately happy doing them and so you don't need
| as much of a reward to be convinced to take that action.
| If we're going do discuss justifying original points,
| perhaps you should address yours: "I wouldn't accept an
| employee or a boss who thought this [the exchanged of
| labour for money] was a reasonable definition of a job."
|
| Can you at least see my objection? Someone who thinks a
| job aught to be pleasurable is breaking down the boundary
| between work and pleasure. This can very easily lead to
| abuse, where someone believes they are entitled to their
| employees' work and the employees should be thankful for
| being exploited.
| JoeMattiello wrote:
| Redditor energy.
| sdenton4 wrote:
| Huh. The folks I know who work in circus are extremely
| creative, driven people, who often scrape by for years
| between gigs that pay decently. They're definitely not
| really in it for the money, though they do need to eat,
| and definitely aren't just taking orders. The ring leader
| is just another role...
|
| And as for the bear, it doesn't get paid at all...
| alok-g wrote:
| 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 slowdowns. Not once in my
| career, a debate or an issue has happened because of the type
| of problems brought in interviews.
| bluGill wrote:
| The point of fizzbuzz is to prove you can program. There are
| a few ways to solve the problem but like real world all are
| not elegant and so you have to show how you handle such
| problems. Yet you can do the whole thing in less than an hour
| while real worle problems are expected to take a week or
| more.
|
| there is no point in all the additions the article had the
| first example is enough to show you are not lieing about your
| ability and that is what matters.
| alok-g wrote:
| I agree about vanilla FizzBuzz. It's like a 'hello, world'
| of coding. My comment is about the several other rules
| brought in. I still do not see the rules added as a
| reflection of a real world problem.
|
| When I interview, I only give real world problems that can
| be solved within an interview setting. (PS: I won't
| disclose the interview problems here on open Internet.)
| macNchz wrote:
| 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 requires knowledge of an algorithm that
| researchers worked on for decades that you've either
| practiced or will stumble through deriving from first
| principles--you're writing a very simplistic function.
| sasmithjr wrote:
| 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.
| kijin wrote:
| 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.
| alok-g wrote:
| I agree about vanilla FizzBuzz. It's like a 'hello, world'
| of coding. My comment is about the several other rules
| brought in.
| xtracto wrote:
| You mean you had never had to traverse a 2D number array in
| spiral order to fix the 500 error in the site?
| quietbritishjim wrote:
| 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
| but had jobs because they were good at interviews. That's why
| FizzBuzz is not done Google-style tree inversion exercise but
| basically just "please write a for loop". I wouldn't want to
| work a company that doesn't filter those idiots out. A full
| blown exercise with real code would be fine but a toy
| exercise would also totally do.
|
| [1] Imran Ghory. He wrote a blog post about it but it now
| seems to be down, but I know it was him and the reason why he
| did it because I was working with him at Bloomberg when he
| came up with it.
| whstl wrote:
| 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.
| mark-r wrote:
| 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.
| eieio wrote:
| I was really curious reading this. Many years ago I read
| this blog post (from 2007!) by Jeff Atwood[1] that
| mentioned FizzBuzz, and I guess I had mentally filed away
| that Jeff Atwood invented FizzBuzz! But that is not true.
|
| Jeff's blog mentions Imran. Jeff's blog is still up, but
| Imran's isn't! However it is up on the internet archive,
| and Imran's post is also from 2007[2].
|
| My sense is that Imran wrote a blog in January 2007
| mentioning FizzBuzz and that Jeff's post in February 2007
| is what made FizzBuzz the meme that it is today. This is
| probably very obvious to some readers of HN, but Jeff's
| blog (Coding Horror) has been around for a very long time
| and was one of the 'big' tech blogs back in that era of
| blogging (Jeff went on to, among other things, cofound
| Stack Overflow with Joel Spolsky a year after writing
| about FizzBuzz).
|
| Thanks for asking this - if someone asked me yesterday
| "who invented FizzBuzz?" I would have pretty confidently
| said "Jeff Atwood!" and I would have been totally wrong.
|
| For completenesses sake, the other really influential
| interview question blog I remember from this era is Steve
| Yegge's "five essential phone screen questions," which is
| even earlier (2005!)[3]
|
| I think interviewing discourse on message boards is
| tricky; folks have strong opinions, and if someone says
| "this is an essential question" and the question is hard
| for you, it's hard not to take that personally. In a past
| life I thought a lot about interviewing (here is a
| resource on interviewing I helped create for Jane Street
| back when I worked there[4]). I have never asked a
| FizzBuzz-style question, but I do think that "explicitly
| telling the candidate what you want and give them lots of
| help to get there" is really important.
|
| [1] https://blog.codinghorror.com/why-cant-programmers-
| program/
|
| [2] https://web.archive.org/web/20080405225407/http://imr
| anontec...
|
| [3] https://sites.google.com/site/steveyegge2/five-
| essential-pho...
|
| [4] https://www.youtube.com/watch?v=V8DGdPkBBxg
| mark-r wrote:
| Thanks for digging that up! I'm quite sure that Jeff
| Atwood's blog is where I first heard about Fizzbuzz, but
| it never occurred to me that he had attributions.
| quietbritishjim wrote:
| Thanks for digging out those links. I think Imran came up
| with it in 2006 or 2007, he was certainly experimenting
| with interview questions around that time, so the blog
| post was not long after. I had no idea at the time he had
| a blog and didn't see the post myself until a few years
| after that. In fact, I think I saw Jeff Atwood's first!
| xeromal wrote:
| I had a set of interviews at a relatively large tech company
| and I was pretty pleased with the process.
|
| 1 tech interview which was progressively implementing a
| banking system. Final question involved threading
|
| 1 tech interview which involved building a banking system but
| it was more systems and database design.
|
| 1 business logic interview which was breaking down how credit
| card numbers worked and then asking me to do a code review
|
| 1 was just a personal fit interview.
|
| It took a lot of time but it all felt realistic and useful in
| the context of hiring someone.
| jancsika wrote:
| > Seems like a great way to learn absolutely nothing about the
| candidate.
|
| They learned that as the spec became more complicated and
| twisted, his code got more and more clever.
|
| I guarantee that there were other candidates whose code got
| simplified and more commented as the spec grew.
|
| They even gave both a general hint:
|
| > An example of this was that a 50 lines solution with a line
| of 110 characters would be considered.
|
| ... and a custom-tailored hint directly to the candidate:
|
| > Asked the interviewer if it was OK to rewrite it using only
| types, she asked her partner and he told me it was but that he
| couldn't see the point of it and advised me it would not be the
| right tool for the problem given that there would be many more
| rules.
|
| Be honest: if you were dealing with a monstrously complicated
| spec would you rather read straightforward code with comments
| like, "Have to special case -0 here, ugh" or see two lines that
| inexplicably make everything into base 15?
| lcnPylGDnU4H9OF wrote:
| > Be honest: if you were dealing with a monstrously
| complicated spec would you rather read straightforward code
| with comments like, "Have to special case -0 here, ugh" or
| see two lines that inexplicably make everything into base 15?
|
| _Unquestionably_ the latter. Especially if its behavior
| matched the spec flawlessly. Doubly so if I can demonstrably
| break it by modifying /removing those two lines.
|
| I'm not totally sure why that's controversial; of course, I
| understand that I might inherit this nonsense without the
| author around to explain themself but it sounds _fun_ to be
| faced with that.
| williamdclt wrote:
| Depends on the requirements. If they're a complex tangle of
| special cases and heuristics, I want the code as imperative
| or low level as possible so that I can tweak the fine details
| with precision. If they're clearly set rules, I want the code
| as declarative or high level as possible (even if it becomes
| a strange DSL) so that I have confidence it matches the
| rules,that it enforces invariants and that adding new rules
| won't introduce edge cases in existing ones
| Waterluvian wrote:
| Absolutely.
|
| "What's the difference between call and apply in JavaScript?"
|
| "Ah well I can never remember which is which, but they both
| invoke a function with arguments but accept the arguments
| differently, whether an array or spread." When you reach for it
| you really want to be asking if you should be using bind
| instead, especially because of the massive gotcha of how
| JavaScript does binding, but with ES6 arrow functions they're
| often the best option to wrap a function call."
|
| "Candidate did not know the difference between call and apply"
| stickfigure wrote:
| I argue the contrary case - the interview style is pretty
| reasonable, but the interviewers screwed up the process (and
| ultimately, the grading).
|
| "Adding additional requirements which test a candidate's
| ability to refactor code" is a pretty good exercise. And it's
| ok to force candidates people down a specific development path.
| The problem is that the interviewers didn't do this. They let
| the candidate pick a strategy the interviewers weren't
| expecting, then were disappointed with the results.
|
| Actually we have no idea why the interviewers rejected the
| candidate. Maybe they were just as impressed with the solution
| as I am. Maybe the candidate presented poorly in other ways.
| Maybe they agonized over hiring this candidate vs someone else
| who was even more amazing, and could only afford one.
|
| Ghosting the candidate is pretty inexcusable. But maybe it was
| just old fashioned corporate dysfunction and someone dropped
| the ball.
|
| _You do not need to waste 45 minutes of someone 's time on
| whether they can correctly interpret and execute some joke
| requirements_ -- this is absolutely not the case. I interview a
| lot of people and most are bad programmers, despite having
| impressive resumes. 45 minutes of a progressively difficult
| programming exercise is a minimum.
|
| --
|
| All that said, there are red flags that make me question the
| veracity of the whole thing:
|
| * Author claims to speak English very poorly, but writes
| incredibly well! Maybe they leaned on LLMs, but this seems
| pretty good even for an LLM.
|
| * Author says they have 2 years of work experience in a company
| that doesn't use Typescript, but then proceeds to create a
| solution ad-hoc that requires incredibly deep knowledge of the
| type system. Certainly not impossible, but I don't know anyone
| that could pull this off.
|
| * Author doesn't have a name. There's no contact information. I
| don't even know if I should write "he" or "she". Here's a viral
| calling card that would almost guarantee countless interviews
| (including from my company!) and they aren't capitalizing on
| it.
|
| * There's nothing else on this domain, no link to a CV,
| nothing. It's a ghost.
|
| The story is too good. I'm defaulting to skepticism.
| erikerikson wrote:
| I would have led with your skepticism.
|
| This story reads like concept art poking at our empathy to
| send us through an emotional journey.
|
| I know my reading journey took me through the sadnesses of so
| many of the interviews in my life and the dysfunction that
| gets pushed in our industry. I have wondered whether this is
| part of psychological positioning and pre-negotiation or
| simply emotional, psychological, or/and organizational
| ineptitude.
| fhars wrote:
| The concept art version is this one
| https://aphyr.com/posts/342-typing-the-technical-interview
| erikerikson wrote:
| I don't think any art has only one form or rendering.
| Certainly not one subject. That said, I am familiar. That
| one evokes awe and mysticism whereas this one seems more
| grounded in life and more relatable.
| shiomiru wrote:
| > * Author claims to speak English very poorly, but writes
| incredibly well! Maybe they leaned on LLMs, but this seems
| pretty good even for an LLM.
|
| The author claims their _pronunciation_ is poor. Writing is a
| completely different skill. (Especially in English with its
| insane spelling rules.)
|
| > * Author says they have 2 years of work experience in a
| company that doesn't use Typescript, but then proceeds to
| create a solution ad-hoc that requires incredibly deep
| knowledge of the type system. Certainly not impossible, but I
| don't know anyone that could pull this off.
|
| Self-study?
| stickfigure wrote:
| Each factor alone is within the realm of _possible_ but
| unlikely. The combination multiplies my skepticism
| exponentially.
|
| It could be genuine, but I would bet against it.
| essnine wrote:
| Looking up the domain shows that OP's write-up was posted on
| reddit by a similarly named account with relatively little
| activity, but history going back a good 8 years. Sometimes
| people just haven't gotten around to setting up a full
| website with a portfolio, which is fine.
| flimsypremise wrote:
| Been interviewing for over a decade. Tests like this do not
| really tell you whether someone is a good programmer, they
| tell you whether a person has spent a lot of time practicing
| problems like this. The only way to tell if someone is good
| at the job is to have a conversation with them and pay
| attention to how they answer your questions. Ask your
| candidate their opinions on API interface design or whether
| they favor mono-repos. A good candidate will be able to speak
| legibly and at length about these things. The problem is that
| in order to judge those responses you also have to be very
| knowledgeable. So instead we have stupid little tests
| designed to let interviewers of varying ability screen
| candidates.
| sideshowb wrote:
| to correctly judge some fizzbuzz solutions (or approaches
| to refactoring) you would also have to be knowledgeable.
| Guess what I think the problem is.
| stickfigure wrote:
| I've been interviewing people for more than twice that
| long. I started with the conversational approach, and it
| worked poorly. There are too many people that are good at
| talking about technology but bad at actually doing.
|
| My mature interview style is a pair programming session on
| a specific exercise (the same for everyone). It's inspired
| by the "RPI" (Rob's Pairing Interview) from Pivotal (well,
| Pivotal of old days). There are no gotchas to it, it's not
| hard. But it's definitely programming. Because that's what
| I'm hiring for. Not talking.
| beefnugs wrote:
| The entire software interviewing mindset is horrible: the
| interviewee has no idea at any given time if the interviewer is
| actually looking for : versatility, years of experience in one
| particular language, generality, experience in their EXACT
| stack, the ability to follow exact dumb/arbitrary
| rules/procedures, social tolerance to managers making dumb and
| arbitrary decisions, will you spill the beans about your
| previous employers illegal and dumb acts, do you know about our
| exact industry, does it seem like we can exploit you for as
| long as possible with minimal raises, do you follow the same
| esoteric "clean code" rules we have chosen all of our previous
| hires for, or any other random thing that they will never
| articulate to you.
|
| While good employees are always just thinking: cool i will try
| something smart to make them think i am smart, or ok i will
| follow these dumb exact things to make sure they know i am
| obedient, jesus christ why cant i just play a video of me doing
| this from last week, i guess i better try it a different way
| since that way didnt get me hired, i guess i need to dance this
| angle to the moon this time...
|
| At least AI will stop all of this nonsense
| teddyh wrote:
| The author seems to constantly conflate "not failing the
| interview" with "having the program produce correct output
| according to the rules". But it was an inverview, not a logic
| puzzle.
| ahoka wrote:
| I think the best "debugging" skill is to think about the problem
| first and choose a solution that makes the corner cases
| impossible. Dijkstra smiles on you!
| grujicd wrote:
| Some of these rules look like straight from Severance TV show.
| This would be a huge red flag for me.
| raverbashing wrote:
| I'm getting peeved by interviews that asks for tests (especially
| take home tests)
|
| The main issue that I see is that interviewers get extra picky
| with all the minor details and they fail candidates due to minor
| issues that would get solved in a code review or just with a bit
| more time
|
| And while fizzbuzz using strings only is cool, it seems it didn't
| add anything to the predictive power of the interview
| kbr- wrote:
| > The main issue that I see is that interviewers get extra
| picky with all the minor details and they fail candidates due
| to minor issues that would get solved in a code review or just
| with a bit more time
|
| You see a "minor issue that would get solved in a code review".
|
| I see a production outage.
|
| You cannot rely on others catching and fixing your bugs. It
| happens, but it's all about probabilities. You want to reduce
| the probability that something bad will happen. That means not
| just relying on more senior people to catch problems in your
| code, it also means relying on you to be careful.
| mariomash wrote:
| You have the coding and reasoning part perfect (but maybe not
| straightforward to understand) and you also know the things you
| are missing. - University degree: not necessary, get
| certifications or equivalent experience (upwork)? - English: this
| part is really important. find or hire a native speaker and start
| practicing. - AWS/GCP/anything else... get certifications or free
| courses.
|
| My only complaint about your code: in a company you probably want
| them to approve your PRs, sometimes your peers will code worse
| than you, so better if the code is less stilted and maybe
| objectively "worse", but easy to understand at a glance. but that
| part also depends on the interviewer.... better to ask first,
| it's part of working in a team.
|
| I'm sure you'll soon be hired for 50k+.
|
| Suerte.
| isaacremuant wrote:
| I'd say get hired at any role that pays what you want for your
| seniority and simply work and learn.
|
| Courses won't matter that much if you don't implement something
| (might give you a point or two on an interview but don't
| overinvest) and upwork would be absolutely exploitative work
| and you probably would not gain as much as working with others
| who can share a thing or two. Having a shared codebase is
| critical for growing as a software developer and not being too
| clever.
|
| OP should just work and learn. Bring his enthusiasm but also
| humbleness and grow. He can keep his options open and move
| companies rapidly if he is already there but getting stable
| work and improving his communication should probably be his
| first goals to achieve.
| rho4 wrote:
| The 30-lines rule annoyed me the most.
|
| Don't force 'clever' solutions if you're looking for readability,
| maintainability, changeability, debuggability etc.
|
| On the other hand, our company doesn't do any technical
| interviews at all, so there's that.
| James_K wrote:
| As a programmer, your goal should always be to produce the most
| readable possible code. Just because you can't produce
| something perfect doesn't mean that you should give up on
| readability entirely.
| forgotpwd16 wrote:
| Code looks simultaneously impressive, elegant, and monstrous. Are
| such snippets found in TS codebases? Would like to see how it
| compares to a more conventional approach. Still, cool code. (Even
| if weren't hired.)
| pas wrote:
| https://hasura.io/blog/how-typescript-template-literal-types...
|
| Access to template literals at type-level is available since TS
| 4.1.
|
| https://github.com/ghoullier/awesome-template-literal-types
| rokkamokka wrote:
| Interestingly, unlike many in this thread I would've avoided
| hiring this person based only on the code example.
|
| This code is almost unreadable to me, certainly to most on my
| team. I would request changes it if it was a PR going into
| production (ignoring that the problem itself is made up). The
| code I would've liked to see would be easy to read, easy to
| follow, and would make me understand the underlying rules that
| made the code look like it is. This, I feel, achieves none of
| that.
|
| But of course, everyone is different, and certainly many in this
| thread feel different. I just wanted to add my perspective :)
| lou1306 wrote:
| The code being hard to read may be partly a consequence of
| having to bend over backwards to fulfill the absurd
| requirements.
|
| No numerical operations on a fizzbuzz problem? Give me a damn
| break.
| mcherm wrote:
| If the requirements of the exercise had been "write FizzBuzz"
| then I would agree: doing weird tricks like this rather than
| writing straightforward code is a red flag.
|
| But the requirements were "write FizzBuzz in ANY language. Then
| change it so it doesn't use use numbers (!!!). Stick to strict
| and unreasonable code length constraints."
|
| The only POSSIBLE interpretation is that the interviewers don't
| WANT straightforward readable code, but want weird tricks
| instead. Which is exactly what the author gave them.
| wakawaka28 wrote:
| The interviewers clearly expected the candidate to give up on
| his weird solution early. They should have just said, "Do it
| another way, we don't like this." But they let him dig his
| own grave instead. This solution is impractical in many
| cases, and fundamentally difficult to debug. They said many
| things that suggested that they wanted "easy to extend" and
| that implies "easy to debug." I don't really have much
| sympathy for the candidate. The whole story could also be
| fake, and certainly sounds like the kind of thing someone
| would make up to post a clever solution to HN that in truth
| took days or weeks to come up with.
| sgarland wrote:
| It seemed like it was actually trivially easy to extend.
| I'm not saying it's an optimal solution in general, but
| given the absurd requirements, I think it was well done.
| TheOtherHobbes wrote:
| Of course. The "I can't see how this works so FAIL" comments
| are missing the point.
|
| This person aced some ridiculous requirements. The odds are
| good they're capable of writing simple, clear, non-clever
| code when asked to.
|
| If the job requires simple, clear, non-clever code don't ask
| for FizzBuzz that can't use numerics.
| James_K wrote:
| Why is that your takeaway? The test isn't just "write a
| fizzbuzz", it's "write a fizzbuzz better than all the other
| candidates". Suppose one candidate produces straightforward
| readable code within those restrictions and the other
| doesn't, which would you hire? This guy chose deliberately to
| write an unreadable solution that is highly impractical
| against the advice of the interviewer.
| pas wrote:
| This is supposedly a NodeJS / NestJS / backend position. If
| they seem like a good team fit then I would hire someone
| this good with TS types in a heartbeat.
|
| Especially that this is a small company, so if I'm some
| kind of mid-level decision maker there then having someone
| versatile is a big advantage for this company.
|
| If this would be a huge boring enterprise recruiting for
| the maintenance of their legacy COBOL.TS backend? Then
| probably the orthodox candidate.
| James_K wrote:
| I don't think you'd really like to see any code like that
| in production. The point of an interview is to
| demonstrate your talents as they relate to the job. While
| fiddling with types is fun, it is not really relevant and
| is the exact opposite of what you should be doing in a
| real codebase. The person in this interview chose to do
| something silly to show off. They could have demonstrated
| their actual TS knowledge but instead they chose to write
| something totally unreadable after the interviewer asked
| them not to once, then made a specific rule which is
| basically telling them to drop the silly type stuff and
| just write normal code. If you really wanted the job,
| would you behave like that in the interview?
| spuz wrote:
| I admit, I don't understand how it works. But there are ways of
| making code understandable that doesn't require rewriting it.
| Let's assume that creating custom types is the perfect solution
| to the given problem, you can help your fellow devs to
| understand it with comments, tests, documentation or even
| presentations. If I wrote code that was this obscure in an
| interview I'd be sure to mention that in a real scenario I'd
| provide links to this supporting documentation along with the
| code.
| whstl wrote:
| The requirement says "Numeric types, number literals and their
| associated methods and operations are forbidden".
|
| There is almost zero chance that a passable FizzBuzz would be
| produced in those interviews.
| jajko wrote:
| I have to agree. When I was junior decades ago, I saw all those
| cool one liners as some sort of holy grail and had huge respect
| for the authors, like we had 10KM HDDs so every char counts.
|
| Then I realized how hard they are to debug once codebase looks
| like this, and any serious production code will get debugged to
| hell, no doubt there. Also implementing changes require same
| mindset, which is rare in teams generally, so its basically a
| technical debt right in creation.
|
| KISS, the most important principle in any form of engineering
| is exact opposite of this. I've seen and experienced great
| success with it. I haven't seen that much success when ignored,
| apart from one man / tiny homogeneous team show.
| lproven wrote:
| I admire terse code too. I can relate. I'm also old.
|
| But:
|
| > we had 10KM HDDs so every char counts.
|
| Ten kilometre hard disk drives?
|
| It can't be 10kB. Hard disks were never that small. Floppy
| disks were never that small.
|
| Maybe it's not hard disk drives.
|
| It can't be length of tape, or of mercury delay lines.
|
| I am mystified.
| lproven wrote:
| _thinks more_
|
| 2 characters wrong? 10 MB hard disks?
| jajko wrote:
| I was just joking, sorry not a native english speaker.
|
| What I meant was that disk space with code text was never
| an issue on modern PC, so optimizing for that doesn't make
| sense.
| MrDresden wrote:
| Honestly, reading these coding golf rules gives off the sense
| that they were written by a either very inexperienced or insecure
| individual. These are not a good way to measure a candidates
| abilities.
|
| As has already been mentioned in other comments, these are
| clearly red flags and grounds for not taking the application
| process further.
| moffkalast wrote:
| > Changing the programming language after starting was also
| forbidden.
|
| > Max of 30 lines.
|
| > Max width of 100 characters.
|
| Putting arbitrary rules where none are really required is
| actually quite informative. It shows how the company culture is
| set up and it's probably gonna be lots of long days working on
| things that make no sense because some manager is power tripping
| over pointless arbitrary decisions. You must be truly desperate
| to come to them for work.
| yujzgzc wrote:
| It's not that the candidate is underqualified, it's that they
| demonstrated more hacking skill than programming skill in that
| interview. I feel like the rules about program length were
| mistaken for coding golf rules?
|
| A small company hiring a programmer isn't looking for super
| clever type system hacks, they're looking for someone to crank
| out code to solve problems fast. It's not readable or efficient
| to use the type checking system as a general purpose computation
| system. If this is the code that your teammate wrote and now you
| have to debug it, good luck...
|
| The candidate is certainly smarter than the average code monkey,
| just not "housebroken". Once they've worked at a team where they
| mostly get to fix and improve long-gone coworkers' code all day
| is when they gain more of an understanding of what programming is
| about...
| whstl wrote:
| The rules of this FizzBuzz say that you can't even use numbers
| and numeric operations.
|
| They WERE expecting a clever solution.
| zogomoox wrote:
| From your description I think you accidentally applied for a
| position in an administrative sub-branch of Hell. This was the
| giveaway: "I had a little discussion with the interviewer, who
| said 0 was not a multiple of 3 and 5".
| wbxp99 wrote:
| Your solution seemed very smart, and I have no doubt that you are
| an excellent programmer. However, I think you way over-
| complicated things by choosing to go the functional route. Here
| is my go in imperative Python. The base-15 trick is still needed,
| but the rest of it seems a lot easier to understand for someone
| reading the code later.
|
| https://pastebin.com/trD9Ezf1
| guccihat wrote:
| 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.
| bhaney wrote:
| > ...readability or maintainability. And these were the only
| two stated core requirements.
|
| Where was that stated? I don't see those being mentioned as
| core requirements at all
| guccihat wrote:
| It was the whole point of the exercise if I read the article
| correct
|
| "While the base algorithm is very simple, the point of the
| exercise is that the interviewer will add new rules to test
| how you update the code while keeping it readable and
| maintainable."
| bhaney wrote:
| Good point. I don't know why that stood out to me so much
| less than "the interviewer noted that I could even use
| esoteric programming languages" which to me is code for "go
| nuts and do stupid fun stuff like writing your whole
| solution in APL for the extra challenge of it" or other
| flashy passion-having-shibboleths, which are usually
| incompatible with readability or maintainability.
| spacechild1 wrote:
| Keep in mind that they came up with this solution after the
| interviewers forbid the use of numeric types and math while
| still keeping a limit of 30 lines. What do you expect? I found
| the solution impressive given the circumstances. At this point
| I would have thrown the towel.
| guccihat wrote:
| I think the interviewers were looking for the key insight
| that a number is divisible by 3 iff the sum of the individual
| digits is divisible by 3. That is easy to verify, even
| constrained to using single digit data types. To be clear, I
| am not saying this was a great interview question and I agree
| the solution OP came up with is impressive.
| cornstalks wrote:
| > _a number is divisible by 3 iff the sum of the individual
| digits is divisible by 3_
|
| And how do easily verify this divisibility when "Numeric
| types, number literals and their associated methods and
| operations are forbidden?"
| guccihat wrote:
| 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 everything in
| string representation.
|
| "The programmer can use whatever representation they see
| fit with the only restriction being that it could only
| contain letters, numbers and symbols that could be typed
| with a single stroke"
| drewhk wrote:
| You clearly did not read the article...
| zaruvi wrote:
| I would have failed this question badly. I'm curious, how
| would you check that without access to any number or math
| operations? I think I would try something similar to what
| he did with his sum_table, but that too was disallowed.
| They're constraints I've never had to deal with, nor seen
| before.
| joshribakoff wrote:
| Math operators like division aren't native to your
| (traditional) cpu, they are implemented in code, for
| example using similar algorithms as the ones taught to us
| in grade school to multiply big numbers one digit at a
| time on paper and "long division".
|
| All math operations can be implemented with bitwise
| operators, too, i am pretty sure
|
| Likely the interviewer specifically needed the candidate
| to do that, implement the math, and tried to steer them
| that way numerous times (no sum table, dont use the type
| system, no math operators). Thats likely also why they
| suggest allowing limited use of Google, because they
| realize many people will need a refresher on bitwise
| operations. But they don't want to outright tell you what
| to search for, they needed to see some resourcefulness.
| When they suggested OP was cheating they likely didn't
| mean it personally and actually wanted to help steer OP
| towards an acceptable solution. Rather than saying it's
| cheating they could have said it avoids the main thing we
| need to see, or outright say "please implement the low
| level math from first principles"
|
| In my opinion the candidate showed resourcefulness in
| their own way indeed, but sometimes its not even up to
| the person administering an interview for example if they
| have been given a rubric.
| ozim wrote:
| Getting clever with type systems is exactly why everyone hates
| Java and OOP.
|
| Fizz buzz is also much better treated like data stream and
| applying reactive programming.
| catlifeonmars wrote:
| Fizz buzz is a toy problem. I think it's a mistake to read
| too much into anything but basic programming skills while
| using it as an interview question. If you want to test code
| quality and maintainability you are much better off with a
| more realistic problem.
| ozim wrote:
| Making convoluted solution by solving the problem with type
| system is showing that OP doesn't have basic programming
| skills.
|
| Basic programming skill is also picking right tool for the
| job.
|
| What he did was worst approach possible.
| catlifeonmars wrote:
| On the contrary, it shows that the OP has a very good
| understanding of the type system. Plus, it's an
| understandable approach given the code golf nature in
| which the original problem was presented. (Line length
| and character limits screams "code golf" to me)
|
| I give lots of interviews and I try very hard to resolve
| ambiguity in the expectations and requirements. Up front
| I explain what the purpose of the interview is and what I
| intend to evaluate. It's silly to assume everyone is
| equally able to read between the lines and coding
| interviews are already a very poor approximation of what
| a day to day software engineering job looks like, so I
| try my best to set expectations up front.
| ozim wrote:
| But it shows OP is "one trick pony" and interviewer told
| him it will not be proper approach but then he still went
| with it.
|
| We also had some freelancers like that and one employee
| who lasted 3 months - and always it was company owners
| who wanted to "bring help to speed things up".
|
| Those guys ignored everything and did code the way they
| knew how to do it. Results were always bad and 3 months
| guy instead of speeding anything up trashed all team
| productivity for those 3 months and I guess even 2 more
| when we had to do the cleanup of his worst inventions.
| catlifeonmars wrote:
| Two tricks. OP switched from programming to meta
| programming halfway through.
|
| Also the reason given (not the right tool for the
| problem) was demonstrably false if we take the OP at face
| value. They solved it and their solution was robust to
| changing requirements.
|
| We only know the OPs side of the story, but if we take it
| at face value it reads a lot like the interviewer wanted
| to jump them through hoops and they made the best of it.
| I would have politely declined the interview pretty early
| on if I was in their shoes.
| arp242 wrote:
| 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
| cognitive overhead?
| whstl wrote:
| Honestly? It REALLY is.
|
| This kind of typing in TS is used mostly for getting
| dynamically typed Javascript codebases under control.
|
| I did this once for a state management library that was
| considered "impossible to add types to" by the authors
| themselves, and thanks to this I found several bugs in the
| library itself, and in our own codebase, due to subtle
| incorrect usage.
|
| Just the fact that we got autocompletion across the whole app
| was worth the effort. Even the engineer that was against it
| ended up praising it.
|
| I'm not the kind of person to say this but: maybe some things
| are not for everyone. Some people just have different
| interests and skills. Complicated things aren't less worth
| just because someone in the team can't understand them.
| kiviuq wrote:
| I thought domain modelling through types is considered
| standard in functional programming?
|
| (see for example Scott Wlaschin)
| wrs wrote:
| 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!
| catlifeonmars wrote:
| > And even if you are a TS-wizard with a Ph.D. in typing: is
| it really worth all the cognitive overhead?
|
| Yes, but only on the weekends :)
| hnthrow90348765 wrote:
| >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.
|
| If that's their code base, they shouldn't be asking these kinds
| of questions. They'd be better served by asking to debug a non-
| functioning component that looks like a real component you'd
| find in their code base.
|
| Plus readability and maintainability are subjective
| tmtvl wrote:
| I know it's bad form to complain about technical issues with the
| site rather than engaging with its content, but I can't do the
| latter as I get redirected to a page telling me to activate
| javascript... even after activating js. Considering I expect the
| page itself to just be static text I'd appreciate if anyone could
| give a quick summary. Even the Wayback Machine can't show the
| page, for crying out loud.
| st_goliath wrote:
| > I get redirected to a page telling me to activate
| javascript...
|
| ...which is hosted on a different domain (notion.so), so if you
| didn't notice and temporarily allow _that_ domain in NoScript,
| the actual page (hosted on kranga.notion.site) will _still_
| redirect you to the "Please Enable JavaScript" text on
| notion.so
| andyjohnson0 wrote:
| I've been doing interviews and coding tests recently, but this
| beats anything I've seen in terms of awfulness. To me, the only
| thing worse than being tested on your ability to write clever
| code would be to end-up working in an organisation where everyone
| had been selected on their ability to write clever code.
|
| I can't make up my mind whether these interviewers are simply
| staggeringly unaware, or gatekeeping, or that they enjoy making
| people suffer. The latter because, for every candidate like the
| author, there will be multiple candidates for whom this kind of
| test leaves them frozen and anxious. I wish people involved in
| interviewing would think more about what they're doing.
| darkwater wrote:
| 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 warning about mixing Terraform and non-Terraform managed
| infra because it can lead to unforeseen issues, especially if
| there are less visible dependencies between the 2. I then
| mentioned anyway it could be done with Python + boto3, with AWS
| CLI + bash, with Pulumi, with CDK and then after some extra talk,
| also with Ansible.
|
| They didn't want a long answer with lessons learned in real prod,
| they wanted a oneliner answer: Ansible. They told me then to be
| shorter in next answers and proceeded to ask like 30 questions in
| a row involving bash, Linux, Terraform and Kubernetes knowledge,
| to which I answered all correctly (and with the one-liner
| answer).
|
| The result: discarded, because I chaotically answered to that
| first question. Although I was somehow offended because I don't
| like to be discarded, I think I dodged a bullet in this case.
| bhaney wrote:
| > Although I was somehow offended
|
| No somehow to it, that's just offensive.
| darkwater wrote:
| Yeah, indeed. I gave my feedback to the TA that was managing
| the position, although with little hope it would be of any
| use.
| thebruce87m wrote:
| I'm no master of English, but I think "somewhat" is more
| commonly used here rather than "somehow".
|
| Edit: I'm no master of replying to the correct person either.
| em-bee wrote:
| are you sure it was the answer for the first question? i went
| through a fast paced interview recently. i was told that it
| would be fast paced and the interviewer did cut me off when i
| gave an answer like that for a different question, but i can't
| imagine that that would be the reason to reject me. (i didn't
| know all the answers so it was fair in my case)
| darkwater wrote:
| 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 the story, they probably have another
| version, but still I think I dodged a bullet.
| em-bee wrote:
| 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.
| whstl wrote:
| 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.
| pas wrote:
| Maybe there's something in the air recently? Last year I had a
| similar experience. Senior Infrawhatever position, "take home
| assignment" manipulating the firewall on a standard Linux box,
| in the rejection mail I got negative points for having
| permissions checks, and my solution being too complicated for
| supporting both iptables and nftables, and so on.
|
| -\\_(tsu)_/-
| wrs wrote:
| Yes, it's nice to get paid, but I probably wouldn't enjoy
| working with people who think Ansible and Terraform are
| interchangeable.
| nrr wrote:
| I've had a lot of experiences like this, and I wound up ducking
| out of the industry entirely in 2021 after having had my
| skillset reduced to dogmatic use of the infrastructure buzzword
| of the day.
| jonathanlydall wrote:
| From a lot of the comments it feels like many people don't seem
| to understand what the interviewers were looking for.
|
| To be clear upfront, it wasn't simply getting the right answer
| spat out by the candidate's solution.
|
| At one level they were trying to asses that you did in fact know
| how to write code, but since they're assuming most of their
| candidates can write code, they were also checking to see what
| you would do when presented with evolving requirements and
| constraints.
|
| If I were the interviewers (considering candidates are more
| stressed than they would normally be on a job), I wouldn't
| necessarily require the candidates got all the requirements met
| as long as they were clearly on the right track and able to
| explain what they were doing.
|
| Although the technical assessment was contrived (which is okay in
| an interview), it was absolutely not a "leet code" style problem,
| but instead super approachable and easy to understand. It doesn't
| seem they were doing anything to "try catch people out" so as to
| disqualify them, but made it interesting enough that they could
| hopefully get a bit of insight into how the candidate tends to
| think and behave.
|
| I do think the interviewers were silly to entertain the
| candidate's approach for as long as they did, after it was clear
| that it was very impressive, even if highly impractical for the
| actual task at hand (which was to show the interviewers your
| typical day-to-day approach to coding tasks), they should have
| said very clearly to the candidate "your solution is very
| impressive and clever, but as we're trying to gain insight on
| your approach to typical day-to-day coding, please change your
| approach such that we're able to do so". And they kind of did say
| something similar, which the candidate essentially ignored to...
| outsmart them?
|
| If you ask me, the candidate is very skilled and intelligent, but
| at the same time not very smart in terms of understanding what
| other people actually "need".
|
| Most properly experienced software developers have learnt that
| often what customers "ask for" isn't actually what they need,
| very often you give them what they asked for and when they
| actually see it in action, they realize it won't actually do
| what's needed and then iteration happens.
|
| The candidate in this case gave the interviewers what they asked
| for, but not what the interviewers needed from them.
|
| The hard parts of software development is almost always not about
| building something that technically works, but rather working out
| what's actually needed.
|
| My message to the candidate is, you seem very technically
| talented, but you don't seem to understand very well about how
| the world and most people in it tend to "work".
| Dansvidania wrote:
| I found the solution quite impressive, but I think it is the
| typical junior developer mistake of getting too smart with
| their code.
|
| As an interviewer who is going to have to work with the
| candidate in case they get hired, I would worry that this kind
| of code would be what I'd need to review on a daily basis.
|
| The requirements were weird, but when are they ever not? and
| read-ability and maintain-ability were clearly stated as
| priorities at the start..
|
| Still, props for the cleverness.
| codingdave wrote:
| I wish I could have seen the code at each step instead of just,
| "That was easy." Because he seems to have focused on the
| functionality of the code, not on the clear message that their
| goal is to see how robust, reliable, and readable you can make
| your code. I don't think this interview was actually about the
| code, it was about long-term maintenance and risk avoidance.
|
| So while I am not saying I love this interview method, and other
| comments are correct that weird tricks seem to be required... I
| still think the interview served its purpose. OP is not a good
| match for this company. No judgment implied there - this is the
| purpose of interviews: for both sides to see if they work well
| together. In this case, they do not.
| grajaganDev wrote:
| Would any developer be a good match for that company?
|
| My judgment is that this company has no idea of what they are
| doing. Not uncommon for companies with under 50 employees.
| wakawaka28 wrote:
| They know exactly what they're doing. The code, while clever,
| is bad for understandability, extensibility, and
| debuggability. They tried throughout the interview to get the
| candidate to do something else, and he ignored all advice and
| hints. If this even happened at all. It sounds like a "just
| so" work of fiction.
| joshuaissac wrote:
| The rules that they added, like the ban on mathematical
| operations, made it clear that they were not looking for
| understandable code. His code could handle new rules
| without a problem, so extensibility was not a problem
| either.
| wakawaka28 wrote:
| Near the top of the article:
|
| >While the base algorithm is very simple, the point of
| the exercise is that the interviewer will add new rules
| to test how you update the code while keeping it readable
| and maintainable.
|
| As for this:
|
| >His code could handle new rules without a problem, so
| extensibility was not a problem either.
|
| Ok, now I want you to query a database at runtime and
| write the output to a file instead if the number is in
| the database. Good luck with adapting this type-theory
| solution, and good luck with debugging this crap. It's a
| PhD-level solution to a freshman-level problem, that is
| very atypical and uses niche features of the language
| that might fail unexpectedly due to language limitations.
|
| On top of all of that, the story sounds like fiction as
| well. But who knows.
| grajaganDev wrote:
| I am not sure that clean, extensible and debuggable code
| could be written for such a bizarre set of requirements.
| whstl wrote:
| > their goal is to see how robust, reliable, and readable you
| can make your code
|
| The rules presented show that the goal is definitely not that.
| kmoser wrote:
| The way I see it, the rules are simply constraints and
| obstacles put in place to see how robust, reliable, and
| readable you can write your code under those conditions.
| trhway wrote:
| The author really looks like a junior, though unquestionably
| smart, dev. What he wrote isn't enterprise. Enterprise is
| spaghetti - the first version would be simple number array and
| division, and once numbers became strings and math isn't allowed,
| instead of division just run over the digit characters doing
| simple modulo 3 math in non-math way - as required - using say
| if/case as matrixes aren't allowed ( "3456" -> 6 mod 3 is 0, 5
| and 0 mod 3 is 2, 4 and 2 is 0, 3 and 0 is 0 -> Fizz ). Met not
| digit -> drop that number, move to the next. Met decimal dot ->
| start modulo again (set remainder to 0), and if it is not a first
| dot in that number -> drop the number, move to next. Basically
| any new rule is just an additional if/case branch or a
| flag/counter. Kind of self-documenting and easy to add and to
| remove/modify. switch (ch) { case '1':
| case '4': case '7': switch(rem) {
| case 0: rem = 1; break;
| case 1: rem = 2; break;
| ... break; case '2': case '5':
| ...
| tanepiper wrote:
| Honestly, if you are still using FizzBuzz in 2025 as a hiring
| question, you don't deserve the best developers. If you're still
| demanding a university-level education for a full stack developer
| you're going to be missing out on some great individual
| contributors.
|
| I get that smaller companies can't afford to mis-hire, but they
| are also not a FAANG - when I read this, I doubt I would have
| passed.
| iLoveOncall wrote:
| > 1. Max of 30 lines. Lines taken by the input array do not
| count.
|
| > 2. Max width of 100 characters. Lines must break on natural
| breakpoints and not with the aim of optimizing for following the
| rules. Comments do not count toward this limit and would be
| positively valued if they are helpful.
|
| This is the point at which I would say that I've heard enough and
| I'm not interested in working for their company, before I hang up
| the call.
| kej wrote:
| I'm curious what the full starting instructions were, and I
| concede that this might be a regional or cultural thing, but this
| entire article is missing that in the traditional children's game
| and in most online FizzBuzz problems you have to output the
| original number for numbers that aren't multiples of 3 or 5. That
| is, the input [1, 2, 3, 4, 5] should yield the output [1, 2,
| "fizz", 4, "buzz"].
|
| I'd be nervous about an applicant that came up with a very clever
| solution for the hard part of a problem but completely overlooked
| the simple part. (Again, not sure whether this is what happened
| here, but the change from how the problem is usually presented
| makes me wonder.)
| rvz wrote:
| > The position was for a Node.js backend developer.
|
| Seeing this being used in the backend is really questionable. In
| fact, I then question the overall skillset of the team as to why
| they need to use Node.js or JS-related technologies in the
| backend.
|
| As soon as I see any recruiter or company mentioning _any_ usage
| of Node.js or JavaScript or TypeScript in the backend in the job
| description, I just laugh and delete the email and never reply
| back.
|
| Introducing such unsound technologies into a production system
| responsible for maintaining a critical service is a recipe for
| complete chaos and disorder and tells me that your company is a
| joke that exists to prepare their developers for failure.
| fildevtronic wrote:
| I was expecting to read that this was some big time FAANGing
| company interview...but .no
| yobbo wrote:
| The base conversion insight was great. With this insight, the
| solution could have been just as compact and much more readable
| without using types.
|
| Sometimes it is possible to be too clever.
| skeeter2020 wrote:
| 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, explicitly tell
| them "wow! that'd didn't go as we planned, but interesting
| approach!", maybe steer conversation to the pros/cons of
| unique/efficient solutions vs. less terse / bog-standard
| approaches, have some prepared code to debug and refactor
| (instead of expecting the candidate to produce it).
|
| I do a lot of interviews and most of them are so boring and
| forgettable. The best ones are unique and the candidates shows
| passion about <anything> in any demonstrable way.
| whstl wrote:
| 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.
| doctorpangloss wrote:
| Every candidate who has ever shown me an interesting solution
| to a purposefully open ended programming question wildly
| exceeded expectations.
| lowbloodsugar wrote:
| 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.
| z3t4 wrote:
| 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 want to hire people that are like
| them.
|
| Here's my tip: Start filter out jobs instead of having them
| filter you out! There are many jobs, especially if you are
| willing to relocate.
|
| Only apply for places that are as much into types and functional
| programming that you are! Or at least on your "nerd" level
| generally.
|
| Do the company have a technical blog that writes about this
| stuff? Do the company have a technical speaker that speak about
| this stuff? Is anyone at the company writing technical articles
| about this stuff?
|
| If you see a good article, reach out to the author and ask if
| they have any openings or can recommend a good company to work
| for.
|
| Also if you are applying for a senior position, and you get to an
| interview, you should be talking to them as if they where 5 year
| olds. Even if they say they have 30 years of experience, explain
| stuff like if you where talking to a kid. For me it's much easier
| to come up with a better algorithm then explaining to others why
| it's better. It feels like explaining it to my dog.
| James_K wrote:
| 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 to do things. If
| you are going to actually get stuff done, then I think you need
| a certain number of drones--people who follow orders reliably
| to produce predictable outcomes. If you don't want to be a
| drone, then you probably shouldn't apply for jobs given that
| drones account for the vast majority of employed people.
| bluGill wrote:
| 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.
| doctorpangloss wrote:
| 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.
| James_K wrote:
| Are you trying to insult me?
| ryandrake wrote:
| 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.
| James_K wrote:
| 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.
| ryandrake wrote:
| There is no need to invoke negative connotations about an
| honest day's work. Obviously not everyone is John Carmack
| or Ken Thompson. Just because most of us are a small part
| of a large company, that doesn't mean we are drones.
| airforce1 wrote:
| My initial thought is that it is a troll post as well. All
| interviewers had to say was "ok, but your program needs to be
| able to take input from a file and write output to a file" and
| OP would have been caught with his pants down.
|
| Instead OP is a hero who bests the interviewers at every turn
| with his cleverness.
| crosser wrote:
| Small company in Netherlands? My guess: management realized that
| they don't have money, and axed the position. They cannot say it
| openly, so had no choice but to ghost the interviewee. Which is
| of course still very frustrating!
| joshstrange wrote:
| This is a horrible interview process. I'm not even going to
| comment on the salary other than that company must be quite full
| of themselves to offer that low and give a stupid technical test
| that proves nothing.
|
| Hazing-style technical tests are just dumb and this absolutely
| qualifies. On top of that, I hate technical interviews that tell
| you that you can't search the internet or use toolsets that you
| would use daily in your job. Why do companies waste everyone's
| time on exercises that are not representative of the work/working
| conditions?
|
| When I ran a hiring round last year I spent a good chunk of time
| putting together a test/process that tried to closely mirror the
| type of code/problems you would be solving as an IC. I had almost
| every candidate (even the ones we passed on) commented on the
| process and how it was no-nonsense and letting them use whatever
| tool/resource/etc they wanted to solve it made it less stressful.
|
| I even told people they were free to use LLM/AIs. After competing
| the base test (which they did without us watching, it's an easy
| base problem) we asked candidates to modify the code to handle
| one more use-case (very simple, nothing like the silly rules the
| OP was given) and it was very clear which people understood the
| code they/the AI had written vs the ones that could prompt for a
| solution but didn't understand it and thus failed to modify it to
| account for the new use-case (or struggled heavily for something
| that was a 1-3 line fix depending on how you implemented the
| original code).
|
| I truly despise the hiring process from both sides. Both parties
| are asked to make life-altering decisions on very little data. We
| had a 4-step interview process:
|
| * Introduction, ask basic questions, get to know you
|
| * Technical test and problem solving test (the problem solving
| test was talking through a real issue we had run into, asking you
| to talk through possible ways to solve it. There is no "right"
| answer or rather there are multiple right answers)
|
| * Debugging test, we produce code with bugs in it, you find/fix
| all the bugs
|
| * Final interview with owners of the company
|
| Last time I talked about this in HN I had at least 1 person
| complain about how long the process was. Normally we'd get
| through it in 2 weeks or less with a candidate (depending on
| scheduling) and it was a total of about 5-6hr (depending on how
| long the tests took). I'm not a fan of long and drawn out
| interview processes, but this was the bare minimum process I
| could come up with that would test candidates in the areas that
| we cared about. Also, I wanted to give ourselves multiple chances
| to interact with the interviewee as some people came across great
| in the first few rounds, and by the later rounds issues had
| started to surface.
|
| Is 6hr really a crazy amount of time to spend deciding if you
| want to commit to 40hrs a week to a company for potentially years
| of your life? Yes, yes, yes, I know you can leave after a week if
| you are unhappy and I know the company can let you go after a
| week if they are unhappy but it's never that easy and switching
| jobs is hard/painful/stressful (as is firing someone). I am
| strong opposed to the "just hire them and fire them quickly if it
| doesn't work out", in fact I find it morally repugnant to play
| with people's lives in that way. Also, I assume the people who
| suggest such a corse of action are not the ones that have to
| onboard new hires (a process that is very involved and takes a
| lot of time, for me at least).
|
| This was an interesting post for how to solve FizzBuzz in an
| unorthodox and just "cool" way but this test tells you nothing.
| In fact, if a developer wrote code trying to be this clever, I
| would reject it at PR time. It's cool for code-golfing but LoC is
| always a stupid measurement when it comes to maintainable code.
|
| I wish the OP the best of luck finding a job that doesn't make
| them jump through hoops like this again.
| Dansvidania wrote:
| The interviewing company does seem like a dodged bullet at first
| glance, but:
|
| - the requirements being weird might very well be modeling how
| weird things often get in reality. Rules are often not recorded
| and not repeated, and very often they seem arbitrary from the POV
| of the developers.
|
| - the interviewers hinted that the direction was not what they
| were looking for
|
| - a senior dev needs to apply his own common sense to understand
| what the truly appropriate solution is given the stated
| priorities (readability and maintainability were stated)
|
| - not to mention the fact that if the interviewers don't
| understand your code, things won't go smoothly for you either way
|
| The fact that they said, paraphrasing "..pick any esoteric
| language.." might investigate whether, given technical freedom
| (EG: to pick your own stack) you will build an incomprehensible
| codebase that will be hard for the company to deal with in the
| future
|
| I think the author is indeed very clever and I learned a few
| things from reading this write up (thanks for sharing!) but I
| think the interviewers were right not be impressed.
|
| If I were you, I'd try to dumb it down for your colleagues.
| pinoy420 wrote:
| Absolutely. This would be a no from me
| ben-schaaf wrote:
| What's the plan for the candidate choosing C when they hit rule 7
| and simultaneously have to use strings but the `char` type is
| banned? How are they supposed to loop through the input array
| without an increment operation? Pointers are basically also
| numerical types, are those banned as well?
| pinoy420 wrote:
| Cosmic rays and a lot of luck
| throw16180339 wrote:
| There's always recursion.
| zo1 wrote:
| That's the point at which most sane people would tell the
| interviewer to "GTFO".
|
| If they're hiring for some hyper unique role where they have to
| deal with some contrived AI in a dark room and they have to do
| it because someone's got a gun to their heads and they have to
| invent calculus to solve FizzBuzz in under 14.5 minutes
| otherwise the memory is corrupted and the world explodes, then
| sure they can ask such a contrived interview question.
|
| Until then, this company is either crazy, bored, not looking to
| hire a candidate, or simply fictional and made up by the author
| to tell a feel-good story that makes them look like the
| Einstein-equivalent for programmers.
| pockmarked19 wrote:
| If this is what people imagine when they hear of whiteboard
| interviews, no wonder they hate them! What this was and what a
| technical interview is supposed to be could not be any more
| different. This interview reminds me of some experiences I've had
| in my early career, and now I know better than to spend more than
| 5 minutes with this kind of nonsense.
|
| The easiest tell is the adversarial nature of it, but the moment
| the "max of 30 lines" slide was revealed I'd be out. Scratch that
| - I'd be out when I saw there were slides. The point of a
| technical interview isn't to repeatedly try and throw caltrops in
| front of someone, and a company that doesn't know that is
| unlikely to be a great place to work.
| astura wrote:
| Dumb hazing exercise.
|
| I would have walked out.
| BobbyTables2 wrote:
| Never considered using base-15 for FizzBuzz - that's brilliant!
|
| This may sound surprising, but interviews are equally about
| convincing the candidate to join the company as they are about
| convincing the company to hire the candidate. The former involves
| much more than just the number for compensation.
|
| I think you dodged a bullet here.
|
| Once found myself in a similar ridiculous situation (Google
| interview). Looking back, I have to wonder if they expected me to
| put my foot down and tell them why their scenario was getting
| ludicrous instead of continuing along. In the end, they
| determined I wasn't even fit to be a sysadmin, much less a SRE,
| despite 10 years of relevant development experience with a wide
| technical background and numerous patents.
| pavel_lishin wrote:
| > _They didn't want to tell me if I would be a contractor or an
| employee during the personal interview. They told me that they
| were just looking for the right person and that technicalities
| would be discussed later._
|
| ... that 's not a "technicality", that's a crucial distinction
| that's as important as salary range or other benefits. This would
| be a huge red flag for me.
| spamizbad wrote:
| Boy do I feel for that candidate. As a manager, while this is not
| the kind of question I'd ever ask, if I saw a candidate work
| through a problem like this I'd take it as a strong signal for a
| possible hire. Ghosting is a dick move period, but especially
| after a performance like that. I would like a follow-up
| discussion probing how open/accepting they'd be to skilling-up in
| their weaker areas, how they go about asking for help, try to
| suss out if they're prone to getting stuck in "ruts". But if I
| didn't see any red flags my vote would've been yes.
| kevinventullo wrote:
| Am I crazy or is "conversion to base 15" very much a numeric
| method/operation?
|
| Like sure the API itself may have string input/output, but under
| the hood there's no way it's not doing integer divisions and
| modulos.
| Karliss wrote:
| From what I understand there was no change of base within the
| solution code. Author just used the base conversion function to
| prepare some test inputs.
|
| "The input array must contain a string representations of the
| numbers. The programmer can use whatever representation they
| see fit"
|
| Allowing arbitrary string based representation of numbers also
| means that whole task becomes a bit silly. Why stop at base 15,
| when you could use what I call the "FizzBuzz" number system. In
| fizzbuzz number system the divisibility by 3 and 5 is encoded
| in first symbols of number. Something like 1="1", 3="F", 5="B",
| 10="B2", 30="FB2", 1000="B200". Digits represent rest of the
| number you get after dividing it by 3 and 5 if possible.
| umvi wrote:
| 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."
| whstl wrote:
| 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?
| kibwen wrote:
| _> 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_
|
| I think this is uncharitable. The interviewer's demands to not
| use numeric types or any mathematical operations is inherently
| preposterous, and at that point the author can't be judged
| negatively for whatever contortions they needed to perform in
| order to comply with them.
| umvi wrote:
| That's fair, the interviewers did put unreasonable
| restrictions on the challenge that forced the overly clever
| solution. It was my kneejerk response from personal
| experience seeing candidates come up with overly clever
| solutions even to simple job challenges.
|
| But even still, let's assume there is a problem out there
| with unreasonable requirements. And let's say an engineer
| architects a solution to that problem in 100% TS. How's that
| going to solve anything? When the inputs and outputs are
| types... how do you interface with such a solution? You can't
| because types only exist at compile time so there's no way to
| dynamically send in inputs and retrieve outputs (at least not
| without _even more_ hacks /cleverness).
| kiviuq wrote:
| I can't ask the candidate not to jump, and then complain
| that he didn't.
| yreg wrote:
| OP, you are not the author, right? Do you know them? It seems
| like they might be interested in the comments here, unless the
| article is ancient.
| lcnPylGDnU4H9OF wrote:
| It reminds me of _Typing the Technical Interview_ (highly
| recommended if one is unfamiliar) but seemingly more likely to be
| non-fiction, given the difference in storytelling style. I wish
| the author luck in their search.
|
| https://aphyr.com/posts/342-typing-the-technical-interview
| rapidaneurism wrote:
| the point of this exercise was (1) to weed out people who could
| not code at all, (2) have people fail after 7, so that they could
| low ball them to below 50k as they 'failed the test but they
| might deserve a chance'
| firesteelrain wrote:
| What if the interviewers were offended that this guy is smarter
| than them?
|
| I once was given an interview question for a position at a
| company. Wanted me to create build scheduler in any language. It
| was a build engineer position. I started to do their at home
| exercise but ended up telling the recruiter I won't do the
| exercise. It was pointless since Bamboo, Jenkins, or GitLab is
| what they should be using. Not some home grown build system.
| cvoss wrote:
| If the interviewers thought the hardcoded sum table was cheating,
| they surely should have said that demanding the inputs come in
| base 15 was also cheating. (I think base 15 is the best solution
| though. The instant I saw the rule that permitted the dev to
| choose the input representation, I knew this would be the way to
| go.)
|
| But if the interviewers have to be persuaded that 0 is divisible
| by 3, I guess you can't expect too much from them. Or anything
| from them.
| joeguilmette wrote:
| are you still looking for work?
| joeguilmette wrote:
| Does anyone have the contact information of this person? Are they
| still looking for work?
| moi2388 wrote:
| It's not your technical skills.
|
| I guarantee it's due to you not living in the Netherlands and not
| being fluent in English.
|
| No matter if the job offers says they accept remote people, in
| the Netherlands they really value face to face contact and good
| and open communication.
| bhk wrote:
| The interviewers were fans of Franz Kafka, I presume.
| vander_elst wrote:
| If what's written on the blog is true, the interviewee knows
| their stuff technically and the interviewers were just bad: they
| wanted to check some boxes, feel good about themselves and be
| done. Nonetheless, by self admission the interviewee also didn't
| speak English very well ("This was my first interview for a
| foreign company and the first time in life I spoke english") and
| that could also be part of the problem or something we didn't
| know is how the overall communication went, this might have
| played a part in the rejection. A candidate, but also an
| employee, might be very strong technically, but they should be
| able to clearly communicate their solutions and play well within
| a team, having a genius Anarchist might not always be the best.
| Anyway, from the post, I'd have moved forward with the candidate
| and if they were rejected they probably dodged a bullet. Best of
| luck with the next interviews!
| stefs wrote:
| looks like they failed this interview, not you.
| Cypher wrote:
| They were looking for someone who ignored the rules.
___________________________________________________________________
(page generated 2025-01-25 23:02 UTC)