Hacker News new | ask | show | jobs
by lnxg33k1 1539 days ago
I feel like lately something weird is happening to the industry. I interviewed some people lately during the past few months to fill a couple of react jobs, and it looks like people is really giving a lot of fucks to the tech stack and technology they use, like I feel like there are now a lot of people who are knowledgeable of everything but master of nothing and also they keep learning framework and library without caring about software principle, architectural or design patterns or security best practice, We interviewed a tech lead that we hired for react lead and she didn’t know even what owasp 10 are, and my coworkers said yeah that is not something they’re supposed to know which chills by skin , so maybe this post is not fully related to the thing, but maybe is it not cool anymore to work solving challenging and meaningful problems or as long as you work on the last framework you’re good? Is it a developer issue or the industry is being fucked up by hiring managers or recruiters ignoring portable developers Knowledge and just caring for how many years you’ve used $nextCoolFramework?
10 comments

What are the modern, accepted software principle, architectural or design patterns, and security best practices?

What is the best source on these topics?

I’m not being cheeky here. I’m genuinely interested, because I see these terms thrown around a lot without reference.

Not everything has to be "modern" (a term which also gets thrown around a lot without reference) to be useful.

With regards to design patterns I would recommend the Gang of Four book on the subject. It's old (to the point where it makes me feel young) but still relevant as most of the patterns you'll see in the wild will be described there or be slight variations.

For security I've heard people describe the OWASP Top Ten as the software equivalent of the Ten Commandments. It's been around for almost two decades and is also still very much relevant today, perhaps even more so going by the comment you replied to.

I know a lot about security, but I did not know about owasp10 before today. I knew about all the listed security issues in owasp 10 and how to mitigate them, but not about the list itself. Perhaps look at what candidates actually know instead of $nextCoolList?
Well, personally when I ask about something with an acronym is just for shortness, but of course if you see the candidate a bit worried unable to give an answer for that specifically then I usually try to help saying something on the lines of (in this specific case), "So if I say XSS or session hijacking does anything comes to mind?" So like I don't just ask about OWASP and then move on, try to help, so I am pretty sure that it was not just the list, but yeah also I made an example of the one we hired, but I've had candidates knowing a lot of stuff but not knowing what a decorator was, so I was making a point more specifically about concrete frameworks versus principles
Yep, most of those items baked into framework already, plus practices we've heard about in the list, but not need to know the name "owasp".
This probably gets at the heart of why people [misguidedly] ask about OWASP or anything other specific thing. They want to know if the candidates knows the principles, which they should, whether they're baked into all the modern frameworks or not. This might be an unpopular opinion, but I don't care how "good" your code is, or how quickly you write it, or how nice of a person you are, if you have no idea what SQL injection is or how to prevent it. Yes, day to day you might be using an ORM. But at some point you may be asked to do something with strings being passed around as SQL commands and I don't want a bomb to go off because you only know JS because that's what React is written in, you only know SQL via your ORM of choice, etc.
This is why people are complaining about whiteboard interview, it's the same thing. Even if I have computer engineering background, I'm not going to remember my Campus Network Design class, because in daily basis, we don't have to remember that, but we know the knowledge exists, we just loop it up when needed.
I have been working for over 20 years in the industry. Been doing Java, Python, Angular, Vue.js, MySQL, SQLite, Mongodb, Elixir, Php, Nodejs, and now Go. Ansible, Terraform, bash scripting. Mobile development, backend, frontend, data mining. E-commerce, fintech, edtech, media streaming.

I don't know Rect (besides implementing the todo list they have in their frontpage), but I can learn in a few weeks to become proficient on it. Don't hire "React developers", hire "good developers".

I think the problem is that you’re hiring for a “React” lead. If companies are being for <specific framework> developer, they should be be surprised when they get applicants who are more focused on frameworks than fundamentals.

On the backend at the Principal level, I’ve see the opposite thankfully. Most companies don’t seem to care about the specifics—the current buzzword with is that they care that I can design “web scale” systems (regardless of whether the company actually has web scale problems—but that’s a different problem).

