Yep. All those extra rules missed the entire point of FizzBuzz - people who have trouble writing code fail at even simple thing like FizzBuzz.
The extra rules presented sequentially and their interactions might have revealed more about both parties, but it's hard to tell without seeing them in person.
Disagree, this is a significant step up from the leetcode-style programming puzzles that other companies do. It doesn't bank on the interviewee knowing the specific trick that makes the puzzle work and instead tries to somewhat test the skills that are more significant for the job at hand like debugging, refactoring and dealing with changing requirements.
That was likely the thought process of the interviewers, however wrong.
FizzBuzz works well enough as a lowest common denominator screening test, but it doesn't scale up. At its core, it's an entirely made up problem with no relevance to anything you may ever do at a job. How do you evaluate requirements for a problem that is not real?
The higher level the skills you want to test, the more realistic your questions have to get.
A real job is often simialar to fizzbuzz in that there is no eligant solutians. There are several solutions but they all have some special case. a real world problem would take you a week to solve though and so we can't give them to you in an hour.
Oh, I guess a few of these additional rules might prove helpful for weeding out people who just memorized FizzBuzz but don't know much more.
However, all of these "don't use the right tools" and "write extremely compact code" rules mostly select for people who are good in code golf, not for people who can solve actual business problems or write maintainable software.
And it seems like this was the only programming challenge in the whole interview?!
This is my takeaway, like maybe 3 extra rules would be worthwhile but by god there is too many, what are you learning here for something so simple as fizzbuzz
I think it's supposed to test refactoring and debugging abilities, but it just didn't work and they didn't know what to do. Anyway trying to argue that 0 is not a multiple of 3 is a big red flag.
Apologies to the employers that I uploaded it to Github, but I was trying to keep my green squares thingy streak. I didn't upload the requirements so that it's harder to google/scrape into an LLM.
My first note is that, the quality of the code was very high, evidently the code worked and it did so in a manner that introducing changes either required little or no effort. It is unfortunate that the interviewers were annoyed by this rather than satisfied, it reads as if the interview process was written by one person and the interview was executed by someone else and was trying to check some boxes and get to his lunch.
My second note is that, while not incorrect, the approach was a bit academic and certainly harder for others to read. The functional approach is not the most common and definitely not as easy to read as the procedural approach. The interviewer, potentially a coworker, would be reading this and thinking that he would have to read this as part of their job. I don't see any upside to a functional approach here, perhaps in cases with more complexity if I were keen to this approach the pros and cons would be weighted more closely, but it feels overkill.
Third, yes, the requirements are very weird and don't correlate very well with real problems, in some scenarios it forces the developer to do some weird things to the point where you are not sure how someone will evaluate you. If I were an employer I wouldn't be able to distinguish between someone that does 10 ifs in a row because he doesn't know how to use more expressive language constructs, or because he is trying to avoid an array or whatever fucky condition was placed.
Finally, requirement 7, to not use numerical literals and functions, indeed does require to reimplement some basic math, but it was not necessary to implement all of the math. You implemented base 10 addition. My solution just implemented signle digit base 3 addition with overflow. I think overimplementing is a common trap in programming, where you find a solution in 1 minute, and then spend 60 minutes implementing that solution, whereas if you spend some time looking for more efficient solutions, you might cut that implementation and debugging time in the long run.
I wouldn't say that the approach was wrong, it certainly would have bode well with more academic types that value functional approaches, perhaps if they use functional languages like F#, haskell, Scala, Clojure, etc.. But a javascript shop just screams pragmatism and lack of love for the programming language, I don't think you read the room here.
Oh and also, definitely make an AWS account and play with the free tier, just launch a vm (ec2). AWS was hugely influential in terms of design and pricing in the SaaS industry. Remember that AWS was the first big Cloud provider Google and Azure followed, so it's not as important to make an account with the other big cloud providers.
I love FizzBuzz as an interview question and then dive into tail recursion and compiler optimization. I learned a lot from candidates. I miss my interviewing days.
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.
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?
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.
Ideally yes, but most people in corporate settings don't communicate clearly. So if they have a culture of dropping hints, and you don't take them you're not going to do well at the company.
It's not good, but it's an accurate reflection of the work environment.
Then don't say" "the interviewer noted that I could even use esoteric programming languages but advised me against because there would be lots of rules that would be hard to follow"
if someone starts careening through the task using brainfuck, they ain’t thinking like a senior dev at day job i.e. simple, clear, easy to follow and maintainable code writing.
i don’t care how clever you are. i need to know you’re not going to rewrite the frontend in your first week because of a “big brain” moment [0]. using python or something simple without being told to helps me feel like you won’t do that, and that i might be able to trust you on day 0.
Then ask. Ask the candidate if he has experience in some teams, ask what he would do if someone else was challenging his technical decisions. Ask him what he would do if he was ordered to do something which he believes was a bad technical decision.
Instead of talking the company relies on easily misinterpreted hints that he might or might not be someone able to work in a team. People can be both self confident and able to create a cheeky solution and be sociable people with decent team skills.
If your hiring process relies on psycho analysis of the candidates, it probably will not work very well.
Agree as a general rule BUT candidates can (and some WILL) lie to those questions. See how they react naturally although in a simulated scenario can give you a better idea.
But you should do both things, probably in 2 different interviews.
There is plenty of research on interviews and how to prevent them - or so the interview trainers hr made me take classes from before I was allowed to interview anyone.
disscussions here universially show no evidence anyone knows it exists much less what it is. I at least know it evists but I don't know how to find it
I think the lie is in thinking FizzBuzz is going to give you any insight into such matters.
Put aside your paranoia and just talk to your candidates. Ask them thoughtful questions that invite thoughtful answers. Probe gently to get at more challenging questions. Trust your ability to discern when they're BSing you.
Even in the candidate's own telling, it is obvious that they misread very strong signals from interviewers. I've sometimes been that overly clever programmer and I've had to deal with it too, on the one side it's great that they bring energy and brains, but it is exhausting. At some point when moving fast you just want to have some people that you can go "hey just fix this bug wouldya" and trust that they're not going to come back with a clever but convoluted and inefficient hack.
Exactly. On one level I loved this solution but it’s definitely “clever code” and, unless there is a particularly strong requirement driving it (e.g., performance), I don’t particularly like clever code in production systems.
The problem of “What does this do?” is prevalent enough, and occurs often enough under pressure, without adding excessive niftiness into the mix.
Also, this still properly fits the "you're interviewing the company as well" paradigm. If the author wanted a company that values cleverness or can deal with people who go unbeaten paths, they now know it wasn't the right place.
Normally I’d give the company the benefit of the doubt for the reasons you point out, but not in this case. If you’re asking increasingly convoluted/unrealistic/impractical questions, you can’t complain that the response wasn’t practical.
It gives off strong “your answer might be correct but it’s not on my answer key so I’m marking you wrong” teacher vibes. Avoid at all costs.
The interview was also very clever and unconventional.
"Numeric types, number literals and their associated methods and operations are forbidden".
If this is how the interview behaved, I'm pretty sure this is a company that expects developers to write code in a certain way but doesn't really know how to guide them.
Kudos to the author, but shame on the interviewer.
I probably wouldn't have hired the candidate, at least for the position as stated.
My reasoning is that the company advertised a position for a senior engineer with 4 years experience. Leaving aside title inflation and whether someone with 4 years experience is actually a senior engineer, and leaving aside the really dumb test, that position requires communication skills, common sense, maturity, and just generally knowing what's going on. A candidate who misreads the situation in an interview so badly that they can't take the interviewer's unsubtle hints is going to mess up other communication within the company, has likely never been on the other side of an interview before, and is at risk of allowing the kind of "clever" code that destroys companies.
Again, this is only a problem for a senior engineer. I want junior and mid-level engineers to be clever and enthusiastic. Senior engineers are meant to understand that I have five interviews this week and their attempt to channel Aphyr[0] is going to make my life harder when I want to talk about their thoughts on maintainability.
If you want to assess communication skills, common sense, maturity, just generally knowing what's going on, or any other senior engineering quality, I advise you steer hard away from FizzBuzz.
Yeah I was thinking it was extremely well written. I want to be on their side after reading it, but I've encountered enough individuals that are completely different people online than how they are in real life. Especially in the way they communicate and how they speak.
All that being said, I would not be able to take the OP's side until I heard the interviewers side of the story as well.
The only thing I can think of is they were fielding for them to say "that's not possible" and push back, potentially as a way to gauge if they would reject unreasonable client expectations or something.
Then it's a stupid way to check for it, because it was possible and trivial enough to implement in a short time frame with a "rewrite" in the middle and no attempt to meassure pushing back in other ways when the first one failed
> 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.
"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.
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.
> and if you'd change tack because of the question alone, it would seem like you really lack self-confidence.
Or because the candidate realized that they've messed up, and by dropping the issue can at least salvage the next XY minutes of the interview by not going down the wrong rabbit hole.
"Could you tell me more about this?" and "Are you sure about this?" are invitations for providing the rationalization for your answers. "I'm not sure that's a good idea" is a very unsubtle, but polite way of hinting that the you have gone way off the map.
As an interviewer, I want my candidates to succeed. I want them to put their best foot forward. I've asked my question over a hundred times, and I've seen many ways that people have solved it, correctly or no. If I'm giving them this suggestion, it means that I know that they are going down one of the many, many wrong garden paths.
I know, I have now spent enough time in the Anglosphere to understand this cultural code. But I do want to emphasize that, yes, if you only know English as a language, that that subcontext is not obvious.
In France, professors would literally say "You are wrong." as an invitation to explain yourself better. There are only 500km between London and Paris, but the culture behind these words is the complete opposite.
That phrase in English has a strong connotation of the recipient screwing up somehow though, so I’d probably say “that’s not what I was looking for in this case. Try something else.”
In the UK, it’s not at all cut and dried - depends more on the personality of the person saying it. Could be lazy assertion of control, an attempt to help or an implied challenge.
I also think the interview setup and management were poor.
> Yeah, it's an English thing. A literal translation in Dutch would mean "explain yourself here",
That's just patently untrue. The literal translation is "ik denk niet dat dat een goed idee is" and the better translation would be "dat is niet de bedoeling".
If I got told in an interview "dat is niet de bedoeling" I'd be damn sure to rework my solution because they're clearly trying to coax me towards whatever they're looking for. And in a way it is actually a nice thing of them, because they could just say nothing and fail me out of that round of interviews.
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.
The way you figure these things out is talking about them. Plenty of people like to solve challenges in weird ways and might even see the suggestions that it is inappropriate as a challenge.
>There are not really multiple ways to read "I don't think that's a good idea" in an interview. If your "technical depth" leads you to an inappropriate solution, it doesn't matter if it's right. Just because this solution worked for FizzBuzz and all their rules does not mean it's maintainable. It's obvious to most senior people that such a weird solution is brittle and overkill, even if they can't come up with a rule to break it. But here's a simple one: Output FizzBuzz if all the rules are passed, except if there is a database entry matching the number. Good luck solving that with some bullshit type theory, and good luck to anyone who comes behind this guy to add that rule to his Rube Goldberg code.
"What set of tools would you choose to build <normal software project>? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?".
Both are infinitely more telling about the candidate.
Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
>For example, I worked with one mostly self-taught guy who wanted to rewrite everything in a niche compiled language, including things that really should be done in scripting languages like Python or shell. Thankfully nobody else let him do that. But deep down I think he didn't accept that he was wrong, and on multiple occasions he expressed that he thought the average person on the team was woefully inexperienced. In fact, it was him that was woefully inexperienced, because he didn't understand how inappropriate and even flat-out wrong his solutions were.
I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
>Plenty of people like to solve challenges in weird ways and might even see the suggestions that it is inappropriate as a challenge.
That's absolutely not the way to approach an interview. "Let me try to do things the exact way you clearly don't want, just to see if we can." Is the candidate going to try to do their next job this way? What are you going to do when their egotistical attempts to solve problems in clever ways despite your advice and even instructions bites YOU?
>"What set of tools would you choose to build <normal software project>? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?". Both are infinitely more telling about the candidate.
I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most people. If you're talking about someone with no working experience and who claims to be self-taught, you really have to make them write code.
>Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise. He was in the mood to do an academic exercise, and that's what he did. The interviewers seriously don't know what he will do in the workplace. That's why they're trying to make him write some code in such a way. Self-taught people are more of a risk in that they often overcomplicate (or oversimplify) things.
>I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
Good for you? I'm not talking about silly problems. I'm talking about someone who wanted to rewrite our build system in a compiled language, and our Python unit test driver in a different compiled language. He wanted to use inappropriate "fun" languages at work. I'm not categorically against using interesting new languages and tools, but when there is ZERO benefit to doing so and nobody else knows said languages, it is not to be done.
>The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them. The candidate wanted to show off his knowledge of type theory despite pretty obvious hints that the interviewers didn't want that. That means he has bad social skills or else he has an ego issue. The fact he blogged about it in such a way to brag about his solution suggests he does have an ego problem. There's also a healthy chance that the whole story is fiction, just to advertise himself as a self-taught "genius" who is turned down for being "too good" lol.
>The whole point of the interview is to get hints about the candidate.
Which it didn't accomplish at all, because the interviewers refused to do the single most important thing. Actually talking with their candidate about these things. Instead they are relying on psychoanalysis to divine some secret meaning in his actions.
I am not arguing that your interview shouldn't try to figure out the personality or professional approach of a person, but that this particular interview made it near impossible to do so. Simply because they refused to talk about the things they wanted to know.
You make it sound so much more mysterious than it is. The candidate rejected polite social cues to not go down the path he did. He came up with an oddball, brittle, and undebuggable solution. They said what they wanted for this fairly simple problem. It's not a guess at some secret, it's a simple observation that the candidate is not right for the job.
> I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most people. If you're talking about someone with no working experience and who claims to be self-taught, you really have to make them write code.
The choice is not limited to made up toy problems vs not testing coding skills at all. You can give them real problems to solve.
> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.
Hahaha, and how exactly do you write an 'industrial-grade' FizzBuzz? ;)
> The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them.
Oh but it is. If I were to ask you, the expert, to draw a blue line with red ink and then attempt to draw conclusions from your behaviour based on that question, could I ever get a valid assessment of you? If a test is faulty, so are its results. Garbage in, garbage out.
Interviewing is no trivial task. It is an attempt to test how well someone will do a thing without having them actually do it. By definition, that is impossible. Still, we can try to get good enough results by minimising the number of differences between our test environment (interview) and production (the job). That will involve:
a) making the interview environment resemble the job as much as possible (no hazing, minimal pressure on the candidate, writing code in and IDE instead of a whiteboard, etc.)
b) presenting the candidates with coding tasks that match what the company does on a daily basis (take a suitable bug you had in your codebase, touch it up a bit with more issues, have them fix it; pair program with them to add a new feature to your codebase, etc.)
I strongly disagree. I’ll take the opportunity to wildly diverge when the chance naturally presents itself. It’s how I can show the interviewer that I’m a creative person who comes up with interesting alternatives and can also be fun to work with.
For example, I was asked to do FizzBuzz once. I laughed, said we’ve both done this dozens of times, and would they like to have fun with it? We ended up building this wild thing with recursive Python generators and itertools and a state machine or something. I don’t remember the details a decade later, except that the interviewer thought it was hilarious, and I taught them some Python (“wait, that part there, does that actually work?!”, and they paused me to test it on their laptop).
I got the job.
As a candidate, you’re interviewing them, too. If the person is a martinet who can’t look deviate from the script even slightly, and you have other options, do you really want to work with them? That sounds joyless.
Sometimes going off script is OK but that is not what they wanted here, it seems. Besides I guess that if this interview ever happened, the "solution" might not be the reason that they weren't hired. But the numerous hints that the candidate got suggest that they wanted a normal solution. Asking someone to deliver a solution within some reasonable constraints is not "joyless" and disregarding these constraints on purpose over and over is not "smart."
> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.
Wrong. They put in silly rules like "Max of 30 lines" and "Mutating array operations are forbidden". These do not describe industrial-grade rules. They describe an academic, esoteric challenge. And then when he provides them with it, they punish him for his creativity by adding in bullshit rules retroactively e.g. "Hardcoding matrices is forbidden."
You just sound upset that he's able to walk the walk but you WANT him to be just a bullshitter.
Yeah as an interviewer if the type-heavy solution wasn’t what I wanted to look at I would’ve asked the candidate to pretend like they don’t understand the type system and adjust the solution accordingly.
Actually though if they wanted to test for debugging ability, presenting some real code with defects would have worked a lot better than this.
That last part is key. Way better than FizzBuzz from scratch, best interview results I've seen come from giving a candidate a pre-made solution or architecture document that technically works but with glaring issues and just talking about their opinion on it, coding or pseudocoding optional for presenting solutions.
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.
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.
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.
> I wish all the best to him, but reading between the lines is a useful skill regardless of this specific situation.
I disagree. This is not a fair ask, especially for a programming position. Programming and maths in particular puts a lot of emphasis on attention to detail.
If he can write it in X, and there's no rule against it, and the job gets done well, then there is no issue. Arguing any further of it is unproductive. He's applying for software development, not for public relations.
> "I don't think that will be a good idea" is not a suggestion, it's an order.
Then it should be a rule. "Reading between the lines" sounds like an excuse to me for bullshit criteria. It should be written, it should be explicit, and it should be known. If the interviewer is uncomfortable writing it down as a rule then that tells me they KNOW that it's too silly or pedantic. This whole idea of unwritten rules is a double standard designed to weed out neurodivergent or autistic individuals who are more than capable of fulfilling job requirements and, to me, seems like a potentially illegal form of discrimination that violates disability civil rights laws.
Yeah 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.
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.
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.
> 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).
The more time that goes on, the more I think as a community we should unashamedly be name-dropping anywhere that has poor practices, bad comms, or bad behaviour.
Neglecting to name them just lets them get away with it.
Do you think you'll make it to the interview stage of the hiring process if the interviewer looks on your personal website and finds that you wrote an entire blog post calling out your last interviewer by name? I would not risk inviting such a person.
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.
50k EUR/year for me would be like 2900 EUR/month after all taxes. Monthly expenses in the part of Spain I live in are ~800 EUR (rent + food + electricity + water + 1Gbps internet).
2900 - 800 = 2100 EUR to do whatever I want with. Even if I decide to put half of that into savings, that's still ~1000 EUR to spend freely, and any unspent money would go into savings too at the end of the month.
Or in other words: With a salary like that I would be able to pay a family member's full monthly expenses if they are in rough times, and still have leftover for myself.
Fair enough I’m just saying I live in Germany and just entered my first software position and get 73k, and I don’t live in Berlin or anything. I suppose in Spain living expenses are much cheaper. Your monthly expenses including food are less than my rent. Tho I still think I have more than 2100 left over after expenses
Yeah to be fair I don't live in a big city or any touristic location where monthly expenses could easily double, but it's still nice and comfy enough that I don't plan on moving even if money weren't an issue.
Including healthcare, vacation days, maternity leave, no calls after work or during vacations, not being on call unless paid for and is on the contract, unions,...
Maybe you just have no experience with Silicon Valley or just hate it for whatever reason, but the only thing in that list that doesn’t apply to SV is the unions… Not sure the point you’re making.
As someone that lived two years in Switzerland and still goes there regularly, don't forget how much things actually cost, the high value is artificial given how much even basic supermarkt good cost.
Prices in most supermarkets are high, but I've come to understand this as most consumers being price-indifferent for groceries, at least in Zurich, because it represents little of their overall costs anyway. If you want to save on groceries, Lidl is way cheaper than Coop/Migros, but many consumers prefer convenience. That's not even including the case of people living in Basel / Geneva who buy groceries in Germany / France such that Swiss prices don't matter to them.
i have only seen few offers from switzerland, and i didn't see anything that stood out. i am only looking at remote jobs though. that may skew my perception. i did notice that switzerland had a higher average compared to the rest of europe when looking at statistics.
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.
I used to give fizz buzz with zero additions. Just write me a fizz buzz in c#. We didn’t actually want to take up a lot of the interviewee’s time. There were other tests, tests better than any programming tests. They had to take like one for SQL and one with nothing but logic puzzles, the latter of which is most indicative of whether a person will be competent at the job.
Fizz buzz just lets me see their coding style (single letter variables, lack of curly braces after ifs, comments, platform - console, web, service) and whether they’re willing to allow simple mistakes into their finished product. So many mistakes.
But it’s the least I can do to get some information out of a candidate who is already overburdened by the process.
This article describes everything that's wrong with tech hiring these days. There is zero evidence that success on these arbitrary programming riddles have any correlation with success on the job, and yet we force candidates through a gauntlet of completely unrealistic brain teasers solving problems that they will literally never have to solve on the job.
I've recently completed half a dozen 2-4 hour coding challenges, gotten a perfect score according to the tests provided, and after a couple of weeks, gotten a boilerplate rejection email.
i agree. this solution is to clever for its own good. but those requirements were essentially asking for a clever solution. if the challenge can't be solved without being clever then it is the wrong challenge.
this interview tells me that the candidate is smart and knows typescript well, but it doesn't tell me if they can write code that is clear enough so that a junior can understand and modify it. because the latter is the reality of work. a year from now, a junior will be asked to adapt this code to say replace 3 with 7 or something like that, and they will probably not be able to it without having to rewrite all of it from scratch.
How much of the article did you read? They were looking for a senior, with more than twice the experience the poster has. Being able to pump out algos is only part of the job.
While there a solution is clever, it’s not terribly maintainable and likely didn’t fit the bill.
Beyond that, things like soft skills matter for senior roles. The author can write, there’s no denying that, but we don’t know how well they can explain the why of their solution. It’s very likely the interviewers wanted more traditional functions that were unit-testable.
I've worked for companies in NL whose tech interview wasn't nearly this involved but the wages offered were comparable or better; I seriously doubt any of the skills asked or demonstrated in the interview would actually be necessary for this job, not when it's just node which in all likelihood means it's mostly REST like APIs and some business logic. (I'm making some sweeping generalizations here)
To me, the rules given to you are pure gatekeeping. The fact that even after they had given successively more restrictive rules for what should be a trivial program they then verbally restricted you further confirms this. I would question whether this was actually an interview for a real job or not but in any case it's not you it's them.
Asking a trivial question is a simple way to test a person’s basic skill but also more importantly his ability to communicate and work with others who may not have the same level of expertise.
If you use it as a chance to make a mockery of the interview process/interviewer then perhaps that is not a good idea if you actually want the job.
The interview deserves to be mocked. It wasn't someone being asked a few trivial questions, but 45 minutes of being asked to go through ridiculous hoops.
If you are concerned about a candidates team skills. Talk to them, do not interpret it based on, how they engage with some stupid coding puzzles.
Well, there you go. Typescript can only get you so far. Unless you want to be a low-paid code monkey, time to learn natural languages.
ps. I have many Spanish colleagues, and I have a hard time understanding them in general (when they speak English). Only one other nation is worse, the French...
It may not help that there are more of them, and of course, among themselves they speak Spanish. One of them then turns to me and asks something switching to English, he keeps his speech mostly unchanged (speed, enunciation, pronounciation), except he is putting supposedly English words one after the other...
The Spanish accent in English is --simply put-- atrocious. I've met many Spaniards, and only a few had a clear, understandable accent. Even academics with British or US post-docs may not speak clearly. Nor flight-attendants, for that matter (juecom odi flai tu ásterda).
I only know a few French, but I had a colleague who (although not of the French nationality) was born and raised there, and apparently was taught English literature through reading Les Hauts de Hurlevent. Yes, Wuthering Heights, in French.
If this coding test was what they used to assess the quality of candidates, I would say that the author of this article dodged a very large bullet by not getting hired.
I've got a hard time imagining they were going for a solution other than you adjusting the base.
That seems to be what all restrictions, especially #7, lead to and it is a concept everybody that understands how module works should understand.
> 15. Hardcoding matrices is forbidden.
This was definitely meant to nudge you into the direction of adjusting the base.
The excessive number of rules was really weird, surely they could've just asked you to consider simpler a solution.
> Asked the interviewer if it was OK to rewrite it using only types, she asked her partner and he told me it was but that he couldn’t see the point of it and advised me it would not be the right tool for the problem given that there would be many more rules
> I've got a hard time imagining they were going for a solution other than you adjusting the base.
I agree that this is probably what they were going for, but it still seems a bit ridiculous that the conversion from numbers to the chosen representation is not subject to the same rules (i.e., you can call `.toString(15)`, and this definitely uses numbers under the hood!). If this is allowed, then you could also encode your numbers as the string "{n % 3}{n % 5}" and be done with it. Or if they wanted a unique encoding, "{n}{n % 3}{n % 5}" would work too!
The toString wasn't used in the solution. It was used in creating the solution. Encoding the numbers as your given string exceeds the max length of an encoded character per the rules.
The problem is that adjusting the base selects for two kinds of people:
1. People who have come across that trick before.
2. People who have a lightbulb moment in the 45 minutes of the interview.
Now, given that someone has passed the test, what is the probability that it is because of 1 or 2? The VAST majority who pass the test will fall into category 1.
The test manages to have both low sensitivity and low specificity. Well done!
Most likely, the interviewers are completely unaware that the solution is only obvious to their uncurious minds because someone else told them the answer. They don’t appear to have an understanding of where quantum-leap ideas come from, or how to foster them.
I would have thought to create the matrix on the fly with a loop. Not as clever as changing the base, of course, but wouldn't that have been acceptable?
Normally, you learn during high school that when you take any exam, you should not reply with the best or smartest answer, but with the answer the teacher expects.
If you are interviewing for a job - the "answer the teacher expects" can tell you a lot about the company you are potentially going to work for, as can the exam which you are given to prove your worth.
But that was the correct answer after all: screw the interview, have fun trolling the interviewers (you won't get the job anyway), then write a cool blog post and post it here. There is already someone in this thread asking for contact.
What do you think they expected when they said not to use numbers? Is there a "normal" answer to that? It seems like a very freeform kind of crazy restriction to me.
459 comments
[ 35.1 ms ] story [ 7744 ms ] threadThis doesn’t assess anything meaningful, it’s an ego trip for the interviewer. Ugh.
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.
A few have a trick or insight but I haven’t ran across those in interviews.
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?!
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.
(/s)
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.
You are interviewing them too.
I would also have hired the candidate.
It's not good, but it's an accurate reflection of the work environment.
if someone starts careening through the task using brainfuck, they ain’t thinking like a senior dev at day job i.e. simple, clear, easy to follow and maintainable code writing.
i don’t care how clever you are. i need to know you’re not going to rewrite the frontend in your first week because of a “big brain” moment [0]. using python or something simple without being told to helps me feel like you won’t do that, and that i might be able to trust you on day 0.
expectations on seniors are higher
[0]: https://grugbrain.dev/
Instead of talking the company relies on easily misinterpreted hints that he might or might not be someone able to work in a team. People can be both self confident and able to create a cheeky solution and be sociable people with decent team skills.
If your hiring process relies on psycho analysis of the candidates, it probably will not work very well.
But you should do both things, probably in 2 different interviews.
disscussions here universially show no evidence anyone knows it exists much less what it is. I at least know it evists but I don't know how to find it
Put aside your paranoia and just talk to your candidates. Ask them thoughtful questions that invite thoughtful answers. Probe gently to get at more challenging questions. Trust your ability to discern when they're BSing you.
The problem of “What does this do?” is prevalent enough, and occurs often enough under pressure, without adding excessive niftiness into the mix.
I do still like the solution though.
Also, this still properly fits the "you're interviewing the company as well" paradigm. If the author wanted a company that values cleverness or can deal with people who go unbeaten paths, they now know it wasn't the right place.
It gives off strong “your answer might be correct but it’s not on my answer key so I’m marking you wrong” teacher vibes. Avoid at all costs.
"Numeric types, number literals and their associated methods and operations are forbidden".
If this is how the interview behaved, I'm pretty sure this is a company that expects developers to write code in a certain way but doesn't really know how to guide them.
Kudos to the author, but shame on the interviewer.
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
FizzBuzz is the mind-killer.
All that being said, I would not be able to take the OP's side until I heard the interviewers side of the story as well.
But if you're doing anything unique, or experimental they might be a great fit.
Most of us are doing the second.
Anyone saying "you gotta check divisibility without math" on the job would get laughed out of the room.
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.
"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 after living in the UK for a bit, in the UK that is most likely an order.
Or because the candidate realized that they've messed up, and by dropping the issue can at least salvage the next XY minutes of the interview by not going down the wrong rabbit hole.
"Could you tell me more about this?" and "Are you sure about this?" are invitations for providing the rationalization for your answers. "I'm not sure that's a good idea" is a very unsubtle, but polite way of hinting that the you have gone way off the map.
As an interviewer, I want my candidates to succeed. I want them to put their best foot forward. I've asked my question over a hundred times, and I've seen many ways that people have solved it, correctly or no. If I'm giving them this suggestion, it means that I know that they are going down one of the many, many wrong garden paths.
In France, professors would literally say "You are wrong." as an invitation to explain yourself better. There are only 500km between London and Paris, but the culture behind these words is the complete opposite.
I also think the interview setup and management were poor.
That's just patently untrue. The literal translation is "ik denk niet dat dat een goed idee is" and the better translation would be "dat is niet de bedoeling".
If I got told in an interview "dat is niet de bedoeling" I'd be damn sure to rework my solution because they're clearly trying to coax me towards whatever they're looking for. And in a way it is actually a nice thing of them, because they could just say nothing and fail me out of that round of interviews.
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.
>There are not really multiple ways to read "I don't think that's a good idea" in an interview. If your "technical depth" leads you to an inappropriate solution, it doesn't matter if it's right. Just because this solution worked for FizzBuzz and all their rules does not mean it's maintainable. It's obvious to most senior people that such a weird solution is brittle and overkill, even if they can't come up with a rule to break it. But here's a simple one: Output FizzBuzz if all the rules are passed, except if there is a database entry matching the number. Good luck solving that with some bullshit type theory, and good luck to anyone who comes behind this guy to add that rule to his Rube Goldberg code.
"What set of tools would you choose to build <normal software project>? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?". Both are infinitely more telling about the candidate.
Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
>For example, I worked with one mostly self-taught guy who wanted to rewrite everything in a niche compiled language, including things that really should be done in scripting languages like Python or shell. Thankfully nobody else let him do that. But deep down I think he didn't accept that he was wrong, and on multiple occasions he expressed that he thought the average person on the team was woefully inexperienced. In fact, it was him that was woefully inexperienced, because he didn't understand how inappropriate and even flat-out wrong his solutions were.
I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
That's absolutely not the way to approach an interview. "Let me try to do things the exact way you clearly don't want, just to see if we can." Is the candidate going to try to do their next job this way? What are you going to do when their egotistical attempts to solve problems in clever ways despite your advice and even instructions bites YOU?
>"What set of tools would you choose to build <normal software project>? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?". Both are infinitely more telling about the candidate.
I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most people. If you're talking about someone with no working experience and who claims to be self-taught, you really have to make them write code.
>Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise. He was in the mood to do an academic exercise, and that's what he did. The interviewers seriously don't know what he will do in the workplace. That's why they're trying to make him write some code in such a way. Self-taught people are more of a risk in that they often overcomplicate (or oversimplify) things.
>I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
Good for you? I'm not talking about silly problems. I'm talking about someone who wanted to rewrite our build system in a compiled language, and our Python unit test driver in a different compiled language. He wanted to use inappropriate "fun" languages at work. I'm not categorically against using interesting new languages and tools, but when there is ZERO benefit to doing so and nobody else knows said languages, it is not to be done.
>The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them. The candidate wanted to show off his knowledge of type theory despite pretty obvious hints that the interviewers didn't want that. That means he has bad social skills or else he has an ego issue. The fact he blogged about it in such a way to brag about his solution suggests he does have an ego problem. There's also a healthy chance that the whole story is fiction, just to advertise himself as a self-taught "genius" who is turned down for being "too good" lol.
Which it didn't accomplish at all, because the interviewers refused to do the single most important thing. Actually talking with their candidate about these things. Instead they are relying on psychoanalysis to divine some secret meaning in his actions.
I am not arguing that your interview shouldn't try to figure out the personality or professional approach of a person, but that this particular interview made it near impossible to do so. Simply because they refused to talk about the things they wanted to know.
The choice is not limited to made up toy problems vs not testing coding skills at all. You can give them real problems to solve.
> The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise.
Hahaha, and how exactly do you write an 'industrial-grade' FizzBuzz? ;)
Obligatory: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
> The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them.
Oh but it is. If I were to ask you, the expert, to draw a blue line with red ink and then attempt to draw conclusions from your behaviour based on that question, could I ever get a valid assessment of you? If a test is faulty, so are its results. Garbage in, garbage out.
Interviewing is no trivial task. It is an attempt to test how well someone will do a thing without having them actually do it. By definition, that is impossible. Still, we can try to get good enough results by minimising the number of differences between our test environment (interview) and production (the job). That will involve:
a) making the interview environment resemble the job as much as possible (no hazing, minimal pressure on the candidate, writing code in and IDE instead of a whiteboard, etc.)
b) presenting the candidates with coding tasks that match what the company does on a daily basis (take a suitable bug you had in your codebase, touch it up a bit with more issues, have them fix it; pair program with them to add a new feature to your codebase, etc.)
Some concrete examples:
- https://rachelbythebay.com/w/2022/03/19/time/ (it suffices to read the first two paragraphs)
- https://quuxplusone.github.io/blog/2022/01/06/memcached-inte...
- https://blog.jez.io/bugsquash/
For example, I was asked to do FizzBuzz once. I laughed, said we’ve both done this dozens of times, and would they like to have fun with it? We ended up building this wild thing with recursive Python generators and itertools and a state machine or something. I don’t remember the details a decade later, except that the interviewer thought it was hilarious, and I taught them some Python (“wait, that part there, does that actually work?!”, and they paused me to test it on their laptop).
I got the job.
As a candidate, you’re interviewing them, too. If the person is a martinet who can’t look deviate from the script even slightly, and you have other options, do you really want to work with them? That sounds joyless.
Wrong. They put in silly rules like "Max of 30 lines" and "Mutating array operations are forbidden". These do not describe industrial-grade rules. They describe an academic, esoteric challenge. And then when he provides them with it, they punish him for his creativity by adding in bullshit rules retroactively e.g. "Hardcoding matrices is forbidden."
You just sound upset that he's able to walk the walk but you WANT him to be just a bullshitter.
Actually though if they wanted to test for debugging ability, presenting some real code with defects would have worked a lot better than this.
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.
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.
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.
And the reason for the hesitance was a worry that it would have trouble with future rules, which turned out to be completely unfounded.
That was forbidden, check the rules given by the interviewer.
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.
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).
I disagree, but of course that's entirely up to you.
Neglecting to name them just lets them get away with it.
Apply to other companies. In this case it’s not you, it’s them.
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.
that sounds like a major exception. the average for juniors in germany is 50k or below.
More to you, but that isn't a common entry level, at least for companies whose main business isn't selling software.
Yep, the exact opposite.
Compared with which location?
My experience is that you're way better off in Zurich than, say, London where you'll end up having similar costs. https://livingcost.org/cost/london/zurich illustrates that. Zurich seems similar to San Jose: https://livingcost.org/cost/san-jose-us/zurich.
Prices in most supermarkets are high, but I've come to understand this as most consumers being price-indifferent for groceries, at least in Zurich, because it represents little of their overall costs anyway. If you want to save on groceries, Lidl is way cheaper than Coop/Migros, but many consumers prefer convenience. That's not even including the case of people living in Basel / Geneva who buy groceries in Germany / France such that Swiss prices don't matter to them.
Top 5% richest income in UK is €81.3k (£68.4k).
https://www.ons.gov.uk/peoplepopulationandcommunity/personal...
https://github.com/leoffx/fizz
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.
The requirements were way stranger and quirky than the solution, and wouldn’t really lead to any production-ready code…
Lots of comments complaining about the code completely glossed over the requirements.
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.
Why invite him then?
>Beyond that, things like soft skills matter for senior roles.
Then talk. Ask him. Psychoanalysis of the solution of a stupid brain teaser will not answer your questions.
If you don’t mind me asking, are you a senior level engineer?
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
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.
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.
I only know a few French, but I had a colleague who (although not of the French nationality) was born and raised there, and apparently was taught English literature through reading Les Hauts de Hurlevent. Yes, Wuthering Heights, in French.
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
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!
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.
Hope the author finds a good job somewhere that recognises and appreciates their skill.
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 same applies to interviews.
Learn to blend in if you want to function into society.