Live data from Hacker News

Who Killed the Junior Developer?

medium.com

631–640 of 803 posts

Re: Who Killed the Junior Developer?

#631

Earlier quoted context omitted.

Why is that bad? Jobs should be filled based on skill/knowledge. (The ability to learn is a skill too, one that means what you know currently matters less). I take slight offence to your statement. Why is being a woman relevant to anything, unless your company is going for 50/50 male female. But in my opinion that is wrong, and amounts to sex discrimination against men, because if 50% of roles are filled by men, even…

Building diversity is an important component of forward progress, since it engenders a broader experiential pool to draw from. In the case of gender, female developers have been shut out of the industry for long enough that corrective action has to be taken to balance the scales. Until such time as that happens, "sex discrimination against men" is impossible.

>Building diversity is an important component of forward progress, since it engenders a broader experiential pool to draw from.

Only the pool has to be created in the lower levels (education etc) not imposed at the company level with less good candidates favored just because of their sex.

>Until such time as that happens, "sex discrimination against men" is impossible.

It's very possible, if meritocracy is sidestepped, and the person who gets sidestepped is a man in favor of e.g. 50-50 parity with a woman.

Unless the pool entering the workforce is 50-50 already, then 50-50 hiring requires discrimination.

Re: Who Killed the Junior Developer?

#632
post #531
post #470

Earlier quoted context omitted.

I'd argue that it's absurd that we still think 120k is a lot of money when we look around at how expensive things like property are. My father, with a modest education and a modest first job, was able to get married, raise a child and buy a house near London well before he was 30. Property in that area is now worth hundreds of thousands and would require a six-figure salary (supposedly a lot of money!!) to be able to…

This. Its not that junior devs are overpaid, its that almost every single salaried job is underpaid for the amount of revenue they produce. If you work for a company and produce a million in value every year and they pay you 100k for it, you are basically accepting that the company was 90% of the reason you made any value at all. For almost every single developer that is not true. On average you could probably make t…

Absolutely. 100. Do you have any revolutionizing ideas about how to change this for the better? I think you could start a movement right here.

Re: Who Killed the Junior Developer?

#633

Earlier quoted context omitted.

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?

No. However we get more applicants that are women for the Jr roles and our hiring criteria matches them roughly as often as it matches men. For the sr positions 80% or more of applicants are men which roughly translates into 80% or more of hires being men. Pretty easy to see the math there without having to introduce any sort of preferential treatment.

Re: Who Killed the Junior Developer?

#634

Earlier quoted context omitted.

Have you ever been in a union? > "...pout over not getting enough money" You're trying to make striking sound childish but there are plenty of legitimate reasons why unions go on strike.

