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.
"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.
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.
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.
I had a similar experience at a different big tech company when I went to use Ruby. The interviewer suggested that Ruby was allowed, but I would be unlikely to get the job if I didn't use python.
I did get the job, and with almost entirely in Ruby and PowerShell, so....
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.
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.
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.
> 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?
> 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.
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.
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.
> * 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.
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.
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.
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.
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.
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.
The post actually has a lot of small grammatical errors typical of someone not so fluent in English:
>> My reasoning went as follow: // My reasoning went as follows.
>> Is there any other numbers where this happens? // Are there any other numbers
>> I didn’t had paper at hand // I didn't have (any) paper on hand.
I'm not here to proofread a fun blog post but it's far from incredibly well-written English.
> that requires incredibly deep knowledge of the type system.
I think the solution needed more clever maths than deep knowledge of the type system---the type system knowledge can be self-studied from documentation. The clever maths, one can get used to if you Leetcode properly (you don't even need Leetcode Hard to get exposure to that).
If anything doesn't track in this respect, it's the claim that author doesn't have any kind of formal education. Not even high school? That will be extremely impressive. But maybe something got lost in translation there, or just careless exaggeration.
> Here's a viral calling card that would almost guarantee countless interviews (including from my company!) and they aren't capitalizing on it.
>> I don’t have anything to sell just yet, I am not a tech influencer so all you got was this post about a somewhat challenging FizzBuzz.
Yeah, not everyone is out to sell something, not every blog post is written as an opportunity to self-promote.
The story is definitely rather strange, even without taking into account the language barrier and the general absurdity of most tech interviews, but it's not outside the realm of possibility.
I didn’t even notice the typos when reading it... I did notice how well the text flows, how easy it is to read.
I (not a native speaker either) probably don’t make that many grammatical errors, but I envy their ability to just write. I can’t do that, I struggle with every word in long form writing.
These small errors are easily addressed with a final pass in e.g. DeepL Writer.
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.
"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.
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.
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.
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.
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.
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!
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.
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.
The only thing that might be tricky about FizzBuzz is if the person doesn't know about the modulo operator. I can't remember the last time I used it in production code; I use it far more thinking about FizzBuzz than I do anywhere else.
If I didn't have the modulo operator, I would just check whether division resulted in a round number. I wouldn't rate someone who understands this basic principle lower than someone who just happens to know about the modulo operator.
Bonus points if you use Python and demonstrate that you know the difference between the / operator and the // operator. That's much more useful in day-to-day work.
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.
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.)
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.
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.
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.
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.
> 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.
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.
> 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.
Listen, your argument follows from your premises, but your premises are flawed. Your argument is reductive because it requires the assumption that people only want one thing (specifically in this case: to do a thing other than their job). Of course it follows that they're doing something they don't want to be doing when you only allow them to want one thing.
It's not reasonable to take someone saying, "I'd rather be parasailing..." to mean, "I don't want to do this work." Those are not equivalent statements. For starters, one is relative and the other is absolute. Even if that weren't the case, people can want more than one thing and even conflicting things.
If I say, "I want to fly like Superman" you can't then conclude that everything in my life that I'm doing is something I don't want to be doing since I'm not flying like Superman at any moment.
It's reductive and the only thing it fully explains is the highly reductive space it constructs.
> 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."
I've already justified it. In my experience, which I understand is not your experience, an employee with this attitude is more likely to not have a good work ethic. You then made up a bunch of stuff about what I mean by that, but I just mean they're less likely to do a good job. A boss with this attitude is more likely to feel entitled to my labor and make unreasonable demands, including but not limited to trying to require me to do things I don't want to do (i.e., that I haven't agreed to do as part of accepting 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.
There was never a moment when I couldn't see your objection. I just think the opposite is more likely, but this view is really just your opinion and not actually related to your original statement, except in terms of its explanatory power for why you want to believe the world works a certain way.
It's wholly unclear to me why a boss acting badly means all employees everywhere should have a wall between work and pleasure. That seems like throwing the baby out with the bathwater. Should we all just do jobs we hate so this doesn't happen?
A boss can certainly try to exploit his employees by using their non-monetary interests against them. But the boss that thinks transactionally is more likely to do it!
On the flip side, any employee can have a good work ethic, but...
Suppose you have a transactional employee and an employee who wants to be there. Suppose also you have a machine that requires maintenance and it is such that it is difficult to see whether that maintenance has been done. If the maintenance isn't done, you won't know until (say) two years later when the machine breaks down and requires relatively expensive repairs.
Are you going to assign the employee that has said to you this is just transactional? What is his incentive to even do the maintenance? Yes, either employee can get away without doing the maintenance. But which one do you think is more likely to shirk the responsibility? Which one is more likely to not be around to face consequences if they don't do the work?
So, yes, I see what you are saying. But I'm not even a little bit convinced. I don't want to deal with people as employees, bosses, partners, contractors, clients, etc who view work this way, because 'the real world' just doesn't work that way and people who think it does, again in my experience are generally more likely to be a problem than others.
> Your argument is reductive because it requires the assumption that people only want one thing
No it doesn't. I explicitly mention that there is one thing they want to do the most and that other things are closer to or further away from that thing.
> Are you going to assign the employee that has said to you this is just transactional? What is his incentive to even do the maintenance.
I would assign the employee which I trust more, which could well be the transnational one. Someone who claims to enjoy their job might enjoy it because they don't bother with the stuff that bores them, and someone who hates their job might hate it because they put intense effort into ensuring it is done well. I have family members who fall exactly into the latter group. They are highly committed to the idea of earning their pay and thus have a much harder time of it than they would otherwise. Someone who thinks "I must work because I'm getting paid" is far more reliable than someone who thinks "I'll work because I enjoy it". Of course some people will try to get away with doing less work, but I don't see much difference between avoiding work you don't enjoy because you don't enjoy it and avoiding work you don't enjoy because you can still get paid without doing it.
The point I'd like to make is this: someone who works for pay has a clear motivation to do work they don't enjoy. Why would someone who works for enjoyment bother with the parts they don't enjoy? You skirt this problem by saying the employee wants to be there and so wants to do all work, but there are some people who enjoy certain parts of their work and not others. "Wanting to be there" is not a motivation for working but the outcome of that motivation, where "pay" and "enjoyment" are reasons to work and it's not so clear that someone who only works when they enjoy it would be more reliable.
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...
“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”
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.
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...
> 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?
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
> 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.
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.
> 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.
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.
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.
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.
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.
>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.
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.
It is not uncommon for self-taught people to develop weird fixations on particular niche tech. Even if their understanding is thorough, they don't have the experience to know when their tool is appropriate. 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. He wrote a fair amount of seemingly sophisticated code and sounded smart until you really got down to details and realized how nonsensical it all was. The worst part is if such a person becomes a manager and YOU have to be the one to fight for the right solution with them. I think that guy talked his way into management after I left the company, and I pity anyone who has to work under him.
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.
>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.
>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.
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.
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.
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."
> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.
Wrong. They put in silly rules like "Max of 30 lines" and "Mutating array operations are forbidden". These do not describe industrial-grade rules. They describe an academic, esoteric challenge. And then when he provides them with it, they punish him for his creativity by adding in bullshit rules retroactively e.g. "Hardcoding matrices is forbidden."
You just sound upset that he's able to walk the walk but you WANT him to be just a bullshitter.
> 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? ;)
> 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.)
> I wish all the best to him, but reading between the lines is a useful skill regardless of this specific situation.
I disagree. This is not a fair ask, especially for a programming position. Programming and maths in particular puts a lot of emphasis on attention to detail.
If he can write it in X, and there's no rule against it, and the job gets done well, then there is no issue. Arguing any further of it is unproductive. He's applying for software development, not for public relations.
> "I don't think that will be a good idea" is not a suggestion, it's an order.
Then it should be a rule. "Reading between the lines" sounds like an excuse to me for bullshit criteria. It should be written, it should be explicit, and it should be known. If the interviewer is uncomfortable writing it down as a rule then that tells me they KNOW that it's too silly or pedantic. This whole idea of unwritten rules is a double standard designed to weed out neurodivergent or autistic individuals who are more than capable of fulfilling job requirements and, to me, seems like a potentially illegal form of discrimination that violates disability civil rights laws.
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.
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.
> 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.
> 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.
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.
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.”
"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.
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.
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.
> 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).
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?
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.
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.
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.
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.
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.
Agree as a general rule BUT candidates can (and some WILL) lie to those questions. See how they react naturally although in a simulated scenario can give you a better idea.
But you should do both things, probably in 2 different interviews.
I think the lie is in thinking FizzBuzz is going to give you any insight into such matters.
Put aside your paranoia and just talk to your candidates. Ask them thoughtful questions that invite thoughtful answers. Probe gently to get at more challenging questions. Trust your ability to discern when they're BSing you.
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
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.
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.
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.
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"
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.
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.
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.
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.
Then it's a stupid way to check for it, because it was possible and trivial enough to implement in a short time frame with a "rewrite" in the middle and no attempt to meassure pushing back in other ways when the first one failed
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.
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.
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
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.
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.
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.
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.
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)
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.
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.
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.
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
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,...
Maybe you just have no experience with Silicon Valley or just hate it for whatever reason, but the only thing in that list that doesn’t apply to SV is the unions… Not sure the point you’re making.
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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
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.
> Math operators like division aren’t native to your (traditional) cpu, they are implemented in code
If you are talking about tiny microprocessors or old ARM chips, sure. But so are programming languages! They should have really asked him to code his solution in machine code then. After all, that's what you typically do in a NodeJS job :)
Agree. While the solution is impressive, the choice of using the type system severely hampers the ways the code can be deployed. Instead of taking dynamic input, the DATA array must now be encoded up-front in an unexpected number-base and run within the tsc compiler. It limits the number of members in the team that can maintain it. Finally, he was lucky there were no further silly requirements like send a PDF report to the CTO if the number is divisible by 201 and it's a Monday. While i also disprove of the interview setup and their bizarre artificial limitations, in the real world shit also happens and you need to react to it, if you decided to prematurely constrain yourself for the sake of scratching your own itch, you could set back progress for weeks, i see this happen all the times with people choosing the wrong tool for the job or reinventing what already exists in the standard library. Long term maintainability and pragmatism is valued higher by the business.
In my books this choice alone wouldn't be cause for rejection, a good interviewer would question it though and depending on the reaction, it could be. Whether or not that happened here isn't clear. They could also have other even better candidates to pick.
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?
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!
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.
>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
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."
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.
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.
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.
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.
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.
The interviewers came up with a lot of brain dead rules that they (hopefully) don’t use on their code base.
I could ask you to show me how well and fast you can run while making up a rule that you can’t use your legs and then tell you that you can’t run fast enough to join my sprint team… but that would be idiotic on my part.
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.
Yeah, I'm pretty sure the typescript solution was way beyond the skill level of the interviewer.
Which is fine.
But what's unacceptable is that a lot of people in our industry are not mature enough to admit when they don't know something, and instead just chalk it off as "unreadable" or some other adjective.
I was once interviewed by someone who is quite famous in the industry, even then, and he looked at my program for his test and said “This can’t possibly work.” And then later I got the job offer because he’d figured it out and it totally worked.
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.
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.
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.
In my experience, everyone who has ever invoked "drones" to describe a subordinate hires the absolute worst candidates. They never get far enough in interviewing to the made up situation you are describing, they hired someone terrible long ago.
Yea, there is way too much “everyone below me in [skill | cleverness | intelligence | creativity] is a drone (or NPC)” attitude in tech. Not saying OP thinks this, but the word use is kind of icky.
I use it deliberately to invoke these negative connotations. I am not commenting on the skill, creativity, or any other aspect of the drones. I think it's just a fairly basic fact that most of us are drones. We go to work, we do what we're told, we get paid. There's no shame in it. Being a drone is an honest living. It just seems that many here are in denial of that. They think that every worker is going to be a special snowflake doing their own creative little thing instead of a small cog in big machine that has to fall in line with every other part.
I think it's just out of touch with reality. If you are applying for a job, then they probably want someone who does what their told reliably and predictably, and you probably want to get paid. So you should show them that you are capable of doing what you're told reliably and predictably. You exchange your time for money and everybody benefits. It's just a waste of everybody's time if you are going to rage against this process—insist on not doing what you are told and then get angry when the result is not getting paid.
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.
I think by describing it in the starkest possible terms, one can elucidate the situation. What people object to here is the idea of being a drone, and I'm saying "you are and it's fine".
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.
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?!
This is my takeaway, like maybe 3 extra rules would be worthwhile but by god there is too many, what are you learning here for something so simple as fizzbuzz
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.
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.
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.
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.
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.
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'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!
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.
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?
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.
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.
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.
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.
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.
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.
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.)
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 :)
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
>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.
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.
Respectfully, if someone puts "remote available" on a job description and expects you to know they don't _actually_ want those applicants due to specific nuanced cultural differences, those people can go fuck _all_ the way off for wasting my time.
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.
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.
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.
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.
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.
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.
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".
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)
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.
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.
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.
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”.
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..
Interesting article and congrats on the original solutions, but wow!
Is there any other field where applicants are subjected to this?
Nepalese Ghhurkas perhaps ?
I once backed out of an interview when they sent me an 85 page manual on how to prepare for the interview with them.
It was not even a FAANG company, just a small IT solution with mediocre benefits.
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?
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.
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'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.
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!
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.
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!
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!
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.
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.
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'
Maybe I missed something, but if DATA is given as an array at runtime, is there a way to put it into the type system? And if the result is in type system, is there a way to print it out at runtime without looping through all permutations of the possible characters?
The solution was impressive and fascinating, regardless.
The base conversion insight is annoying; they mandate the form of the input in detail down to individual characters and mandate that you can't use numeric methods, except that in this one situation you can completely control the input and do so in a numeric way. You can't change programming language after starting, but you can change the input format on-demand? If you can choose an arbitrary input pre-processor, just choose that the input is the desired output and your program can echo it.
By rule 7: "Numeric types, number literals and their associated methods and operations are forbidden. The input array must contain a string representations of the numbers. 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 (they didn’t specify which keyboard layout, in mine, ñ and ç can be typed with a single stroke but I assumed it was an US keyboard). The max length of a string representing a number is 6 characters."
The numbers they care about are 1 - 1000 and the max length is 6 that leaves two spare digits, so decide that the input format is "tf0000" where the first two characters indicate if the number is a multiple of three, or five, respectively.
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.
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.
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.
This sounds like a bad interview IMO. But also, don’t be this interviewee.
Solving a problem like this with the type system is setting off all kinds of “too clever for their own good” alarm bells. The goal of a coding interview is to showcase as concisely as possible that you know the craft of software engineering. Fizzbuzz should not be considered an IQ test.
The progressive requirements in the interview, while clunky, are getting at the reality of software development: there rarely exists a spec for what you are building. You need to be flexible to future requirements, and you need to write maintainable code that others on your team can understand.
> 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.
> 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.
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
> 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.
No, I see people complaining about a test not looking like what they expect, or minor nitpicks like variable names or not using the interviewer's favourite design pattern
Of course the same people who nitpick are the ones writing O(n^2) code and actually causing a major bug
Ok, I was thinking about something else than stylistic preferences, e.g. making an off-by-one error in an implementation of an algorithm during live coding. Something that indeed would be usually catched by a careful code review, but candidates sometimes undermine importance errors.
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.
I think DHH was right all along. Typescript is cool if you use it alone but from my experience code like the one produced by the OP gets written by some ex-Java ninja and out of 1000 devs maybe 5 could fully comprehend what the code actually does. AI writes this kind of TS a lot. I don’t say TS is bad but most of the time I feel it’s like trying to kill a fly with a nuke. The worst part is I almost never had the issues TS tries to solve, after all adding prototypes to React took 1/10th of the time than annoyances with TS take.
> 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.
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.
> 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
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.
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...
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.
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':
...
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."
> 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.
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).
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?
> 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.
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.
I will never understand how can someone say so confidently such a broad statement believing it truly applies indiscriminately to every person of a country with 18 million people. Even if you had some bad experience with dutch people how can you really believe this automatically applies to all of them? Geez
> are sticklers (mierenneuker), focus on irrelevant things, operate in cliques and have gigantic egos while pretending to be humble.
I'd say these weaknesses are common among many cultures and definitely a thing from people with authoritarian mindsets ("leadership is right because they're leadership").
The same company might employ these people in one team and not in another.
You don't really know until you're dealing. Minimizing their ability to stand in the way of progress is key.
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.
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.
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...
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...
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 ásterda).
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.
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.
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.
reply