> (regardless of whether the company actually has web scale problems—but that’s a different problem)

Indeed. So then they'll go ahead and design "web scale" solutions to non-existent problems. I quote web scale since in the majority of the cases I've seen, the solutions don't actually seem particularly capable of handling massive scale but since they don't need to, it never gets tested.

Worked with one company with this ginormous logging and analytics pipeline which consumed most of the AWS budget, but the actual data flowing through it amounted to a handful of million entries per year. Yes year. At that scale, the wise solution is grep and awk on a $5 VM.

Solve the problems you actually have and the ones you can project to having in six months. Don't solve the problems you wish you'll have in ten years.

> like I feel like there are now a lot of people who are knowledgeable of everything but master of nothing

In general that is not necessarily bad, it can be a good thing.

> they keep learning framework and library without caring about software principle, architectural or design patterns or security best practice

My guess here is that it is a way to get into more interviews. Many job openings today lists a ton of libraries and frameworks that you should have experience with, thus the market reacts(!) accordingly.

> Is it a developer issue or the industry is being fucked up by hiring managers or recruiters ignoring portable developers Knowledge and just caring for how many years you’ve used $nextCoolFramework?

I don't really know whose fault it is, but I can tell you from experience that if you present yourself as having good -even excellent- experience and knowledge of the principles, the practices, and the patterns, and having similar experience with $similarFrameworkA and $similarFrameworkB, but not with $thisParticularFramework, then "you're not quite what we're looking for". And the opposite is common too. If you do have a couple of years experience with $thisParticularFramework you're good to go. It doesn't matter whether you don't know how to do anything else outside of that.

This is something people don't often want to admit, or sometimes even discuss. I'd guess it may be related in some way to another rarely admitted fact about the industry: There is a lot of wasted effort and resources. Particularly in certain types of projects and companies, the overall productivity is extremely low.

From my experience hiring and mentoring, I reckon a lot has to do with how (overly) complex stacks for web application development have gotten. Thus people often having to learn in a very top down way, learning the very high level tools first and have little understanding of what lies beneath. There is also at least the perception that there are a ton of those high level things you need to understand for being a "fullstack" dev and it is also this top layer that actually moves fast, whereas the fundamentals move in a much more glacial manner. People chasing changes and additions instead of deepening their knowledge.

If I compare that to my own experience learning web dev in the early 2000s on my own. Make a html file with some css and ftp it up to a server. First version done. Add some JS, some PHP, then a database. Eventually move from vanilla code to different frameworks and languages, move from a Linux box to some cloud services, slowly start working with more complex systems and different paradigms. The whole process was very iterative and I feel I have gotten a lot of transferable knowledge on the way.

Of course this is perfectly possible to do these days as well, but it is not what I see happening or being widely encouraged in communities or fostered within companies. It seems more about run this and that generator script, click this button to spin up the managed services to run it on. See, it is so easy, so no problem. Creating hundreds of dependencies and layers of abstraction with practically no idea what they do. I had people wanting to learn programming from zero asking me to help with issues with their docker setup before having written a nested for loop.

I'm definitely not against those "modern" tools, they can be an awesome productivity boost if used well in the right context, but I can't help but often feel reminded of the good old Jurassic Park quote when it comes to tech stack decision making: "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should"

Playing devil's advocate, does it matter if she doesn't know what OWASP is specifically, if she has good security principles and designs secure systems? Saying "What's OWASP 10?" seems like a heuristic question rather than just trying to investigate what you're actually looking for - are they going to write shitty insecure code. I can say plenty of people will right secure code having never heard of OWASP, and plenty of people write terrible code with OWASP cheat sheets saved to their desktop.
Ironically you were hiring "React" lead, which is still popular today as "CoolFramework" despise there are better solutions out there.
Tangent here, what are better solutions?
If you need framework: Svelte, Imba, Elm.

If you only need a view lib: uhtml, lit-html

Might have to do with the fact that front end space is inundated with “frameworks” and superfluous versioning. At the same time why bother sticking with a framework that’s going to be outdated in two years because the development team moved on to something else entirely?