>Have you ever been in a union? No. There is a reason I went into software development and not blue-collar work. ;) (Nothing wrong with it, just not the stuff I want to deal with. Unions included. I lose enough money already to the gov't.)

I went the trades route because I didn't have any concrete plan for college when I finished high school and I wanted to get some form of gainful employment so an electrical apprenticeship seemed like a good idea until I figured out something else.

I have been in a union before (nearly a decade of industrial electrician/power plant operator work before I obtained my CS degree). You bet there is corruption in some unions, but perhaps it is different in the "skilled trades" though, at least it seems that way from my personal experience.

Avoiding blue collar work is a primary motivation for my transition to full time software dev...we'll see how it turns out though because the office culture/work environment is very foreign to me in many ways.

Re: Who Killed the Junior Developer?

#635

Earlier quoted context omitted.

I've been saying this for a while, and I think it will lead to the demise of the bootcamps, and is already causing a cascade of unemployment in low-skill indian IT from what I read. The bar is simply getting higher. I think this is a good thing overall. It's also why I care almost exclusively about CS fundamentals in technical interviews, unless we have a very specific need.

How does exclusively interviewing on CS fundamentals get you people who are good at the job?

I didn't say I interviewed only on fundamentals, just that it was what I almost exclusively cared about - for junior devs. It's a good sign that the person understands core concepts behind many different types of software, and would be teachable on the job.

Re: Who Killed the Junior Developer?

#636
post #596
post #176

Earlier quoted context omitted.

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…

From what you asked, I can deduce you work in an environment where performance is important. For my startup (and I'd say at least a non-negligible number of companies), half of what you ask is just not important. Background to read what follows: small 5-year old startup with 2 developers, which don't do anything "complicated" like ML, computation or things like (mostly apps, with a CRUD back-end). I'll try to rephras…

The thing about performance is that it doesn't matter until it does. A young organization can easily get away with hiring people who don't know about or don't care about performance for years. I get it, features need to get pushed, the business needs to move on. That's fine in the short term. For some organization even longer.

Sooner or later, though, that approach will come back to bite you. Milliseconds matter to the user because the longer they wait for an action to complete, the more likely they are to stop caring. They matter in settings where you're performing multiple RPCs because a millisecond of delay here and there adds up over multiple calls. Not to mention the fact that memory, CPU, and disk all cost money. And when those factors come up, you'll suddenly find yourself surrounded by people who are (at worst) incapable of addressing the situation or (at best) will need to be ramped up on the issue.

And that's just constant factor improvements. Can you imagine choosing an O(NlogN) solution over an O(N) one? Everyone thinks that's trivial, but in real terms it means a 10x speedup per thousand inputs and 20x per million inputs. That's huge.

More importantly: in interviews, a lack of care for performance suggest to me that a candidate is willing to cut corners. Once they have any old solution they pat themselves on the back and move on. We're a very self-driven organization, and in my experience if a new hire is struggling to meet expectations 6-12 months after joining, it's usually because they don't constantly ask themselves how they can improve their work and our codebase and instead expect to be told what to do.

Minor pet peeve: parallel processing is not premature optimization! If you think it is then I suggest you exercise it more. It's not as hard as people make it out to be, and at a certain point it becomes second nature. Then all of a sudden terabyte datasets start looking trivial...

Re: Who Killed the Junior Developer?

#637

Earlier quoted context omitted.

> You hire for needs in the next 12 months. That's like, your opinion, man. Why can't you hire long-term? If all you plan for is short-term, it will only work short-term, and it should be no surprise if on the longer term you fail or you find yourself in a world of pain. > I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons, I think you severely misunde…

..if all you plan for is short-term, it will only work short-term.. My point exactly, only in reverse. In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term. Here you see highly involved onboarding programs with mentorship, in depth training and such. Uber, FB, snapchat, netflix or whatnot never had plans that really looked past 2-3 ye…

> Uber. Netflix' streaming service

I really don't think that Uber and Netflix hired for the short term. Especially Netflix. How did you get that? Netflix in particular seems to have been playing the long game for quite a while.

Re: Who Killed the Junior Developer?

#638

Earlier quoted context omitted.

E-commerce is unique in that it has such a massive impact on revenue generation, but the skills needed to effectively manage it are rarely inline with the core competencies of the business. Most companies attempt to tackle this problem in house, but without proper expertise, there is massive waste in hiring and poor execution. As a consultant, I’ve seen teams waste _years_ fumbling in this cycle, only for me to ship…

That is because business regards its technical staff "in comtempt" and that is a direct quote from one of my previous bosses (a director at on of the largest publishers in the world)

"We keep our developers away from sales teams as they tend to be dreamkillers."

A client one time told me in the past. At the time, I wanted to ask, "so, how badly are you treating them?"

Re: Who Killed the Junior Developer?

#639
post #360

This is of course because of outsourcing. Junior devs usually do repeatable tasks guided by a manager closely, which is exactly what outsourced heads can do, definitely cheaper than the junior devs in the U.S. would. This is normal.

Guess who won't have senior devs in 10-15 years.

Outsourcing destinations, because there is little demand for senior outsourcing heads. They become harder to manage, and their jobs are high impact enough to justify the expense of hiring them in the Valley directly.

People who outgrow junior level will just make their own startups, or move to U.S. from the locations: outsourcing shops won't need them; more: they will take conscious effort to prevent them from ever growing, because growing, they become threats to these body shops.

Re: Who Killed the Junior Developer?

#640
post #159

Earlier quoted context omitted.

You're missing a rather obvious point. A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more. Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly and that's what some companies try to do, there are oth…

> A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more. Sure, but that's why you need to give people raises in line with market rates if you don't want to experience high turnover. That goes for junior and more senior people. Companies often don't want to give big raises as junior people transition int…

I think there is a lot of assumptions being made in regards to what training actually is. In software development field change is constant a senior dev can not afford to stop learning new techniques, frameworks, etc. that’s not something you just get mentored at and you’re set for the rest of your career. The issue that seems to be ignored here is the fact that good devs are active learners on their own and do not typically require the kind of hand holding that is implicitly implied to be required in these type of arguments. A company can not train an employee who otherwise does not have the required skills for the job and hope that once they are trained will stay at the same company.

Here is the equation in my mind:

cost of junior dev added slowness + senior dev lost training time > recruiting cost for senior devs + lost institutional knowledge + ramp up time for new senior devs

Post reply on HN