UAT. It is the first time the end users will play with the system in earnest.

Got it. We always had lots of bugs after UAT. Some were actual bugs, some were user confusion, some were faulty assumptions etc. Our users were the internal business customers in this case.

Sure, in general, if you can hire a junior dev that you believe can be quickly trained, then it may be more economical. But the context of my post was about hiring an "experienced" senior dev. Why not hire a senior dev that can actually write code well? Having to rewrite and understand his obfuscated code months down the line is a cost and nuisance.

You are aware that not every function that you'll write can be googled, right?

This isn't intended to be a comment about you, but just about the question of whether a front end dev should be familiar with computational complexity in general, or about the relationship between dev value and the kind of typical CS stuff that comes up in interviews:

I think I might have had a similar-ish career path to you. I don't have a CS degree, I'm now a little older senior dev type, I often think my practical experience is more valuable than certain CS knowledge, but maybe sometimes I'm wrong about that, etc.

That said, in my career I've done plenty of front-end work (not all web, or JS; and also plenty of back-end work) where performance of algorithms dealing with complex collection-like data structures mattered, and often times more than originally anticipated as a product/company scaled. I do expect a senior dev to be aware of the performance implications of algorithms, and to be able to implement logic efficiently, being thoughtful about when it matters and when it doesn't. It's not always important, but it's important often enough to be important :P

What I don't necessarily care as much about is someone's mastery of the related jargon, or even being able to quickly articulate why some implementation is O(n log(n)) instead of O(n^2). Although it's clear that having the CS background makes it easier to communicate with other devs that share the background, and that has some value. And I expect having a deeper understanding is also useful. It's just that it's also possible to figure out a lot by trial and error over a longer career. I would probably say something similar about data structures. There are some super cute algorithms tricks where I'd imagine being aware enough to know when to google (vs. just writing your naïve version) is as valuable as being deeply versed in the arcana, but a good practical knowledge of many data structures and their tradeoffs -- even when you mostly just rely on standard libraries -- is helpful.

When you talk about "knowing O(n) inside and out" I'm not sure how much you are referring to the ability to speak the jargon and solve hypothetical math problems, or how much you are skeptical of the value of the practical skills which are related. I think the former is more defensible than the latter.

Of course it is. Just because your code works, doesn't mean it's good (eww). Good code can be defined by many things, but efficiency, readability and flow are certainly a few of those properties. If it's one or two function that was written inefficiently, no big deal, but I would puke if the entire code base was riddled O(n^2) or O(n^3) in areas where code can be written a magnitude faster. Those are the type of devs that I want to keep far away from my code base. If you're not disgusted by this scenario, then you're probably a bad dev.

Yeah I think I'm thinking more about the jargon.

My particular situation is I've been a node dev for the last 5-6 years - in an environment where 99% of the time node is tapping it's fingers waiting for back end services to return. So for me code clarity, component scalability and scope flexibility have been pretty much all of my focus during that time.

Code clarity because we're working with offshore devs who might not be experts in closures or middleware and async programming in general. My biggest concern is them accidentally setting something in global scope - which is easy to do in node. Now you might say "Well that's a BS situation get better devs." But that's the world I lived in, so I made it work. And I think there's something to be said for the exercise of developing a framework that keeps devs out of trouble while still allowing them 100% freedom to build the feature they're trying to create.

Component scalability means that creating components 90-100 cause no more pain to the application than components 10-20. By the end we had some 200 components - which could be a full web page, a server-side rendered HTML snippet, or an AJAX rest call. To do this I purposely allowed some redundancy in that a lot of the components shared back end calls and back end logic. If we saw the same gnarly business logic appear more than once we'd just create a utility method. This goes against the standard paradigms of one layer or API services and another for front end components (in a many to many more relationship). But it worked perfectly for us.

I feel like I spent the first 10 years of my programming career trying to build the perfect abstraction, and since then learning when to back off for the sake of code clarity and future flexibility. Nothing is worse to refactor than a big multi-layered abstraction that you suddenly realize doesn't handle a new use case. I've been on projects like that. It's much easier imo to develop with redundancy and factor out obvious code reuse situations later.

Scope flexibility just means that even with 100+ components, it's still very simple to implement cross cutting concerns. I did this with everything being driven from a default properties object, and global middleware hooks at every step of the request/response chain, as well as every step of the back end api calls chain (which are many to one with request). When a new global or semi-global behavior was needed I would just add a new default property, then find the appropriate place(s) in the middleware chain to implement it. It was very simple for me to do, and very simple for other developers to pick up on.

Or since reporting always comes last, we can just snap on a piece of reporting middleware with hooks into the individual reporting components - all of which are superfluous to the actual feature code. Middleware lends itself really nicely to this, hierarchies often don't.

All of this stuff was planned ahead of time when I designed the framework, knowing our situation and the chaotic nature by which our requirements tended to mushroom and evolve.

So anyway it's not like I haven't been thinking deeply about my job the last 5 years. Maybe there's some reason I was highly valued by my company other than luck. I just haven't for the most part been in an environment where highly performant algorithms were needed.

The closest thing I can think of is when we debated whether we should read a hash of 50k zip codes into node's resident memory. We did a bunch of benchmarks and it didn't increase node's internal memory significantly or slow anything down.

