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 ha…
Then you'll be coding what they expect for the next 10 years. Interviews are two way things.
There’s a spectrum of reasonableness with technical interview questions—the process described in this post is unreasonable, but I think plain old fizzbuzz is about as reasonable as it gets. It’s actually pretty “real world” if the candidate will be writing code in their job. It’s not a trick question nor does it require memorization or study to prepare. You’re not being given 20 minutes to solve something that requir…
The only thing that might be tricky about FizzBuzz is if the person doesn't know about the modulo operator. I can't remember the last time I used it in production code; I use it far more thinking about FizzBuzz than I do anywhere else.
It's worth noting that the original FizzBuzz problem is not "given a number n, print..." but rather "for the first 100 natural numbers, print...". In this formulation, you don't need the modulo operator: you just initialize two counters at 3 and 5, respectively, decrement them each time, and react when either or both reach 0.
> artificially handicapping developers > punishing creativity A similar thing happened to me once in an interview. They said use any language, but were a TS shop. I went with Python, which is hardly esoteric. The interviewers were seemingly unaware of the breadth and depth of Python’s stdlib, and so I demolished their questions in short order. I don’t remember specifics, only that I used heapq for something, and iter…
Google pulled this on a friend of mine. "Solve this in any language you want." Friend solves it in Objective-C. "Oh, except that one." I have shunned every Google recruiter since.
How long ago was this? For at least the last 10 years or so (when I tried and completely failed my first Google interview), Google recruiters have asked what language you want to use in advance. The recruiter would then assign you to interviewers who know that language and can pick questions which are appropriate for that language.
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,... Yep, the exact opposite.
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.
Does it? It isn't what usually surfaces in the US press.
I argue the contrary case - the interview style is pretty reasonable, but the interviewers screwed up the process (and ultimately, the grading). "Adding additional requirements which test a candidate's ability to refactor code" is a pretty good exercise. And it's ok to force candidates people down a specific development path. The problem is that the interviewers didn't do this. They let the candidate pick a strategy…
Looking up the domain shows that OP's write-up was posted on reddit by a similarly named account with relatively little activity, but history going back a good 8 years. Sometimes people just haven't gotten around to setting up a full website with a portfolio, which is fine.
Redditors are highly suspicious [0]. It feels like #thathappened is appropriate.
This is supposedly a NodeJS / NestJS / backend position. If they seem like a good team fit then I would hire someone this good with TS types in a heartbeat. Especially that this is a small company, so if I'm some kind of mid-level decision maker there then having someone versatile is a big advantage for this company. If this would be a huge boring enterprise recruiting for the maintenance of their legacy COBOL.TS bac…
I don't think you'd really like to see any code like that in production. The point of an interview is to demonstrate your talents as they relate to the job. While fiddling with types is fun, it is not really relevant and is the exact opposite of what you should be doing in a real codebase. The person in this interview chose to do something silly to show off. They could have demonstrated their actual TS knowledge but…
The libraries your "production code" depends on have types just as complex as the one in TFA if not even more. Based on this judgement, I'm willing to bet the author has more "actual knowledge" of TypeScript than you.
Try reading the types in popular libraries like zod, openapi-ts, tanstack router, etc.
Google pulled this on a friend of mine. "Solve this in any language you want." Friend solves it in Objective-C. "Oh, except that one." I have shunned every Google recruiter since.
The fact that one interviewer decided someone can't use Objective C shouldn't really give you any confidence that interviewers there are generally unreasonable. I have no affiliation with Google.
That wasn't the only incident, nor is that an accurate paraphrasing of what I just conveyed.
And a few years later, Google basically admitted that their interview process was trash and, in not so many words, claimed that they were going to be less douchebaggy.