Live data from Hacker News

Who Killed the Junior Developer?

medium.com

551–560 of 803 posts

Re: Who Killed the Junior Developer?

#551

There were never any junior dev jobs. You have always had to lie, cheat, and steal your way into the field. I have a buddy who legit cheated his way to the top Magento certification and now cycles through $150k+ jobs where they keep him on long enough to realize he doesn't have any coding skills then they fire him. Reason is software is always an ancillary concern to the business. You see this in other fields, like s…

> always had to lie, cheat, and steal your way into the field Back in the 90's, when I wanted to move up to working with C++ (the hip, new, "in" thing at the time), I bought a book about C++, read through it, worked the examples, and then started interviewing. The interviewers asked all sorts of arcane questions that I hadn't come across in my few months of study, so I was tanking the interviews. The trick I figured…

It's only dishonest if you send in a fake interviewee before you in order to get the questions.

Re: Who Killed the Junior Developer?

#552
"I’ve seen the rates for senior developers because I am one and I had project managers that had me allocate timefor budgeting purposes. I know the rate is anywhere from $190-$300 an hour."

What magic world is this and how do I get there?

The norm here is maybe $50/hr if you are lucky with a phd and 20 years of experience.

Re: Who Killed the Junior Developer?

#553

Earlier quoted context omitted.

Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings. Most inventors are not professors.

You are confusing senior devs and rockstar devs. Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team…

You hire the rockstar to write version 1. That's the one that gets you to market fast, and the one you should be planning on throwing away. It's the one you keep in production as your non-rockstar ninja and guru coders write version 2 from scratch. Once you release version 2, you really need to fire your rockstar. They will never be happy in maintenance mode, and that's fine, because they're usually bad at writing for maintainability.

Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.

The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.

To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.

There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.

Re: Who Killed the Junior Developer?

#554
post #10

Isn't the problem the high turnover rate in the industry? Why invest in educating someone if they are going to quit in one year or so?

What I've seen (and frankly even what I experienced in my own career) is that really junior people are grateful to the company that gave them their first opportunity and also (to a degree that might even be called naive) invested in what their companies do, and for that reason tend to stay at companies a long time compared to more senior people.

More ops than dev, though still have to do both, but this has been the case with me as well. I have been open to staying at a company longer given they are willing to pay a reasonable salary and have the right type and amount of work. No point in switching every year if you're somewhere decent.

Re: Who Killed the Junior Developer?

#555
post #176

Earlier quoted context omitted.

I'm curious about what the common deficiencies that your encountering are. Do you mean lack of knowledge and testing and more applicable skills?

Unfortunately I can't share the exact questions we ask, but here's a smattering of the sorts of pitfalls I encounter, in no particular order: * Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess…

And I hate to say it, but this right here is the problem with the industry.

You're expecting a junior dev to know and apply details of edge cases, complex character sets, runtime and space complexity, parallel processing and behavior of caching.

This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience. Yes it's possible to find, but that's not junior level knowledge. But most of them all things that are easily learn-able on the job. You're expecting a junior dev to be familiar with and easily able to apply all aspects of software development but just not have done it. This is absurd.

A junior dev should be able to handle bug fixes, well scoped and defined features, and have a small area of ownership. Guess what, they're working for you, they need to find the 5 largest elements in an array. The sort the entire thing and then take the top 5. They send their code for code review. You have a 5 min conversation with them on how you don't need to sort the full thing. They say "ah that's cool, hadn't seen that trick before". They now implement it and know it for life.

This absurd idea that you wouldn't hire this person instead of investing in a 5 min conversation with them is a large part of the problem with the industry.

Re: Who Killed the Junior Developer?

#556

There were never any junior dev jobs. You have always had to lie, cheat, and steal your way into the field. I have a buddy who legit cheated his way to the top Magento certification and now cycles through $150k+ jobs where they keep him on long enough to realize he doesn't have any coding skills then they fire him. Reason is software is always an ancillary concern to the business. You see this in other fields, like s…

My "standard" team typically has two jr engineers, and two Sr engineers. When we hire Sr engineers we hire people that like to mentor others and see it as part of being Sr. Jr engineers know that in order to become Sr one of the skills they need to master is mentoring. This is 100% a management issue, and it starts at the hiring filter. Hiring Jrs btw is its own skill as you are filtering for potential not skill or k…

> Also, half of the Jrs we hire are women. We could never do that if we only hired experienced talent. Not enough women even apply for those roles.

You're giving preferential treatment to your recruits on the basis of their gender?

Re: Who Killed the Junior Developer?

#557

Earlier quoted context omitted.

Your reading comprehension suffers under your fragile ego. Nobody said 'senior developers shouldn't be coding'. The topic is about a lack of mentoring for junior devs. You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale. What would scale is if you were to start coaching junior devs, because if you don't, all the juniors will keep reinventing 'left-pad' in this week's…

> Your reading comprehension suffers under your fragile ego. Nobody said 'senior developers shouldn't be coding'. That is exactly what the post I was responding to said, and I've quoted it several times. Here it is a gain, since you keep glossing over it: > You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too! > "Mentoring" is basically the job you hire a sen…

For what it’s worth I agree with the person you’re replying to. The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.

I’m surprised you mentor, given all the hubris you have displyed on this thread.

Re: Who Killed the Junior Developer?

#558

Earlier quoted context omitted.

> always had to lie, cheat, and steal your way into the field Back in the 90's, when I wanted to move up to working with C++ (the hip, new, "in" thing at the time), I bought a book about C++, read through it, worked the examples, and then started interviewing. The interviewers asked all sorts of arcane questions that I hadn't come across in my few months of study, so I was tanking the interviews. The trick I figured…

Your story reminds me of the joke/anecdote of the way to cheat on tests. You religiously look over your notes and the textbook in the weeks leading up to the test, so that when you take the test it's like you have a comprehensive cheat sheet with you, but in your head . If the hiring process wasn't able to distinguish between you or who they thought they were looking for, then it wasn't your responsibility to inform…

I may be dense here, but what's the difference between a cheat sheet in your head and actually knowing the topic?

Re: Who Killed the Junior Developer?

#559

Earlier quoted context omitted.

Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings. Most inventors are not professors.

Then they aren't a rockstar. And frankly, I've spent my career cleaning up the obfuscated, badly documented, untested code of "rockstar" devs. The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it com…

Yup, I'll take Gadd over Moon any day.

Re: Who Killed the Junior Developer?

#560

Earlier quoted context omitted.

> always had to lie, cheat, and steal your way into the field Back in the 90's, when I wanted to move up to working with C++ (the hip, new, "in" thing at the time), I bought a book about C++, read through it, worked the examples, and then started interviewing. The interviewers asked all sorts of arcane questions that I hadn't come across in my few months of study, so I was tanking the interviews. The trick I figured…

Your story reminds me of the joke/anecdote of the way to cheat on tests. You religiously look over your notes and the textbook in the weeks leading up to the test, so that when you take the test it's like you have a comprehensive cheat sheet with you, but in your head . If the hiring process wasn't able to distinguish between you or who they thought they were looking for, then it wasn't your responsibility to inform…

this happens in an episode of the simpsons except he studies on accident by getting locked in a closet.
Post reply on HN