441–450 of 460 posts
The author really looks like a junior, though unquestionably smart, dev. What he wrote isn't enterprise. Enterprise is spaghetti - the first version would be simple number array and division, and once numbers became strings and math isn't allowed, instead of division just run over the digit characters doing simple modulo 3 math in non-math way - as required - using say if/case as matrixes aren't allowed ( "3456" -> 6…
Earlier quoted context omitted.
I admire terse code too. I can relate. I'm also old. But: > we had 10KM HDDs so every char counts. Ten kilometre hard disk drives? It can't be 10kB. Hard disks were never that small. Floppy disks were never that small. Maybe it's not hard disk drives. It can't be length of tape, or of mercury delay lines. I am mystified.
I was just joking, sorry not a native english speaker. What I meant was that disk space with code text was never an issue on modern PC, so optimizing for that doesn't make sense.
It’s not your technical skills. 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.
Respectfully, if someone puts "remote available" on a job description and expects you to know they don't _actually_ want those applicants due to specific nuanced cultural differences, those people can go fuck _all_ the way off for wasting my time.
It frequently implies to some degree that face to face meetings can be held and that languages and cultures mesh.
Earlier quoted context omitted.
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.
It was more than 10 years ago. And the candidate was from Apple, hence his currency in Objective-C.
Another good friend worked at Google for some time after that, and reported a pretty toxic evaluation regime that pitted employees directly against each other. He eventually left.
Earlier quoted context omitted.
Absolutely. “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 functi…
what's the use case for call and apply? in 6 years i think i've written .call once
These don't come up a ton in modern code bases in part because of the advent of arrow functions, and in part because of the general trend towards FP / declarative programming in JS/TS and away from OOP / "class" use and thus less need for managing "this" throughout an application. Also most of the time if you really need a utility function it's easier to rely on a bulletproof dependency library like Ramda/Lodash/Underscore... concerns about bundle size notwithstanding.
Another use case is if you need to use array methods on array-like things (this comes up sometimes with DOM manipulation). These data structures are iterables but lack the native array methods like map/filter/reduce etc. If for some reason you can't/don't want to create a new array from your data structure to operate on you can do something like Array.prototype.filter.call(myNodeList, filterFunction). Also not terribly common in modern codebases, but useful to be aware of!
I will go against the grain and say I do not consider OPs fizzbuzz solution to score particular well on readability or maintainability. And these were the only two stated core requirements. The solution is clever and demonstrates solid knowledge of TS. However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers…
Agree. While the solution is impressive, the choice of using the type system severely hampers the ways the code can be deployed. Instead of taking dynamic input, the DATA array must now be encoded up-front in an unexpected number-base and run within the tsc compiler. It limits the number of members in the team that can maintain it. Finally, he was lucky there were no further silly requirements like send a PDF report…
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.
Earlier quoted context omitted.
Respectfully, if someone puts "remote available" on a job description and expects you to know they don't _actually_ want those applicants due to specific nuanced cultural differences, those people can go fuck _all_ the way off for wasting my time.
Respectfully, "remote available" means little more than coming into the office daily isn't a requirement. It frequently implies to some degree that face to face meetings can be held and that languages and cultures mesh.
Earlier quoted context omitted.
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…
I believe that if the candidate is able to whip this up in 30-60 minutes they know their shit around some math and TS.
I think most problems are not this low-level and I think the questions about data management (DB, data structures in memory and on disk), API design, integration with services and other higher-level skills are more important.
So compared to the baseline "JS" at least this candidate effectively showed off one extra interesting and hard skill, while solving the problem flawlessly, and not folding under pressure, and so on.
In the text the candidate explicitly asked for permission to go with types. And if the interviewer wanted to revoke that permission they could have, but they did not, they gave some ambiguous advice.
> If you really wanted the job, would you behave like that in the interview?
Yes. I don't want to work for a company where creativity is a liability.
Interestingly, unlike many in this thread I would've avoided hiring this person based only on the code example. This code is almost unreadable to me, certainly to most on my team. I would request changes it if it was a PR going into production (ignoring that the problem itself is made up). The code I would've liked to see would be easy to read, easy to follow, and would make me understand the underlying rules that ma…
The code being hard to read may be partly a consequence of having to bend over backwards to fulfill the absurd requirements. No numerical operations on a fizzbuzz problem? Give me a damn break.
Fully granted that I'm not familiar with TypeScript, but I find it hard to believe that code like the below is more readable to anyone than the equivalent `for num in nums` loop.
type FizzBuzz = T extends `${_}${_|""}${_|""}` ? `${Fizzer}${Bazzer}${Buzzer}` : "";
type Folded = T extends [infer Head, ...infer Tail] ? `${FizzBuzz}${Folded}` : "";