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?
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
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.
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?
I feel like this is completely backwards. To me this feels like 'I love using this kind of hammer so let me find all the jobs where I can use this hammer I love to use.' I'm actually not interested (at least not primarily interested) in that. I'm more interested in what are you building? What problems are you solving?
I'd rather search by that and then see what their tech stack looks like and filter down to the ones matching my interests and the tools I like using. Heck, there may be a company that I'm really interested in what they're doing but I may not have a lot of experience with their particular technology set. I could reach out to them and express my interest in what they're doing and see if it might make sense for me to join them. Focusing on technology feels like putting the cart before the horse.
I don't care one mote about solving problems. I program because it's fun and I'm good at it, so I have no space for bullshit MBA puff like "solving problems" (it's not) "making people's lives better with technology" (it never has or will). So for me working in a place where I get to use the tools I enjoy is more important than whatever flavor of the week justification is given for the rent we are seeking from and new problems we create for consumers.
This is an interesting take to me, because it seems to be how many of my coworkers work. It's not how I think about things.
I enjoy technology, but it's hard for me to just focus on tech without a purpose for using it. All of the projects I'm proud of aren't because of the tools I used. Instead, I'm proud that I delivered something useful.
Yet, I still completely agree with your statements about "MBA puff". I've been on projects where they extol how valuable a project is going to be and it doesn't stand up to a minute of scrutiny. Other projects would be valuable, but never get into the hands of real users.
On the projects I'm proud of, I was directly working with someone who actually would benefit from the project. There wasn't a question of whether it was worth it. The users weren't puffing up the project to be more than it was. They have a job to do and I'm helping them do it better. Interestingly, this also meant that they didn't care how I approached the problem.
The real sweet spot for projects is where working on interesting tech goes hand-in-hand with delivering something useful.
It's unfortunate that this cynicism is so widespread, because technology actually does solve problems and make people's lives better. I suppose I'm lucky to be working in a domain, accessibility for blind people, where this is obvious. But I'm sure there are many other such areas.
There are a ton of jobs that are tool-heavy, and the "solving problems" only applies to a small percentage of the team.
Some problems should not exist at all and only exists because of the tooling chosen.
Example: A friend of mine works at a company that is running their business on some clown-ish cloud infrastructure, and their SREs have to basically re-invent the wheel to work around the limitations of the cloud vendor the management has chosen (for example: no virtual machine autoscaling, in a cloud environment). Somebody at that company is certainly doing "creative work" and "solving problems" with code, but not those SREs.
It can, but parent's cynicism is very understandable if one looks around at the hot new exciting technology of today and compares it to the hot new exciting technology of decades past. Pretty much the entire high-paying tech space right now is either solving non-problems or actively creating and promoting problems.
Its not so much that I need someone to try to sell me that I’m changing the world instead of making a paycheck. But I definitely would rather clean toilets for a cause I love than work with cool tech on a project I don’t believe in or that doesn’t ever go anywhere.
When I was younger my family was really big into riding ATVs. At first it was cool, but then I started to realize we were just going to drive in the same circles at the same parks forever and it lost all meaning to me. ATVs are cool, I still think they are, but without a reason to ride one I can’t imagine spending a weekend in a tent driving around in circles. At the same time I know plenty of people who live for that, so I recognize that we’re all looking for our own things.
What is a plumber paid for? You tell him you'd like a sink installed somewhere and he installs it. He isn't paid more if the sink is used to wash the hands of surgeons operating on orphans or never used it all. He is paid on the basis of, you want a sink and he knows how to install them.
It seems to me that doing things on demand with no regard for purpose should be the domain of machines, not humans. Of course, robotics isn't yet advanced enough to allow us to meet that ideal in the physical world. But in the software world, the demand for programmers that merely crank out glue code, without understanding or caring about what it's for, should shrink, if it's not already.
I know why they are doing what they are doing, I'm just not paid for it. If I was paid by value produced rather than my skills I'd demand far greater control of the business, complete transparency and would refuse tasks that don't generate sufficient value. That just isn't the relationship most companies want, they would like to dictate what I work on and pay a flat rate for it. You can't have it both ways.
Sure, but if everyone was able to install a sink the price of getting a sink installed would fall considerably. That indicates to me that you are paid based on the rarity and difficulty in gaining the skill, not the value of the problem itself.
You don't get paid for solving the problem, you get paid for transforming the problem using software such that people become dependant on software to "solve" it. Now you can charge them for it. You can also insert software into places where no problems have been yet identified, make them dependant on it and then charge them for it.
This guy knows how business works. If everybody think hard enough, software is not needed in lots of situation. The market is all about forced solution, probably plus some network effect, social value yada yada that keep it alive.
> your example is daily infrastructure people already have
Of daily infrastructure people already have, because someone dared turn it into software?
> You only need a few of them.
I guess we can keep email, but we should strip all the software layer from waste management plants, or the archiving systems of national libraries and museums, or the operating systems that support the browsers we're typing this from, or the avionics from passenger planes, or whatever you decide is the right number of software applications.
> whatever you decide is the right number of software applications
You hit right on the nail, so I don't generally disagree with you.
This is how business works, there is no number! Consumerism works the same kind of way.
[Shifted-goal] Also I don't want to stop or reduce it either, I just want more quality of software, not some VC-pipedream-hype driven software.
> You don't get paid for solving the problem, you get paid for transforming the problem using software such that people become dependant on software to "solve" it
Yes, the entire software industry is akin to crack dealers.
As a "Python Developer" this is for me. There are some demand for specific language based developer instead of purpose based developer. Case in point - Scala. There are Data Engineers and there are Scala Developers. There are some overlap but if you are an employer looking for Scala help, you need a Scala Developer and not someone who tolerates Scala in their stack.
For me, Python always provides the shortest path to solving problems programmatically. It is the best thing you can use to prove a concept before you build something. Python sits appropriately in the middle of pseudo code and something performant. I get to solve unique problems rapidly. That fits my philosophy. If you are comfortable in using something why not get paid to do that. I am open to learning new things particularly Typescript but I am just comfortable in a Python environment more than a JavaScript or any other environment.
The catch with all that is that I am more fitted for contract roles as opposed to full time jobs. For the employer hiring based on tech introduces too much rigidity. They want contractors and experts for that.
Correct. The languages I learn outside of my day job are languages that teach me new ways of thinking about problems: Lisp and Haskell are two that come to mind. Do I expect to get a job where these languages are used? No. I learned them because it gave me insights for becoming better at my craft. It makes me better at solving problems using the languages actually being used where I work.
I think your are underestimating the time it takes to become proficient in a technology stack. You can't build anything until you learn it. When you are proficient, is nice to be able to come into a completely new business environment and be somewhat productive. It feels like validation that you are actually an expert in something. Now it is commendable and a great growth experience to come in as a newbie with no knowledge of the business and the technology, but still a hard pill to swallow for most.
> It feels like validation that you are actually an expert in something.
You're an expert in knowing how to use a hammer. I think it's the wrong focus. Instead we should be focusing on whether you're a framer, a carpenter, a roofer, etc. It's your expertise in solving particular kinds of problems that makes you valuable, not in knowing how to use a particular tool.
As an aside, some people have noted this is not true for IT contractors - as they are oftentimes brought in explicitly for their expertise in a tool. I would argue that's a reason why a lot of people don't want to be a contractor forever.
> I feel like this is completely backwards. To me this feels like 'I love using this kind of hammer so let me find all the jobs where I can use this hammer I love to use.' I'm actually not interested (at least not primarily interested) in that. I'm more interested in what are you building? What problems are you solving?
Same for me. I can learn whatever tech stack you're using (if need be). I want to know about your business, your product, your future.
I generally disregard those requirements if it's a job/domain/business I find interesting. Current gig had requirements I didn't have. And now we have completely different ones from when I was hired.
They shouldn't, though they have few choices. They don't want to admit they chose the wrong tools for the problems, and can we disagree with them .. generally.
To me this feels like 'I love using this kind of hammer so let me find all the jobs where I can use this hammer I love to use.'
Most craftsmen and artists I know are very particular about their tools and much prefer using their own tools that they've lovingly maintained and gotten to know all the quirks of rather than some random tool someone hands them.
As someone who is more of a domain expert who knows a fair bit of programming, rather than an expert programmer, I would certainly be reluctant of taking a job where I wasn't allowed to use the tools I prefer for solving problems within that domain.
It’s almost like people choose companies based on different factors.
Some are coin-operated. Some are language/stack-driven. Some want fast-growing; some want slow-and-steady. Others like small companies. Others like large stable companies.
There exist professional mechanics, and there exist oil-change technicians. The professional mechanic has literally hundreds of tools, of dozens of different types. The oil-change tech has maybe a dozen tools that he uses in an average week. The professional mechanic studies his craft and learns about suspension, brakes, engines, transmissions, electrical, fuel delivery, spark delivery, sensors, ecus, interior parts such as window motors, air conditioning, fuel pump replacement, diagnosis, etc. The oil-change tech can find the oil filter, screw it off, and screw on another one. Sometimes without even over-tightening it.
The "Wordpress Guru" is far more akin to the oil-change technician than to the professional mechanic. He likely does not understand HTTP, let alone TCP/IP, he might google CORS when he has a problem, likely copies code from Stack Overflow without understanding it, and has heard of Big O notation but has never had to apply it to his work. Honestly, I'm probably closer to that extreme than I would like to admit, but I do strive to understand ever line of code I'd be git-blamed for, and think that I understand two levels below the technologies that I do use on a day-to-day basis.
At the same time, I'm sure there are mechanics that love Ferrari, know everything about every Ferrari ever made and don't want a job where they don't get to work on Ferrari's. I wouldn't see that as sign of lack of professionalism.
I think it's more like a professional mechanic wouldn't be happy being oil change technician. A professional mechanic may love Ferrari's, but also jump on the chance to work on Porsches if that means working on a GT Racing team.
I work a lot with Nim, for my own projects. There aren't many jobs out there for Nim just yet. I'm going to release some of tech I've built as Open Source (https://nexusdev.tools/). With any luck that will help to build up the Nim community, which in turn could help jump-start the Nim job market.
DocUI, the back-end SDK that uses Flutter for the front-end, is actually multi-language on the back-end. But I also have a back-end web-framework built on top of Jester that handles user management. Another example is an ORM that generates Nim data access files (which is Postgres only at the moment, but other DBs could be added).
Type Raleigh or Durham or North Carolina into the region selector and it gives bad or no results, but navigate over NC on the map and there are jobs listed
Yeah, I'm not going to assume Raleigh, NC is more important than all the other Raleighs in the world. But it is bizarre that I can get Fort Raleigh City, NC and not the actual capital of the state.
Pretty neat tool, but the region search needs work.
I like the idea but it seems rather US-centric currently. I'm finding it almost impossible to filter by London, UK - a whole load of other locations containing 'London' across the US show up instead. Similarly, trying to reposition the map to London requires a lot of scrolling of the map, because I can't zoom out far enough to see enough of the globe. As it stands it's very difficult for me to use unfortunately, but hopefully it won't be too hard to improve the UX for an international audience.
I run a Discord community [0] around software internals for folks interested in hacking on databases, compilers, browsers, emulators, etc.
There's a jobs channel there where folks post jobs on these topics there. If you've got these kinds of software internals jobs you're welcome to join and share. If you're looking for these kinds of jobs you're welcome to join and browse.
Unlike OP's site this isn't tied to particular technology/languages/frameworms but tied to particular interesting topics.
the job postings are augmented with the dev-stacks (from servers, databases, languages, infra, thirdparties), the job headlines de-b#ll-ified using ML, and the users can apply fast via github / linked or direct via the jobposting on the companies website, every job posting has some salery range. it carved out it's niche in the austrian dev community.
I am not sure where this data is coming from. I live out in the country, 15 minutes from a town of 2000 people, an hour from any real tech jobs. And there are results near me. From places like CyberCoders - almost as if other remote software folks just had a job through them once so their home address shows in the database. I suspect there is some serious validation needed of this data set before it will be useful.
That's little solution introduced to real problem .. looking at job description these days makes me shifting to a product guy using tech I think is appropriated, not just based on "large pool of developers", and fall into inferior and inappropriate tech for solving problems.
My younger and naive self used to over value the tech stack of a company, nowadays I don't care, there's way more important issues than the specific tech stack chosen like people, organization and processes.
A strong engineering team pushes for meaningful and well organized requirements collection and encoding, documentation of the business domain, values (meaningful) testing and is strongly oriented towards providing the best developer experience possible.
Languages and libraries do play a part in developer experience and satisfaction, but they are generally way less important.
If I'm a Go developer, or changing jobs because I want to use Go, of course that it is in both mine and my future employer's best interest to set expectations if I'm gonna work on Go or on ASP.NET.
"sure milansm, you'll work on Go code. we just need to support this ASP.NET codebase for a little bit and then you can lead our migration to Go. I promise.".
In this market, employers are saying anything to get folks in the door. They're scrambling for workers, and a lot of times it's because their codebase is shit and folks are leaving in droves, so they dangle carrots to get folks to support their decaying crap.
