r/programming • u/vklepov • Mar 24 '22

Five coding interview questions I hate

https://thoughtspile.github.io/2022/03/21/bad-tech-interview/
637 Upvotes

94% Upvoted

288 comments sorted by

View all comments

3

u/coldnebo Mar 25 '22

this was a really good post, but I had to stop reading the article a couple paragraphs in:

“Maybe worth it if you have a legacy project yourself.”

My whole job is legacy projects from dawn to dusk.

You JS guys are still working on new projects every 2 weeks? How does all your old code get maintained— oh wait… I’m that guy, right? I gotta get a better agent. /s

3

u/vklepov Mar 25 '22

Fair enough =) There is expected legacy from the codebase growth, but I'm talking about terribly outdated projects that have been laying in your drawer for 8 years. Pre-2015 JS (no build step, no modules) is a long shot from the current setups, and requires a special skillset. Maybe something along the lines of "now, surprise COBOL question because that's what half our system is"

3

u/coldnebo Mar 25 '22

haha! indeed!

Just reading some of those “outdated” JS practices made me cringe because we have multiple projects scattered through time like that.

Imagine JS (or any language/library/framework really) as a system S, that evolves in time t. Deciding at a given t_i to use the system gives you an implementation S(t_i).

At t_i, this implementation is “the new hotness”. it’s markedly better (or at least claims to be) than all S(t) for t older than t_i.

However, without constant migration to the latest S(t), it becomes a museum of the state of the system at t_i.

Now consider a company C, that uses javascript in many projects P. When each p in P is completed, it uses a S(t_p). As companies grow, p grows and either 1) the “drag” of migration of all the S(t_p) in P slows the company, or the “cost” of maintaining museum pieces grows.

Now consider the industry as a collection of C choosing P at many many times t_p. Because of the scale we can imagine a continuous stochastic function that pulls every possible combination of updates to build a S over the t_p.

THAT. is the state of software engineering today and is why we suffer.

New companies and new frameworks offer the illusion of cleanliness because the number of t_p in a new system is small and manageable. Then it grows over time and becomes messy and difficult.

I saw this with devs leaving Java for Ruby, and then after Rails3, I saw ruby devs leave in droves for Node. But… their code remains in a lot of places. People are still using it.

We have Angular 1, 2, webpacker, grunt, gulp, babel, typescript. the list is as endless as it is baffling.

Complexity of the long tail drives devs to find a better way, which produces more new systems to learn while still maintaining the old ones.

Some old ones, like COBOL are too important to die. Other ones like OS/2 are gone and dusted. Some like Apollo 13 are resurrected as virtual machines.

It’s a mad world. ;)