Oh yeah, also I wrote custom middleware timers that showed how long each piece of middleware took on average. We did use this to debug code several times when external data sources were taking too long to return, or when middleware that wasn't going to an external data source was taking more than a few milliseconds. The one I remember is we were initiating moment timezone inside a loop that executed some 600 times. It took 2 seconds. We moved the initialization outside the loop and it went to a few millis.

I guess most of my perf debugging was on the macro level like that.

(I think suzzer's reply above to me above maybe clarifies some of this, but since I already wrote this...)

I don't think it's uncommon for devs to be good at some things (even exceptionally so) while being mediocre or bad at other things. I'm not sure "If you aren't good at X, then you're a bad dev" works for very many X, for that reason.

Like maybe someone is very good at conceptualizing the data models and their relationships for some complex project, and good at organizing the implementations to be clean, modular, maintainable, easy to understand, loosely coupled, or whatever else makes for good code organization. Those are also "senior dev" skills I think, and having that person involved early in the technical design for the project is very valuable (IMO), even if they aren't the right person to implement the performance sensitive algorithms needed to make some part of it work well.

Lol your post and mine crossed paths but basically made the same point.

Can you give an example or two? Are we talking short string traversal or potentially long array/hash manipuation, etc?

Yeah. I realized I also tend to do my complaining here, because none of my non-programmer friends want to hear about it being TWO WHOLE WEEKS and I still haven't found a job.

Another thing I just realized. In 4 onsites and maybe 15 phone screens so far, I haven't been asked one node question other than "How much experience with node do you have?" Weird. I've been asked multiple AWS questions, even though I don't have AWS on my resume.

I think I found the source for a lot of these JS interview questions btw: 10 Interview Questions
Every JavaScript Developer Should Know (shhh - don't let them know we know)

He doesnt have examples he’s just spouting crap he heard in his classes

suzzer,

Are you presenting yourself as only a front-end dev specialist? I'm not too familiar with front-end dev work so I can't say CS fundamentals is important to your day to day.

However I think it is 100% important in our day to day backend development and thus share the sentiment that grimReaper has. It's mildly annoying when you have to refactor and clean up poor performant code that senior engineers left behind while having a staff engineer in the background saying "Why don't we use Akka" for a relatively simple problem.

Pension?!?! I'm surprised that's still a thing.

Anyways, if you move to the Bay you can get total comp over 180k easily for sure .

It wasn't a real pension, just an extra contribution to a fund that vests after 3 years I think. After 6 years I had $30k in mine I think.

Full stack. I've always worked on front end and back end, lots of experience with DBs and some DevOps.

FWIW I've never been accused of writing poor performant code. I have had to correct code in code reviews that was looping over stuff an extra time or using an array where a hashtable makes more sense. etc. I think it's possible to look for that stuff w/o having learned O(n) formally, although maybe not in all cases.

I think most of the time I've either been in a framework that makes most of those decisions for you, or in an environment where screaming performance is down on the list of priorities, or both.

I made a silly blog post, mostly from my musings and rantings in this thread: https://medium.com/@suzzer99/how-not...h-1e99d96358c6

And a hacker news link: https://news.ycombinator.com/item?id=17637071

suzzer, lol.

anyway, I think I am a lot like you and I get super frustrated after a couple interviews. but remember there are ppl that ship out like a 1000 resume and search for months on end. you arent there yet.

Suzzer, that was an entertaining read even having heard it all before

It was a lot funnier seeing it all together. And recognizing a lot of things from my own life in it.

People throw around "impostor syndrome" a lot, but man, it can really kick in when you're interviewing, because an interview presents a slice of Computer Guy Stuff it it seems must be just part of life at the place you're interview at, as opposed to whatever trivia the interviewer googled and convinced himself you must know in order to be good at anything at all.

I keep telling anyone who listen that a lot of people who successfully work at our company might not "pass" our interview process, and a lot of the good ones wouldn't put up with it - they'd just say no thanks and move on. Which a lot of our candidates do.

Right now I'm trying to hire this guy and so far they've put him through 2 phone screens and a casual coffee meeting and then I think they're going to make him do a little coding test and THEN we'll have him in for an interview. This might be a good idea for a man off the street rando, but this is a guy we sort of selected for his skill set, and again, if his resume isn't a lie, we should hire him. I would argue that we could skip the trash filters on this guy (the phone and coffee screens) and just get to it.

Suzzer's a good writer.

Amazing stuff suzzer, I'm sure a lot of people can relate!

Wrt the frontend performance convo, at my last company the toxic guy on my team would always suggest changes that made code significantly less readable because it "improved performance" and it was clear he had no idea wtf he was talking about.

We would have a function that loops through an array to spit out Components and a line at the top like "const isActive = list[index] === this.state.activeSelection" and add that as a prop on the Component like "active=isActive" and he would make us change it to "active=list[index] === this.state.activeSelection".

One time I was feeling tilted and did the math to determine exactly much memory he was saving on each render with his proposed changes and it was like 212 bytes to remove clarity from the entire file.

^
Knuth.

On another note, I enjoyed Suzzer's article.