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.
"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.
That seems to be what all restrictions, especially #7, lead to and it is a concept everybody that understands how module works should understand.
> 15. Hardcoding matrices is forbidden.
This was definitely meant to nudge you into the direction of adjusting the base.
The excessive number of rules was really weird, surely they could've just asked you to consider simpler a solution.
> Asked the interviewer if it was OK to rewrite it using only types, she asked her partner and he told me it was but that he couldn’t see the point of it and advised me it would not be the right tool for the problem given that there would be many more rules
I suppose this might've been such a hint.
But I am confident that I would have been very productive in the type of work they actually perform in reality
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.
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!
This doesn’t assess anything meaningful, it’s an ego trip for the interviewer. Ugh.
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?!
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.
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.
The same applies to interviews.
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.)
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.
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 :)
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.
There is almost zero chance that a passable FizzBuzz would be produced in those interviews.
No numerical operations on a fizzbuzz problem? Give me a damn break.
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.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Don't force 'clever' solutions if you're looking for readability, maintainability, changeability, debuggability etc.
On the other hand, our company doesn't do any technical interviews at all, so there's that.
Access to template literals at type-level is available since TS 4.1.
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.
My judgment is that this company has no idea of what they are doing. Not uncommon for companies with under 50 employees.
The rules presented show that the goal is definitely not that.
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.
It is also a cool opportunity to "talk shop" if they go for a strange solution.
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':
...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.
> 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.
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.
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
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.
I disagree, but of course that's entirely up to you.
Neglecting to name them just lets them get away with it.
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.
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.
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”.
As an interviewer who is going to have to work with the candidate in case they get hired, I would worry that this kind of code would be what I'd need to review on a daily basis.
The requirements were weird, but when are they ever not? and read-ability and maintain-ability were clearly stated as priorities at the start..
Still, props for the cleverness.
Like sure the API itself may have string input/output, but under the hood there’s no way it’s not doing integer divisions and modulos.
"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.
I guarantee it’s due to you not living in the Netherlands and not being fluent in English.
No matter if the job offers says they accept remote people, in the Netherlands they really value face to face contact and good and open communication.
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.
> 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've recently completed half a dozen 2-4 hour coding challenges, gotten a perfect score according to the tests provided, and after a couple of weeks, gotten a boilerplate rejection email.
What's the point?
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.
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.
Hope the author finds a good job somewhere that recognises and appreciates their skill.
https://www.richard-towers.com/2023/03/11/typescripting-the-...
I'm not drawing any conclusions, just pointing out the odd coincidence.
Discussion: https://news.ycombinator.com/item?id=35120084
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.
(/s)
My only complaint about your code: in a company you probably want them to approve your PRs, sometimes your peers will code worse than you, so better if the code is less stilted and maybe objectively “worse”, but easy to understand at a glance. but that part also depends on the interviewer.... better to ask first, it's part of working in a team.
I'm sure you'll soon be hired for 50k+.
Suerte.
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.
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.
Sometimes it is possible to be too clever.
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.
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.
In that case, a list of 1000 strings should work just fine. Fast lookup and can accommodate any new rule that comes in.
If they wanted clarity, they would allow for fucking numbers and modulo operator.
They wanted a solution and the candidate produced one.
Or did they just want to know if he knows how to program? Because he also did demonstrate that.
The solution was impressive and fascinating, regardless.
As has already been mentioned in other comments, these are clearly red flags and grounds for not taking the application process further.
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.
... 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.
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."
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.
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?
...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
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.
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...
They WERE expecting a clever solution.
Great job OP, but my eyes bleed.
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.
I would have walked out.
FML.
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.
https://github.com/TZubiri/fizzbuzz2.0
Apologies to the employers that I uploaded it to Github, but I was trying to keep my green squares thingy streak. I didn't upload the requirements so that it's harder to google/scrape into an LLM.
My first note is that, the quality of the code was very high, evidently the code worked and it did so in a manner that introducing changes either required little or no effort. It is unfortunate that the interviewers were annoyed by this rather than satisfied, it reads as if the interview process was written by one person and the interview was executed by someone else and was trying to check some boxes and get to his lunch.
My second note is that, while not incorrect, the approach was a bit academic and certainly harder for others to read. The functional approach is not the most common and definitely not as easy to read as the procedural approach. The interviewer, potentially a coworker, would be reading this and thinking that he would have to read this as part of their job. I don't see any upside to a functional approach here, perhaps in cases with more complexity if I were keen to this approach the pros and cons would be weighted more closely, but it feels overkill.
In a sense it reminds me of the satirical https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... . Where it takes the POV of someone overengineering the fizzbuzz with javalike GO4 patterns.
Third, yes, the requirements are very weird and don't correlate very well with real problems, in some scenarios it forces the developer to do some weird things to the point where you are not sure how someone will evaluate you. If I were an employer I wouldn't be able to distinguish between someone that does 10 ifs in a row because he doesn't know how to use more expressive language constructs, or because he is trying to avoid an array or whatever fucky condition was placed.
Finally, requirement 7, to not use numerical literals and functions, indeed does require to reimplement some basic math, but it was not necessary to implement all of the math. You implemented base 10 addition. My solution just implemented signle digit base 3 addition with overflow. I think overimplementing is a common trap in programming, where you find a solution in 1 minute, and then spend 60 minutes implementing that solution, whereas if you spend some time looking for more efficient solutions, you might cut that implementation and debugging time in the long run.
I wouldn't say that the approach was wrong, it certainly would have bode well with more academic types that value functional approaches, perhaps if they use functional languages like F#, haskell, Scala, Clojure, etc.. But a javascript shop just screams pragmatism and lack of love for the programming language, I don't think you read the room here.
Oh and also, definitely make an AWS account and play with the free tier, just launch a vm (ec2). AWS was hugely influential in terms of design and pricing in the SaaS industry. Remember that AWS was the first big Cloud provider Google and Azure followed, so it's not as important to make an account with the other big cloud providers.
Best of lucks! I'm sure you'll find something.
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...
As a Spaniard I'm curious, why's this?
I think I'm pretty well understood (worked remote for US and NL for years) but maybe just in case I can make life easier for my interlocutors.
- 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.
No, they said they couldn’t see the utility in what he was doing, which is very different than being told that his solution is unsatisfactory.
I have had countless interviews where I’ve been told that they don’t see where I’m going with something, and when I’m finished they admit (after some time processing) that they are impressed that I came up with such an elegant, simple solution. When asked what they had in mind, it turns out they (initially) thought the optimal solution was some contrived, overly complicated thing. If I let everyone’s interjections derail me, I’d never get through most interviews.
Think: have you ever seen a candidate give a crazy, overly complicated solution in an interview? Yes? Well, such interviewees (the ones that write 100+ line Fibonacci functions that look like they might be doing some memoization, but if you squint it turns out they aren’t even using the memo table they constructed) go on to be become interviewers — it shouldn’t be a surprise that many interviewers unintentionally throw candidates curveballs by expressing incredulity in the face of a non-shitty solution. If something is truly a hard “no”, then a “no” must be said — expecting the candidate to guess what’s going through the interviewers head is ridiculous.