7 ms·

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 ty

• ali_piccioni 2y ago
  Wittgenstein’s ruler in action.
• alkyon 2y ago
  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 2y ago
    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 2y ago
      A person doesn’t have to be privileged to value things differently than you think they should.
    • alkyon 2y ago
      "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 2y ago
        They also mentioned being fired. But who knows. It's not that important for what I wanted to say.
      • quietbritishjim 2y ago
        "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 2y ago
  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 2y ago
    > 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 2y ago
      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 2y ago
      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.
• TomMasz 2y ago
  Designed to weed out anyone who might not follow orders. Was this a cult?
  • James_K 2y ago
    Close, it's what you might call a "job" where someone pays you to do what they say.
    • wiseowise 2y ago
      If by job you mean acting as a circus bear.
      • James_K 2y ago
        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 2y ago
          I wouldn’t accept an employee or a boss who thought this was a reasonable definition of a job.
          • James_K 2y ago
            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 2y ago
              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.
• alok-g 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
    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.
• jancsika 2y ago
  > 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 2y ago
    > 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 2y ago
    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
  • adammarples 2y ago
    The base 15 thing is a great example of thinking more deeply and then precisely solving the problem in its own domain of complexity
• Waterluvian 2y ago
  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”
  • vidro3 2y ago
    what's the use case for call and apply? in 6 years i think i've written .call once
    • Waterluvian 2y ago
      apply could be useful before the spread operator existed. They can also be a bit useful to call one prototype’s function on another object given you get to pick what “this” is. But in my 12 years I’ve never used them. They’re likely even less important now that we have arrow functions and other features. They probably were useful library building blocks way back in the day.
    • remich 2y ago
      They can be useful if you're working in situations where preserving and using the correct form of _this_ is necessary. Could be a situation with funky legacy code or writing library/utility functions (like an implementation of debounce) where you can't be certain of the context in which your function is going to be used. These don't come up a ton in modern code bases in part because of the advent of arrow functions, and in part because of the general trend towards FP / declarative programming in JS/TS and away from OOP / "class" use and thus less need for managing "this" throughout an application. Also most of the time if you really need a utility function it's easier to rely on a bulletproof dependency library like Ramda/Lodash/Underscore... concerns about bundle size notwithstanding. Another use case is if you need to use array methods on array-like things (this comes up sometimes with DOM manipulation). These data structures are iterables but lack the native array methods like map/filter/reduce etc. If for some reason you can't/don't want to create a new array from your data structure to operate on you can do something like Array.prototype.filter.call(myNodeList, filterFunction). Also not terribly common in modern codebases, but useful to be aware of!
• stickfigure 2y ago
  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 2y ago
    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.
• beefnugs 2y ago
  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
• AutistiCoder 2y ago
  As an AuDHDer, I can see myself having an especially difficult time. This would be basically impossible.