When the AI dust settles, I wonder who will be left standing among the groups of developers, testers, scrum masters, project leaders, department managers, compliance officers, and all the other roles in IT.
It seems the general sentiment is that developers are in danger of being replaced entirely. I may be biased, but it seems not to be the most likely outcome in the long term. I can't imagine how such companies will be competitive against developers who replace their boss with an AI.
I would say most of the examples in TFA are deployment diagrams, not (software) component diagrams. For all the flaws of UML, at least it taught us to be quite specific in which aspect of the system we are currently modelling.
The challenge is getting software engineers to learn and use UML properly. As a discipline, we seem to be in a perpetual state of reinventing the wheel, when we have plenty of mature tools and established best practices that people don't care to learn.
A related issue that we, software engineering people, ignore the design-implement workflow other engineering areas successfully use, mainly because that is not agile enoughtm.
Unless teams are bound by some ISO to have design documentation timestamped earlier than feature DoD, engineering process gets flipped on its head and design docs are quite likely to be simply braindumps of some uninterested party rather than formal-ish specifications driving the implementation.
> when we have plenty of mature tools and established best practices that people don't care to learn.
Hyper-fixation on agile and "move fast and break things" attitude is in part to blame here. You can't really put a timebox on "learn how to use mature tooling" or storypoint "design architecture", when only implementation is rewarded.
I have to confess I am guilty of this — I used to just draw some unstructured circles and arrows on a whiteboard and call it enough.
Lately I've been trying to work my way through lots of different diagram types from https://plantuml.com/, and it does help to wrap my mind around the existing options.
There’s truth in what you say and UML has some good ideas, but it’s not the one true way. One problem with it is that even if engineers can read it properly, diagrams often need to do several jobs at once, and communicate something to non-engineers, otherwise you are making diagrams all day!
The various times I've encountered effective UML, it's been an organization's take on how to use it. I can't remember if the UML Distilled book references this kind of dialectic use but it seems like the only way I've seen buy-in for use and maintaining the diagrams as documentation.
I will go against the grain and say I do not consider OPs fizzbuzz solution to score particular well on readability or maintainability. And these were the only two stated core requirements.
The solution is clever and demonstrates solid knowledge of TS. However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers.
Keep in mind that they came up with this solution after the interviewers forbid the use of numeric types and math while still keeping a limit of 30 lines. What do you expect? I found the solution impressive given the circumstances. At this point I would have thrown the towel.
I think the interviewers were looking for the key insight that a number is divisible by 3 iff the sum of the individual digits is divisible by 3. That is easy to verify, even constrained to using single digit data types. To be clear, I am not saying this was a great interview question and I agree the solution OP came up with is impressive.
Since I read the constraint to allow for single digit numeric values*, I guess they are looking for a solution similar to:
function isDivisibleByThree(num: string): boolean {
let mod3 = "012012012012";
let modulo = "0";
for (const digit of num) {
modulo = mod3[Number(digit) + Number(modulo)];
}
return modulo === "0";
}
If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep everything in string representation.
"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"
Using slice twice is pretty clever. That might work.
But my real point is they did have the digit sum insight. Their code was already doing your previous suggestion, and if there's a compact way to slice in typescript types it could be adapted to this new method by replacing SUM_TABLE and changing one other line.
The only difference is that they're doing a sum modulo 9 instead of modulo 3, but both of those work fine.
I see what you mean now, you are right. My only intention was to demonstrate that a TS solution is possible - one that does not rely on the type system but one that still observes all the constraints listed. I think this was questioned by some in the thread (but not you).
I would have failed this question badly. I'm curious, how would you check that without access to any number or math operations? I think I would try something similar to what he did with his sum_table, but that too was disallowed. They're constraints I've never had to deal with, nor seen before.
Math operators like division aren’t native to your (traditional) cpu, they are implemented in code, for example using similar algorithms as the ones taught to us in grade school to multiply big numbers one digit at a time on paper and “long division”.
All math operations can be implemented with bitwise operators, too, i am pretty sure
Likely the interviewer specifically needed the candidate to do that, implement the math, and tried to steer them that way numerous times (no sum table, dont use the type system, no math operators). Thats likely also why they suggest allowing limited use of Google, because they realize many people will need a refresher on bitwise operations. But they don’t want to outright tell you what to search for, they needed to see some resourcefulness. When they suggested OP was cheating they likely didn’t mean it personally and actually wanted to help steer OP towards an acceptable solution. Rather than saying it’s cheating they could have said it avoids the main thing we need to see, or outright say “please implement the low level math from first principles”
In my opinion the candidate showed resourcefulness in their own way indeed, but sometimes its not even up to the person administering an interview for example if they have been given a rubric.
Bitwise operators work on numbers. That's against the rules.
And while division can be implemented as repeated subtraction, you are not going to find any CPUs 4 bits and up that don't have an adder. It would be ridiculous to try to handle addition/subtraction in software.
> Math operators like division aren’t native to your (traditional) cpu, they are implemented in code
If you are talking about tiny microprocessors or old ARM chips, sure. But so are programming languages! They should have really asked him to code his solution in machine code then. After all, that's what you typically do in a NodeJS job :)
Agree. While the solution is impressive, the choice of using the type system severely hampers the ways the code can be deployed. Instead of taking dynamic input, the DATA array must now be encoded up-front in an unexpected number-base and run within the tsc compiler. It limits the number of members in the team that can maintain it. Finally, he was lucky there were no further silly requirements like send a PDF report to the CTO if the number is divisible by 201 and it's a Monday. While i also disprove of the interview setup and their bizarre artificial limitations, in the real world shit also happens and you need to react to it, if you decided to prematurely constrain yourself for the sake of scratching your own itch, you could set back progress for weeks, i see this happen all the times with people choosing the wrong tool for the job or reinventing what already exists in the standard library. Long term maintainability and pragmatism is valued higher by the business.
In my books this choice alone wouldn't be cause for rejection, a good interviewer would question it though and depending on the reaction, it could be. Whether or not that happened here isn't clear. They could also have other even better candidates to pick.
I noticed this in the throwaway comment that the OP made at the end about their prior job disfavoring the use of TS.
I'm not surprised to see that type of sentiment from someone who is (at least self-described) at a more junior level, but still. Often the choice of what language/framework/tool to use on a given codebase or project is dictated or constrained by considerations other than which one is "best" in a technical sense.
Does this suck? Yeah, most of us have strongly held opinions or like to try out new shiny things. But it's a reality of working in this field and coworkers who refuse to learn it can be really hard to work with.
This is also one of those things that can be quite tricky to modify down the line when you need to add a new feature or whatnot. This problem is of course very artificial and it doesn't sound like the interview was particularly well done, but I can kind of see what they were trying to do with "keep code maintainable as it evolves". And even if you are a TS-wizard with a Ph.D. in typing: is it really worth all the cognitive overhead?
This kind of typing in TS is used mostly for getting dynamically typed Javascript codebases under control.
I did this once for a state management library that was considered "impossible to add types to" by the authors themselves, and thanks to this I found several bugs in the library itself, and in our own codebase, due to subtle incorrect usage.
Just the fact that we got autocompletion across the whole app was worth the effort. Even the engineer that was against it ended up praising it.
I'm not the kind of person to say this but: maybe some things are not for everyone. Some people just have different interests and skills. Complicated things aren't less worth just because someone in the team can't understand them.
The FizzBuzz story did go down a rabbit hole, but this sort of TS type extravagance in small doses can help with maintainability. E.g., I wanted to enforce that the keys in a config object couldn’t have consecutive uppercase letters, because they would be automatically translated to camel case when looked up as environment variables (so awsAPIKey would become AWS_A_P_I_KEY, ugh). No need for a lint rule or whatever, you can do that with TS types in a few lines!
>However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers.
If that's their code base, they shouldn't be asking these kinds of questions. They'd be better served by asking to debug a non-functioning component that looks like a real component you'd find in their code base.
Plus readability and maintainability are subjective
It was the whole point of the exercise if I read the article correct
"While the base algorithm is very simple, the point of the exercise is that the interviewer will add new rules to test how you update the code while keeping it readable and maintainable."
Good point. I don't know why that stood out to me so much less than "the interviewer noted that I could even use esoteric programming languages" which to me is code for "go nuts and do stupid fun stuff like writing your whole solution in APL for the extra challenge of it" or other flashy passion-having-shibboleths, which are usually incompatible with readability or maintainability.
Fizz buzz is a toy problem. I think it’s a mistake to read too much into anything but basic programming skills while using it as an interview question. If you want to test code quality and maintainability you are much better off with a more realistic problem.
On the contrary, it shows that the OP has a very good understanding of the type system. Plus, it’s an understandable approach given the code golf nature in which the original problem was presented. (Line length and character limits screams “code golf” to me)
I give lots of interviews and I try very hard to resolve ambiguity in the expectations and requirements. Up front I explain what the purpose of the interview is and what I intend to evaluate. It’s silly to assume everyone is equally able to read between the lines and coding interviews are already a very poor approximation of what a day to day software engineering job looks like, so I try my best to set expectations up front.
But it shows OP is "one trick pony" and interviewer told him it will not be proper approach but then he still went with it.
We also had some freelancers like that and one employee who lasted 3 months - and always it was company owners who wanted to "bring help to speed things up".
Those guys ignored everything and did code the way they knew how to do it. Results were always bad and 3 months guy instead of speeding anything up trashed all team productivity for those 3 months and I guess even 2 more when we had to do the cleanup of his worst inventions.
Two tricks. OP switched from programming to meta programming halfway through.
Also the reason given (not the right tool for the problem) was demonstrably false if we take the OP at face value. They solved it and their solution was robust to changing requirements.
We only know the OPs side of the story, but if we take it at face value it reads a lot like the interviewer wanted to jump them through hoops and they made the best of it. I would have politely declined the interview pretty early on if I was in their shoes.
The interviewers came up with a lot of brain dead rules that they (hopefully) don’t use on their code base.
I could ask you to show me how well and fast you can run while making up a rule that you can’t use your legs and then tell you that you can’t run fast enough to join my sprint team… but that would be idiotic on my part.
"The study found that commuters who turn on the recirculation are exposed to around 80 percent less harmful particles than those who open their car windows."
Doesn't that mean they have 5 times more exposure, not 80% more?
It depends on how they calculated percent change, but looking at the journal article, you are correct. From the abstract...
> Compared with recirculation, PM2.5 and PM10 were higher by up to 589% (Blantyre) and 1020% (São Paulo), during windows-open and higher by up to 385% (São Paulo) and 390% (São Paulo) during fan-on, respectively.
The headline should read 400% more to reflect the 80% reduction. This is a massive failure of the university press office and I think your comment should be at the top.
It seems the general sentiment is that developers are in danger of being replaced entirely. I may be biased, but it seems not to be the most likely outcome in the long term. I can't imagine how such companies will be competitive against developers who replace their boss with an AI.
reply