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.
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 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.
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.
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.
“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”
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.
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.
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 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.
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.
> 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.
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.
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.
"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.
> 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.
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.
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.
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
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.
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.
Yeah I you dodged too. What work environment would you want to be in where there's no architecture discussion and you're expected to just have the answers?
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.
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.
I noticed this in the throwaway comment that the OP made at the end about their prior job disfavoring the use of TS.
I'm not surprised to see that type of sentiment from someone who is (at least self-described) at a more junior level, but still. Often the choice of what language/framework/tool to use on a given codebase or project is dictated or constrained by considerations other than which one is "best" in a technical sense.
Does this suck? Yeah, most of us have strongly held opinions or like to try out new shiny things. But it's a reality of working in this field and coworkers who refuse to learn it can be really hard to work with.
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?
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.
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!
>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."
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.
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.
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.
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.
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.
What is there to hear? They asked ridiculous questions. Interviewee showed above average competence. So, they should have moved to next interview for cultural fit.
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.
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.
Readit News
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.
> 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?
"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.
The author claims their pronunciation is poor. Writing is a completely different skill. (Especially in English with its insane spelling rules.)
> * Author says they have 2 years of work experience in a company that doesn't use Typescript, but then proceeds to create a solution ad-hoc that requires incredibly deep knowledge of the type system. Certainly not impossible, but I don't know anyone that could pull this off.
Self-study?
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.
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.
“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”
Why on earth would the interviewer think that 0 is not a multiple of 3 and 5?
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.
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.
[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.
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.
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.
1 tech interview which was progressively implementing a banking system. Final question involved threading
1 tech interview which involved building a banking system but it was more systems and database design.
1 business logic interview which was breaking down how credit card numbers worked and then asking me to do a code review
1 was just a personal fit interview.
It took a lot of time but it all felt realistic and useful in the context of hiring someone.
While good employees are always just thinking: cool i will try something smart to make them think i am smart, or ok i will follow these dumb exact things to make sure they know i am obedient, jesus christ why cant i just play a video of me doing this from last week, i guess i better try it a different way since that way didnt get me hired, i guess i need to dance this angle to the moon this time...
At least AI will stop all of this nonsense
This would be basically impossible.
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?
> I guarantee that there were other candidates whose code got simplified and more commented as the spec grew.
I don't understand this criticism.
His code only got weird and clever when he was told not to use numbers. That is a very reasonable consequence for such a huge restriction.
And then with the switch to base 15 his code went back to being nice and simple.
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.
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.
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.
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.
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.
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.
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.
And the reason for the hesitance was a worry that it would have trouble with future rules, which turned out to be completely unfounded.
But after living in the UK for a bit, in the UK that is most likely an order.
"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.
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).
You are interviewing them too.
I would also have hired the candidate.
My reasoning is that the company advertised a position for a senior engineer with 4 years experience. Leaving aside title inflation and whether someone with 4 years experience is actually a senior engineer, and leaving aside the really dumb test, that position requires communication skills, common sense, maturity, and just generally knowing what's going on. A candidate who misreads the situation in an interview so badly that they can't take the interviewer's unsubtle hints is going to mess up other communication within the company, has likely never been on the other side of an interview before, and is at risk of allowing the kind of "clever" code that destroys companies.
Again, this is only a problem for a senior engineer. I want junior and mid-level engineers to be clever and enthusiastic. Senior engineers are meant to understand that I have five interviews this week and their attempt to channel Aphyr[0] is going to make my life harder when I want to talk about their thoughts on maintainability.
[0] https://aphyr.com/posts/342-typing-the-technical-interview
But if you're doing anything unique, or experimental they might be a great fit.
Most of us are doing the second.
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
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.
That was forbidden, check the rules given by the interviewer.
"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.
No somehow to it, that's just offensive.
Edit: I’m no master of replying to the correct person either.
¯\_(ツ)_/¯
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.
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.
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.
One is choice of language, which is supposed to not matter because it's just an interview exercise where you can pick any language.
The other is the contortions around not using numbers.
Anything stemming from those two factors should not be held against the candidate. It definitely shouldn't be labeled as "scratching your own itch".
I'm not surprised to see that type of sentiment from someone who is (at least self-described) at a more junior level, but still. Often the choice of what language/framework/tool to use on a given codebase or project is dictated or constrained by considerations other than which one is "best" in a technical sense.
Does this suck? Yeah, most of us have strongly held opinions or like to try out new shiny things. But it's a reality of working in this field and coworkers who refuse to learn it can be really hard to work with.
(see for example Scott Wlaschin)
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.
Yes, but only on the weekends :)
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
Where was that stated? I don't see those being mentioned as core requirements at all
"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."
Fizz buzz is also much better treated like data stream and applying reactive programming.
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.
That’s due to this excellent post about your excellent abilities and reasoning appearing on HN.
¡Mucha suerte!
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.
Top 5% richest income in UK is €81.3k (£68.4k).
https://www.ons.gov.uk/peoplepopulationandcommunity/personal...
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.
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.
Apply to other companies. In this case it’s not you, it’s them.
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.
Instead OP is a hero who bests the interviewers at every turn with his cleverness.