I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.
Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t seen this be a productivity killer.
Also, with the shocking frequency I’ve seen, code based need more tests. Have them write tests! That’s a fast way to get up to speed.
One other point: senior engineers in one code base may have an uptick if a “junior” in another depending on existing quality, circumstances etc.
I think organizations are lying to themselves that they can only hire seniors. It’s a myth. Just like 10x developers.
I need hard data to be convinced otherwise not anecdotal evidence. All the hard data I’ve seen points in the opposite direction of any anecdotal information I’ve come across.
There are so many volumes of books devoted to these topics alone that I think most ideas around developer productivity without the firm backing of numbers are mostly hand wavy and myths we tell our selves to feel better
We had juniors for easy new features, tests, anything that is small and isolated.
Functional tests are a must. I would also say that in this day and age integration tests are also a must. I don’t think there is any domain now where you are commonly interfacing with only your code end to end, some level of integration is happening and that should be tested too.
Nothing’s perfect because we are human, I will say though that having proper functional, unit, and integration tests for a codebase I don’t see this issue crop often and when it does it becomes apparent, and then you write a test for that and then you have coverage for that etc.
Software is an organism composed of changing structures, after all.
These are just some things I’ve been apart of. I’ve gladly been apart of this before.
You can as I said also have them write tests or as others noted have them write smaller features or other things in isolation.
Also how green are we talking is another question entirely. Some tasks are better fit for people with maybe practical experience in another tech stack but need to get up to speed in a new language etc.
My overall point which may not have been clear is that there is always a way to get an engineer up to speed without killing velocity. It’s a management failure to say you can’t hire junior engineers.
It’s one thing to need someone that’s a domain expert, but often I see “senior engineer” === “No ramp time” and I think that’s just a lie management tells themselves to justify not coming up with a good on-ramp plan for new engineers
Are they going to contribute as much as a senior dev? No, but they can still contribute in significant ways. They can still fix bugs and find issues in your system, bring a fresh perspective on design and take ownership over smaller parts of the codebase.
The reason why junior developers jump ship is because companies aren't willing to even promote people. So of course developers (of all levels!) are going to leave after 2-3 years when it's the best way to actually get paid and not taken advantage of by stupid CEOs that would rather have high turnover than a happy workforce.
One even hired McKinsey to analyze the issue. If they had given away the McKinsey fees as raises it would have solved the issues easily.
When did “not able to solve leetcode-nuclear puzzles while singing and tapdancing backwards”, become “junior developer”?
The OP is talking about “sky-high” levels of (interview) competency, and you immediately jumped to the conclusion that anything less must be juniors who need training to wipe their rears.
I think I see the problem in this field.
I’ve met “junior developers” who couldn’t translate simple business requirements into code.
The stereotypical “developer” who couldn’t do FizzBuzz.
Well, first...you were replying directly to a post that was talking about whitebord/algorithm questions and how they’re out of control. On an article about same. So my answer is: ”because I bothered to read the post to which you were replying.”
Regardless, if you haven’t done an algorithm interview in “over 20 years”, you either haven’t changed jobs, or you’ve had a unicorn career. Either way, you’re clearly not representative of the vast majority of devs. True or exaggerated, your experience is so exceptional that it isn’t worth discussing.
Not everyone’s career has been the r/cscareerquestions “learn leetCode and work for a FAANG”.
These tests are ubiquitous. If you honestly haven’t hit them, you’re a unicorn.
I’ve asked around about my coworkers experience over the years because I had never heard of algorithms style interviews until three years ago when I started reading HN and r/cscareerquestions.
I thought all interviews were soft skill, language trivia, diagramming models and architecture, and explaining past projects.
And one of he best ways to make sure your senior people always have something new and interesting to tackle is having them mentor junior people to take over the things seniors are bored with.
Corporate America is infamous for HR policies where they will only give current employees a maximum percentage raise while hiring new people at market rates (salary compression and inversion). Even if you as a manager want to keep good developers who were juniors but have now leveled up, your hands are tied.
However, most of the people I know who start looking for another job don't do it because they suspect there's more money somewhere else. They do it because they've grown less happy with the job.
Turtles all the way down. Once a game shifts into zero-sum, it's not gonna stop getting played until it collapses.
Normally, I would say to avoid entering into any zero-sum games. But the world has made a sharp turn towards zero-sum over the past 5 years, so that advice has rapidly become impractical in today's climate.
Wisdom shall lead again at some point, but I don't clearly see when. Threads like this one though are a promising sign.
Also if you are going to lose employees because you can’t match competitive salaries than i would say you are losing them if all other things are equal.
In another words this greatly oversimplified version of events here only allows for you to come to that conclusion and dismisses how an organization could adopt different practices, values and foster organizational culture that combats these issues differently which I think training is an essential component.
I actually think this is a good argument for licensure like civil engineers etc have to have, because one thing it mandates is required training hours (among other reasons I won’t diverge into here for the sake of staying on topic)
You can debate what that should look like and I encourage that but I see little downside to forcing employers to acknowledge that all employees may need some time just to train on new things and different concepts away from the day to day work. I know this is a little bit of a tangent here but it’s something I see so often at every level of an engineers career path yet organizations so rarely set aside adequate time for it.
Why wouldn’t a developer leave for more money and more learning opportunities?
2. If that’s HR policy and you request for an exception and it’s denied, that may be a sign to start asking more questions.
3. You’re assuming that’s HR policy. Again, example dictates you have one option without actually thinking through how an organization could position themselves differently. Of couse salary is a component and rightly so, but at a certain point it’s just not everything
Think of it this way: lifestyle, ancillary benefits, “perks” etc can be all valid reasons to stay a place that treats you well and displays real loyalty (which is often displayed in more generous long term planning like big 401K contributions and fully paid health insurance for the family, open source software time etc). Can’t say I would just arbitrarily leave that for an extra 20% because that 20% can be easily eaten in other ways. Not to mention transparently knowing that your job won’t evaporate if the economy gets soft is a win. All this salary gloating is fine until that happens. 1999-2001 was not a fun time to be in the upper band taking pay cuts
Let’s not grossly oversimplify this. I’m never going to say don’t maximize your value, you should, I’m saying there is more than one (salary) way of doing that.
FAANG or not.
Oh and one dirty secret FAANGS don’t tell you? They happily underpay on salary once you’re in, or freeze you into a specific department etc. it’s not all roses.
I’m nowhere near west coast salaries but just big city America salary for context. At my age now in my mid 40s, married, making about the average salary of a top IC in my market, with the big house in the burbs (again not bragging, any developer with 5-10 years of experience could easily afford it), with the white picket fence and 2.1 kids, yeah 20K more wouldn’t make a difference in my lifestyle.
But, when I was just starting out in 1996 making $33K a year, $20K meant a lot.
But salary compression and inversion are real phenomena where HR policies don’t allow for raises to keep up with the market.
I was working during both 1999-2001 and 2008-2011. In 2000, it was very much just a dot com thing. If you worked in corporate America as a standard Enterprise Developer you weren’t really affected.
2008 was rough, but still there was no such thing as job stability. Companies were laying off left and right. I survived three rounds of layoffs - barely. But even then you could find contract gigs if you were the perfect fit.
That is to say I got extremely lucky. I know that. My takeaway since (I’ve been a software engineer for ~10 years now) is that the way I was treated as a junior is what I described throughout this post, and my mentors were the ones that drilled home what the hidden costs were taking jobs based on salary, how to properly evaluate benefits etc. I learned a boat load.
So I want to preach to developers and companies alike that things can and should be evaluated differently and to avoid pitfalls that are easy in this industry
I’ve worked at smaller companies by choice or at smaller divisions of large companies (occasionally). One developer salary is a major cost and can add to their revenue.
If you only have a few openings, you better make them count.
For instance, I know that some features I designed and developed from the ground up was the difference between us getting a client (B2B) and not getting a client. I also know how much revenue that client added directly to our bottom line. I was what is usually called a Single Responsible Individual. When one hire needs to be that impactful, there is no room for training juniors. All of our local software engineers can point to a feature they spearheaded that added measurably to our revenue.
Now the hard truth is, why hire junior developers locally when you can hire people with much more experience overseas for the same price? I know the stereotype of the crappy outsourced developer, but I haven’t found that to be the case.
Anecdotally, I was lucky enough never to be a junior developer[1], I got my first job out of college with a small company based on an internship the previous year. My first assignment was create a networked data entry system in C that was the basis of a new department that they were starting that allowed them to double in size. But I had been a hobbyist programmer for a decade. By the time I got my next job, I was already considered a mid level developer.
[1] yeah that did hurt me later on. I didn’t get any type of real mentoring and stayed an “expert beginner” for a decade.
For what it’s worth I work at a small company now that is a startup and this is how we do things, to great success, the way I described it
To be clear, I do not work in Silicon Valley either, never lived in SV. So I get that part of it
I’ve seen the argument about paying them market rates. But honestly, if they are young and unencumbered, their “market” is the entire US. Meaning you may not have been in the position to pay them what they could make if they were willing to move across the country.
To go into more anecdotal detail, I had been programming as a hobbyist since I was 12 in assembly for 10 years by the time I graduated from a no name college in the south. I had two job opportunities - one making an entry level developer salary writing COBOL [1] in a slightly larger city, or working as a computer operator in a major city. I chose the latter job that paid much less just to get to the city. I got lucky and I was the only one who knew how to program so they gave me the previously mentioned project straight out of college. They gave me a raise the next year to that of an entry level developer (I was hourly at first and got a lot of overtime).
But now, three years later, the project was done and with a major green field C project under my belt, my market value had gone up more than 50%. They couldn’t justify paying me that and I got another job.
Now if a similar scenario had played out in today’s market instead of 1999, even if they could have matched my local salary of $80-$100K for a mid level developer, I could have spent a year studying “algorithms and leetCode”, picked up and moved to SV and doubled or tripled my total comp. There is no way they could compete with that.
Let’s look at the current state of affairs. Almost every engineer at my company is between 35-50. They purposefully created the office in the burbs three years ago to attract older developers. They not only get experience, paying local market salary is relatively easy comparatively. The chance of any of us uprooting our families, selling our big, relatively cheap 3000 square foot houses in the burbs with the great school systems and moving to the west coast is slim.
We train developers in popular languages (particularly our stack leverages Vue and C# and a good deal of custom SCSS) we are only ~3 hrs from the valley yet we aren’t losing engineers in droves and haven’t ever for the years we have been in business
You should pay juniors market rates for their positions, period. I don’t agree with that at all
https://www.businessinsider.com/average-employee-tenure-rete...
This logic is sound, but I don't personally agree that bureaucracy is gonna solve any of our problems.
The rest of your comment, I believe if you spend time reading my OP carefully and spend some time noodling over it then you'd find that all of it had been covered already.
I don’t buy gate keeping either as the number one issue, see the lawyer glut as an example.
That is a zero-sum attitude that does not hold up when a company does other things well. If you are training your employees, you are likely to be doing the other things that help retain employees (https://www.bayshorestaffing.com/images/uploads/Blog_Image.j...). And if you are focusing on and actually delivering all ten of those benefits, employees are extremely unlikely to be jumping ship unless they are either a poor employee or have poor character (which you don’t want anyhow), or the competition is paying not only well above market rate, but well above your rates. Which means that they are now at a strategic disadvantage because an inordinate amount of funding needs to be diverted to payroll - much more so than in a company like yours.
Any company can make an end run around zero-sum thinking by fully and honestly employing those ten benefits. Employees can and will rise to the occasion, bringing a competitive advantage to your company that is well in excess to their numbers.
So, it makes sense somewhat.
You dont have to stop the projects when people on them change jobs either.