Ask HN: Why not more hiring of junior devs, then on-the-job-training?
It seems like twice a week or more I read there is an industry shortage of devs, but I never hear about any companies, of any size, looking for junior devs -- or generally competent devs that might have a specific knowledge gap -- to hire and give on-the-job training to. Not even a contract-to-hire situation that leaves the company with very little risk if the developer isn't what they needed.
Is on-the-job training just flat-out dead?
I ask this because I'm 4-years-experienced as a front-end UI/interaction dev, nothing but glowing references, looking for another, similar, position (regular, not senior or lead) and have had...way too many interviews and rejections, and can't understand why companies are such sticklers for interested devs to have Every Single Box in their list of requirements checked when it would take days or a couple weeks to learn XYZ framework/library/whatever to the level of competence that is required for the position.
To further stack up the frustration, it's not uncommon to see the same position listed and re-listed on LinkedIn and Indeed for months: certainly somebody could have been hired and trained to the level needed in that time. (Maybe even me!)
494 comments
[ 3.8 ms ] story [ 337 ms ] threadIt's trivial to learn a new UI framework, why limit yourself to only the devs that know the one you've selected?
I guess if you have a lot to choose from why not.
Being prepared to learn to produce value is not the same as being prepared to produce value.
There's also the fact that people sometimes dont hire until it hurts (they have too much work to do) and then there's little or not time to train.
There's also a flood of folks from the bootcamps that may or may not have skills but want the salary of a jr dev. These folks (understandably!) flood any jr job posting, making it hard to get through to the hiring manager. There's a bit of the flavor of the year 1999 in my opinion, where everyone wanted to be a programmer (and if you could say "Java" you were hired).
Finally, an investment of months of training makes sense if an employee will be around for years. But because of the erosion of the employee/employer social contract, there's no guarantee as to how long a trained employee will stick around. Better to wait and hire someone who can make an impact their second day.
That said I think there's an enormous opportunity to do this kind of training, create loyal employees, and improve the world by training more devs.
And the most important thing: companies generally tend to expect you to bring the value from month 1. Many of them are scared to death by the prospect of an extensive training for someone who may or may not be a good fit in the long run.
1) a good exit process 2) a good promotion process
1 brings serious culture issues/questions with it. See horror stories from people who went to grad school in the 80s and 90s where year two cut rates were 50% or worse. I don't know how you deal with this, but it will certainly deeply affect your work environment.
2 is easy on the face, but requires huge buy in. Realistically you're looking at a 2-10x increase in this person's compensation over a very short time frame or you'll lose your training investment as they jump ship.
This is actually a very helpful risk-mitigation strategy. If you hire someone with less experience at a lower salary expecting to train them and it turns out they're terrible, all you have to do is not promote them. Once they realize they won't be promoted here but on paper have some experience that can get them a higher paying job elsewhere, they'll promptly disappear on their own without you having to fire them and all that goes with that.
1) What about the employees who won't or can't jump ship? These are the ones that are most important to push along in terms of company health.
2) I'm not a huge fan of the implicit 'firing'- the employee may feel a sense of responsibility to the company and slowly become more and more upset as theyre passed over for promotions.
3) I'd worry about the easy slippery slope towards terrible culture this would allow. A manager thats allowed to keep on sub-par staff because they're cheap might start stringing them along to keep the cheap and mediocre work. "Sure the promotion is coming, we just need to find the money in the budget next quarter...". Its hard to have insight into these issues from a level above the manager, and the manager has huge incentives to do it. So best not to create a structure where it can happen so easily.
Assuming it's even a problem to just leave them where they are indefinitely. There are a lot of people who make bad managers but fine low level workers.
> At 7:00 a.m. on Aug. 3, 13,000 PATCO members went on a strike in violation of a law barring federal employees from striking against the government.
It depends on what country you're in. This USA has an obsession with calling anybody with more than 2-3 years experience a 'senior' developer. In Europe senior is more like 7-8 years.
I am a big fan of mentoring, but this is related to understanding the existing platform and getting productive working on it, not about teaching technology XYZ.
This opinion should actually go both ways and companies need to be willing to hire developers, even they don't have the 100% exact skills they need and then allow them to improve them on the job. If you got rejected by companies because they don't understand this, then be glad that you will not work for them.
Having talked to others, though, I find that a lot of folks don't necessarily realize that this is acceptable/encouraged. As I moved into senior roles, I tried to do a better job of conveying this. And overall, employers and managers need to do a better job communicating that doing this is expected/reasonable behavior.
I will say that I have hired junior folks and seen them thrive after three months (take on more work with more autonomy) and that leveling up was so great to see. Plus it made them a better developer and more effective foe the company.
That's the flip side.
And it's not like a senior developer is a sure bet to be effective either (though I grant you they are, all things considered, a better bet).
I think in the HN community this is probably common sense.
In your situation, I think you're making a strategic mistake. Don't say "nope, don't know anything about react". Spend a small amount of time to do a basic hello world, say "oh, I've toyed around with it and I'm interested in property X but I haven't used it professionally" and you will put yourself in a better position.
The other possibility, honestly, is that you're doing a bad job at interviews and your lack of experience in the relevant technologies is a convenient/polite excuse. That sucks, but there you go
There is no shortage of devs. That has been a complete fabrication, made up entirely by big tech companies, in a propaganda push to promote more and more people getting into CS.
It's entirely so they can pay developers less.
https://www.investopedia.com/terms/f/faang-stocks.asp
Open markets don't have shortages, those are caused by price controls. In a market the product is always available to the highest bidder, unless there are zero suppliers at any price which is obviously not the case here.
But "shortage" sounds like a problem that needs to be solved by some kind of external intervention, whereas "wages are high" is more of the sort of thing people like to see in the economy, and is not actually a problem at all because the high wages on their own are sufficient to attract the necessary talent to the industry.
They may be able to hire more devs if they increase salary, but this would mean that the price of the end product would become too high, and they would go out of business.
Europe has a real shortage in some countries
Success makes more success. If you're a billion dollar company, you can afford to pay more for employees. This lets you hire better developers, which lets you be even more successful. If you're in a poor country and you're trying to start a company... you're still poor. The fact that you need developers doesn't suddenly make you rich enough to afford the same wages a billion dollar company can afford to pay.
These lower wages mean that good developers in such regions are often swayed to move elsewhere to get paid better, leaving that original area even worse off than it was to begin with.
JetBrains has managed to build a globally successful company in the Czech Republic, where engineering wages are usually about a third of what the US pays. Call it luck, elbow grease, whatever. They did it. From a quick google search, JetBrains pays wages that are competitive with Silicon Valley. They can only afford to do that because they have been so successful. This success is making them even more successful, since they can afford to pay competitive wages, and it probably doesn't hurt (now that they're successful) that the cost of living in Prague is super low compared to much of Europe. But it's not like anyone starting a company in Prague can suddenly afford to pay $120k+ per developer.
This cycle of brain drain is very hard to counteract. Banks aren't usually excited about freely giving out large sums of money to try out this whole "paying people more" thing and seeing if that yields better results than the other tech startups they tried to fund, but failed due to a lack of talent, random chance, or mismanagement.
If a company becomes successful, but they're only successful locally, then they're tied to the low economic success of their area. They don't have any more money than other employers, so they can't pay wages competitive with other places.
I'm no professional economist or anything, so I'm sure I'm missing some of the nuances of the situation, but a shortage in one thing (developers) doesn't somehow imply an abundance in another thing (funding), it just means that there aren't enough developers available within the funding that these companies have available.
It takes a certain amount of dish soap to clean dishes, but an absence of dishes doesn't mean your home suddenly has an excess of dish soap... you might not have any dishes or dish soap!
If the companies had a bunch of money, they probably wouldn't have too much trouble getting developers to work for them... but without those developers, how can they get the money?
Banks don't write blank checks, especially not to people who have no track record of success. If someone has a track record of success starting companies, they probably don't need the banks to give them a loan nearly as much.
The whole thing is a catch-22. There are solutions, they're just not obvious or every smaller economy in the world would already be employing those solutions. Stuff like this might help: https://tulsaremote.com/ It's hard to know.
You could've just looked up the economic definition of "shortage". What you're describing is not an economic shortage, it's market equilibrium. Of course there's always more demand than supply for something at a cheaper price than what the actual market price is.
Google definition of shortage: "a state or situation in which something needed cannot be obtained in sufficient amounts." Huh, that's exactly what I said.
In this case, the resource is being consumed by higher paying consumers outside of the local market. The whole market isn't necessarily suffering a shortage, but there are absolutely local shortages within a global market. Everything is in equilibrium if you look at a large enough picture.
It's not an economic shortage when you're in a store full of goods that you can't afford. It's a shortage when the shelves are empty.
By your self-contradictory definition, the term "shortage" loses its meaning and ceases to exist. Because with enough money, you can always buy what you need.
If you need a few tons of platinum to do something and discover that (hypothetically) there isn't actually that much here on Earth, you could build spaceships to go mine it from the asteroids with enough money. Bam! No shortage.
In the absence of sufficient money to go mine the asteroids, though, there would be a shortage of platinum on Earth. Except, your definition doesn't allow for shortages, because someone just needs to come up with the money. Maybe no human can afford to access it, but it's out there in the universe somewhere, so there can't be a shortage, right? I don't think that's a useful definition.
It doesn't really matter if you take me seriously, though, so I'm not going to keep expending effort trying to convince you to change your mind when you're not willing to consider my ideas.
No we haven't. I can assure you, the "shelves" of developers that companies in Europe have access to are far from empty. It's a matter of price. Developers from all over the world would flock to Europe if the pay was outstanding.
Having said that, let's imagine the scenario where some country allows zero immigration, all its developers are employed and would not switch jobs at any price (which is the crucial part), then you'll have a shortage. I'm not aware that such a country exists.
> If you need a few tons of platinum to do something and discover that (hypothetically) there isn't actually that much here on Earth, you could build spaceships to go mine it from the asteroids with enough money. Bam! No shortage.
If there's nobody that can meet demand of the platinum at any price, then there indeed is a shortage. Platinum that is in the ground or in outer space is not part of the supply.
> It doesn't really matter if you take me seriously, though, so I'm not going to keep expending effort trying to convince you to change your mind when you're not willing to consider my ideas.
Nobody who has basic literacy in economics will take you seriously if you can't get your terminology straight. Seriously, just look it up. Your "ideas" are besides the point. Yes, I get it, there are companies that can't afford developers. That is not a shortage in the economic sense of the word.
As an aside, what on earth is that page loading that takes long enough to need a progress bar and can't be either progressively loaded or cached?
see this reply: https://news.ycombinator.com/item?id=18508361
If you think they're that simple, why don't you move somewhere dirt cheap, then call up some developers elsewhere and offer them competitive wages to move to that area?
Show us all how it's done! You have that kind of money, right?
In reality, needing developers doesn't suddenly mean you have lots of money with which to pay those developers.
You're right that banks aren't going to be excited about that, but if you have no local billionaires looking to take a risk, what are you supposed to do? Move to an area with lots of investors? That just reinforces the cycle of low wages in the area you moved from, it doesn't break it.
I'm not saying I disagree with you, I'm genuinely curious.
On top of that, this recruiting has been at a fevered pitch for at least 4 or 5 years. If it was as unfruitful as you claim, I’d expect the recruiters to have learned that by now.
It's EXTREMELY easy for recruiters to spam out messages. Since they're payed based on hires, it's a numbers game for them. Get as many people into the interview as possible.
How many of those interviews actually result in jobs? That's the important question. As this very post shows, there is a clear disconnect: HIRING is much less common than INTERVIEWING.
I only have anecdotal evidence, but so does every one else in this thread. Personally I have been receiving emails from the same recruiters in some instances for years. I'm not a stand out developer. I also know, again anecdotally, that when we open a developer rec at my current company, it can take a very long time to fill.
My gut says there is a shortage. How much of one is very hard to determine and how artificial the shortage is due to generally poor hiring practices, low salaries, or other factors is also hard to determine. But I find it very hard to swallow the idea there is no developer shortage at all, which is what sparked this thread.
If I supply something (dev time, clean water) I think there’s no shortage; they just need to pay more.
If I demand something (dev time, clean water) I will say there’s a shortage if I can’t get it for a certain price.
Big companies can hire more trying to get away from competition, but some people would go to startups anyway (especially recent graduates).
1. There's the myth of the junior developer breaking prod or wiping databases. This is usually the result of teams not having enough process or protections in play. These are only exposed when a newbie developer does something silly because senior developers have learned how to navigate the system.
2. There's the myth of the junior developer not adding value until they're fully trained. Personally I have never had an issue ramping up, but from what I've seen across my network and search is that there's a fear of developers leaving once they gain enough knowledge. And, well, that usually happens because junior developers can be heavily underpaid without any promotion opportunities which makes job hopping the best way to increase your salary.
So I would say right now there's an overabundance of mid-level positions that could be filled by junior developers but due to irrational fears results in them just foisting the work upon smaller teams. I definitely noticed that the moment I hit two years of experience that the search became a lot easier
In regards to #2, it's not that you won't add value until you are fully trained, but there are X number of people applying for the same position, and as the person doing the hiring you are going to try to get the most experienced developer you can for that role.
There are still plenty of good companies that go out of their way to hire junior devs (for budget or other reasons)
That being said, if a company is preparing for growth they need to plan and document for those trainings ahead of time, and they’re probably better off hiring fast and teaching quickly on the job. Not documenting how your company works is another kind of technical debt if you think about it, and a lot of startups scramble to make up for it when they find they need to hire quickly but those hires aren’t getting up to speed as quickly as they should be. So they overreact and think it’s the quality of the developers that’s the problem when it’s really their own lackluster training resources causing the issue. Also, the company I’m at just constantly maintains listings for front end and back end engineers and data science just to try and keep a constant pipeline coming, but the actual needs and experience levels they’re looking for at any one time on those teams do change. IMO you should never apply to a job post that’s been up for 1+ month; always target newly published listings and you’ll up the chances a recruiter reaches out. The rest is just HR noise.
Junior devs should be hired on as exempt hourly workers. This would replace the worse than random interview process and do lots of wonderful things.
It cuts lawyers and HR out to a large degree so I have a hard time seeing it catch on, but in the longer term smart contracts and other lawyer labor saving packages could bring it in.
Yes, most companies prefer to hire people who already have the skills & experience rather than train "junior". This is not because companies don't want to develop the skills of their employees; it's simple economics. The biggest bottleneck in any company is experienced people. The senior engineers who already understand all the systems, have been to all the product meetings and solved many critical bugs in production. These people are the "goose that lays the golden egg". Most companies are looking for more of these "golden geese" who can be effective & contribute to the product immediately because the "ROI" on these people is 10x (or more!).
Training someone up from scratch in a key tech and all the companies systems usually has a negative "ROI" for the first 1-6 months and distracts senior people so it's a "lose-lose" in the short-run! Add to the fact that most companies have a "LIFO" pattern with hiring (the most recent hires are usually the people who exist first!), and many hiring managers (HR) are put off by the idea of hiring people who do not already have the required skills.
Consider the following often repeated quote/saying:
CFO: What happens if we train them and they leave? CEO: What happens if we don’t and they stay?
A lot of people have the mindset that training people costs too much time, money & effort and it distracts the key people in the company away from their focus (building the product).
This is not the fault of the company or the people working there. It's a "systems problem"; most companies simply don't have an effective system for "on-boarding & training" new people.
I've worked for several companies over the past 20 years (including starting my own twice) and have been responsible for hiring & training thousands of people.
Training people in tech skills, company culture & workflow simultaneously is a "hard problem". If you can get a "head start" on at least one of these areas the chance of successfully integrating someone is much higher. HR people know this so they want to "check" as many of the skills boxes as possible up-front. You as the "junior dev" can use this information to your advantage and invest a few hours up-front to demonstrate the necessary skills and make the HR/hiring manager's job much easier!
My advice to any "junior" person reading this:
1. Focus on your own learning/skills for at least an hour every day (preferably first thing in the morning).
2. Share your learning somewhere public e.g: GitHub or a Blog. that way the hiring manager reviewing your "CV" has a clear indication that you are "fast learner" and a "team player" who shares what they learn to help others "level up".
3. Pick the skill/tech/tool that is most valuable in your chosen industry/sector or even target it to a specific company you want to work for. e.g: if you know that AirBnB uses React.js https://stackshare.io/airbnb/airbnb you find and devour all the best tutorials for learning React.
4. Consolidate your learning into a tutorial of your own to show that you have understood the tech/tool.
5. Link to it directly from your CV/LinkedIn.
Seriously, this will take you 20h at most. You could get it done in a week and it will transform your "hireability" from "no thanks" to "when can you start?".
I know this because I have used this strategy to get jobs & contract work in the past to excellent effect. Investing in your skills and sharing your kn...
I've found myself in the exact same situation lately. It seems companies are not actually hiring for people to do a job, but simply trolling the market for who they can find. The result is wasting weeks of your life being strung along through their "process", only to be given a form letter rejection.
I quit my job at the time after months of these nonstop recruiter emails enticing me, and wasted 2 months going through this ruse with a couple companies, only to be left with a feeling of total defeat and a Bay Area rent payment eating me alive. To anyone considering doing the same, think twice. It's pretty maddening not even being able to land an in-person interview with 4 years experience.
I guess this is the takeaway from a self preservation standpoint, but the alternative is worse. Spending months of your employer's time completely mentally checked out, taking sick time and vacation for interviews, pretending like you care in meetings, it's all too much. I watched that happen multiple times before I left, and it's really discourteous to the people you work with. It just seems unethical to me to remain somewhere once you've decided to leave.
Not if you have any other kind of safety net, e.g. savings or frugal low cost lifestyle.
That being said, as difficult as it is to continue to give 100% leaving well is very important for building references that could help you in the future.
Of course, it is more fun to work at a job you care about. But you are under no obligation to "care," and there's nothing wrong with keeping a job while you don't care until you find another one.
While I agree you shouldn't quit your job without having the next thing already in place, at least in my experience this is a very volatile industry and you can't really expect to keep a job for a long time anyways. The odds may be better at a bigger company, but it still happens. One of the largest employers in my city just laid off about 1100 people.
I've been lucky in that I've been able to quickly find work after these things happened before, but I look at it like I need to be prepared to potentially have to go without work for months at any time. Hopefully my next job will be one I can keep for several years, as the constant job hopping really isn't for me.
Not having a job when you are applying for new ones puts you on a back foot with salary negotiations, as you don't have anything to compare it to. However you do have a lot more time and energy to put into the interview process. Especially when people are looking for technical tests and you have limited spare time and energy after work.
Everything worked out well and it was the best decision I ever made.
Upon saying that, I knew that there were a lot of jobs available, and I was also willing to do any kind of job, not just software engineering. If push came to shove, I was willing to go back to working in construction or hospitality.
I also had a backup plan if all else failed, which was to fly back home and stay with my parents while I sorted my life out.
My advice would be to not quit your job without a plan and a plan B.
Either can be taken to an unhealthy extreme, but on balance the human body benefits more from physical exertion than the lack of it.
Sitting in an office desk for 30 years can't be good for you either, but if it's in a position to keep my brain active (even if my muscles aren't), I'd take that job a thousand times before going back to pure labor.
In fact, one of the most memorable parts of those summer jobs was creating a shoulder rest for the 25 lbs bottles to sit on, out of discarded plastic. I honestly can't remember whether it worked at all or not, but I definitely remember being far more interested designing and cutting this piece of plastic than carrying bottles of water.
Do you find programming jobs intellectually stimulating beyond junior level? Maybe I have really bad luck, but all that I seem to be able to find - and see my friends doing - are the computer equivalents of lowest-level construction work. I usually have to step into other people's competences (e.g. contributing UX or even domain-level ideas) to get anything interesting from them.
So are sedentary jobs. Obesity, heart disease and everything else that goes with them are no joke.
It's not exactly the same skillset, but you'll understand and appreciate sales and accounts receivable much more after a stint of doing that yourself.
It has been a total disaster, exact same thing you quoted and your statement as well. Will I ever dare try to help someone else to that extent again? Or make an effort to better my career? No. Lesson learned, we're lucky to have jobs at all. I've done what both of you guys did, but for 6 months now. I feel at the limit of my sanity from all the interviews. I have so much to offer, a very solid background, solid references, I'm very well spoken and convincing- but I'm just not good enough or they're trolling the market as you so very well said. I have 10 years of experience, 8 in devops and 2 in webdev. I've started telling employers- tell me your stack and I'll be up to speed before my first day. I'm willing to work for peanuts.
At this point, I realize that I've picked my passion, but chose my career very poorly. My last company told me that the rule that HR had set for hiring was senior devs from the US, entry to mid level exclusively from from India. Going back in time, I'd have nothing to do with software. I would've picked a licensed profession, bonus points for one that offers a union. I'd probably become an electrician or do HVAC and start my own company.
I guess that's what opioids are for, to end ourselves. We are apparently not wanted nor needed in this industry, possibly the economy as a whole. I'm going to keep applying and interviewing, but I've now accepted that I'm going to slip out of the middle class. No way around it. Without my wife's public teacher's health insurance, I'd be in big trouble.
This economy and job market that everyone is talking about is a lie. If you're investment class, sure, things are great. There's an abundance of guys like us walking around. All the news articles saying how great it is had me completely fooled, I thought it was time to make my move. I'm not complaining about any of this, I'm tough as nails and forge on in every situation I've been in life. I can handle it, but I do think there's a good chance nothing comes up here I'm going to be delivering pizzas pretty soon. I do feel sorry for all the other folks who aren't as polished, have my resume, no criminal record, good credit, and without knowing someone at a company, outside of some very good luck, I don't think most of them have a chance in hell.
Companies are very, very risk-averse in hiring and they don't want to get stuck with one of those types. They overestimate the short-term risk of making a bad hire and underestimate the long-term risk of not moving fast enough or hiring enough.
Even from a purely cover-your-ass perspective, a manager who makes a bad hire will likely be blamed for not screening candidates well enough, but a manager who fails to hire enough can easily point to the "talent shortage". No one ever got fired for choosing AWS, and no one ever got fired for hiring an ex-Googler :)
Actually, a bad hire is a long-term risk. Very hard to fire fast.
Actually, a bad hire is a long-term risk. It’s hard to fire fast and bad hires add up. B players hire C players, as the saying goes.
Plus the market is flooded with junior devs. At this moment it's tough -- but not too tough -- to hire a senior dev. But juniors are a dime a dozen.
Our other employees that have stuck around and become productive have all been initially hired as part-time testers and interns. Some of them were students at the time, others were coming in from other trades entirely. But they all trained up incrementally on our products and learned our business over time. Granted, theres definitely been a filtering, as maybe a quarter of all those we put in those testing roles proved capable of moving on to doing development work, but that is much better than the success rate we have had trying to hire for actual development positions, whether junior or senior.
(OP: email's in the profile if you're interested in making a potential contact; hiring is on the horizon where I'm at.)
Language and programming fundaments have to be taught, and companies rarely have any decent processes around it, and it eats a lot of time from other developers. Domain knowledge can be gathered from literally anyone in the company, and also unless you are a senior, you don't need that much of understanding.
Moreover, you can do some tasks without knowing anything – fixing nasty bugs nobody has time for, automating some stuff. During doing that you can get some ideas what it is about. Another point is that person with experience already immersed into other/same domain in the past projects.
I can see why many companies don't often have a process around teaching programming fundamentals and prefer to hire those who can demonstrate competence in one or more languages. I understand less why companies with a determination to build their team rarely have any kind of methodical approach to introducing developers to their systems and seem to prefer sink-or-swim ad hoc task assignment.
There's a consistency to that approach with the approach of a precise list of specific stack/tooling requirements, of course: it says "we want to rent talent, not develop it." And that approach has its merits, even. But there's an inconsistency, too -- if your primary approach to introducing people to your existing systems is learn-by-flailing, why be concerned about avoiding that with frameworks and languages, too? Especially when, as far as you're concerned, the familiarity that matters is with specific languages and frameworks as used by your system.
If you're willing to work in Texas, send me an email (check my profile). We absolutely do not mind if you have gaps.
semi-OT: To all people in this thread who say there is no shortage of developers: if you know any of these developers willing to work in Texas, send them my way!
We are struggling to hire for front-end/full-stack developers. It isn't a problem with pay - we offer quite competitively AND Texas has low cost of living! The problem is that we seem to get people who can't pass variations of fizzbuzz (i.e., implement max, min, mean, median on a list) or who we filter out after an intro call due to red flags (claimed to be a web application security specialist but also claimed no experience with web browser APIs, another that claimed to be an expert in databases but didn't know what a schema was!).
I am willing to believe the talent is out there, but we are having a hard time tapping into it.
Granted this is a rural area and ymmv depending on the local average skill level, but still if you want to grade someone from zero to ten you need to start with exercisers close to zero.
Otoh if your interview questions are all 9 or 10 in difficulty most of your candidate will fail them and you'll have no data for a decision because all 8s will fail to answer in the same way as 6s and 3s
Much better to start with some stupid loop and work up from there.
Besides, it's a waste of their time and yours to have someone attempt a 9 or 10 before they show they can pass a 1.
Even if you usually would use a library function, finding the max of a list or similar problems are still sufficiently simple tasks which every programmer should be able to perform. It's straightforward and not about remembering some complicated algorithm from some CS class years ago nobody ever implements themselves.
It shows you can iterate over an array and use conditionals, something literally everyone should be able to do if they know the language. These kinds of tests are a quick way to screen out applicants who are straight up lying about experience with a particular language.
It's not like asking them to write a sorting algorithm or implement Dijkstra's algorithm, which requires specific knowledge of algorithms and isn't trivial to implement. And it's not some obscure brainteaser that has no relevance to their normal work.
Iterating over arrays and using conditional logic is something I do every day. In fact, I'd say that's basically 80% of what my job is.
One problem we just encountered in production that I'm trying to work into a prompt was our impression generation created a large amount of duplicates. Identifying the duplicates and eliminating them takes some simple verbal requirements but has a lot of depth. If they cant't do max/min/mean/median, they surely can't do answer that (which our least senior developer was able to do, with guidance (mostly on optimization)).
We have other questions that are much more relevant to day-to-day tasks, but both kinds are important.
Does that problem not require separate thought processes though?
In terms of a max/min/mean/median style problem, the candidate needs to come up with an algorithmic solution to find those values. In the later case of finding duplicates, there is minimal (depending on problem complexity, I suppose) amount of algorithmic complexity and the focus is more on data structures; for instance, does the candidate know they could use a data structure like a hashmap or variant to find unique items with the drawback being an additional storage unit.
So, I guess what I'm trying to trace back to is how you say if they can't answer one then surely they can't solve the other, but (while relatively 'simple' problems) I'd argue they take different mindsets to solve. Obviously in the grand scheme of things one mindset works for both, but in this it can vary a bit.
Anyway, late-night thoughts so hopefully that's not a jumbled-up response.
They aren't exact duplicates. Instead, the code to send an impression was firing repeatedly, so it'd be more like that person refreshing the page once per second thousands of times (except the page content never changes if they don't refresh).
At it's most basic, you're essentially just finding chains of impressions based on lag from the last impression. In practice, we also need to maintain data integrity (foreign keys) and deal with several other issues stemming from common cases where the assumption 'if they are within X seconds, count as duplicate' doesn't hold.
So you could completely ignore performance and still have a question that could prompt a lot of discussion with a candidate (though performance should be part of that discussion). I'm not sure if we'll end up using it due to the relatively large amount of baggage associated with the problem (table layout and business requirements), I've just been toying with reducing the problem down to a simpler prompt that would be feasible.
I'm fairly new to interviewing/hiring, but I really like questions that cut across multiple 'areas of competency' and are amenable to asking followup questions ('what if we wanted to add X?'). Algorithmic questions have their place, but have less day-to-day relevance. We can teach algorithmic stuff on the job.
I think your point would be fair for more complex problems, but getting the max of a list is something anybody of a logical mind could easily do even without knowing any formal programming language. And for those that do know a formal programming language it comes down to the most incredibly trivial basics of a language - comparison/variable/iteration.
In other words a self declared software developer who can't tell you how to get the max of a list is not going to be a good software developer.
I think what you’re might be missing is the basic fact that programming is so stupid lucrative, especially compared to the other jobs that are out there, people will do anything to get these jobs. I’m pretty sure you want your new hire to know HOW the magical library list.max is written. Writing code is surely more than piecing together other people’s utility functions and ideas?
By way of analogy, should your new EE hire be able to compute basic ohms law voltage drop over a resistor? We teach kids this formula. Is this knowledge too below a senior electrical engineer to still know? Of course not.
Finally, someone’s attitude towards answering these questions will tell you a lot about what kind of person they are to work with. If they are surely and refuse to implement list.max, well then, what will their attitude be when it comes to grungy code tasks?
I interned in a medium sized cloud company this summer and they require you to complete a homework project within 4 hours before interviews. You have to setup an environment in your language of choice, query an rest api, parse some json, do a rather easy rearranging of data and post that back to the api as json. Took me about 1 1/2 hours with simple documentation and cleaning up my code. It really only asked basics you should know, if you ever worked with a CRUD app. They also told you before the clock started that it's about HTTP, REST and JSON so you could prepare.
I heared from multiple people from the local colleges that were friends with other interns that this project was way to hard and they had no way of doing it. But it was the bare minimum you needed to do your job there without having to be babysitted by a senior fulltime.
Those devs don't understand the reality of interviewing or take offense too easily. The reality is that people lie on their resumes, which makes such questions necessary. If they can pass, they can feel scoff all they want, but they had best answer the question or I will assume they are acting to avoid showing they can't answer it.
It's an unfortunate waste of everyone's time.
Hiring remote would be an exception to the rule, for us. Not impossible, but you'd have to be worth it.
I can't imagine how awkward it is for both the interviewer and interviewee.
Also, you bring up an important point about time at the company. Anecdotal, but seems like a lot of devs spend 2-3 years at a company before moving on. That cycle is so short that the company doesn't think it's worth investing in junior people and doing so may even be considered counterproductive; the common view is that it's like investing in competitors. I'd like to think I'm wrong about that, but so far it remains a nagging impression.
I mean, a mediocre engineer that knows the system well is way more useful than an excellent engineers that just got his hands on it, for like half a year or more depending on complexity. If you give guidance you don't need excellent engineers. At least not as many. It's kinda surprising the way companies think of this.
Rather than officially allocating a developers time for introducing new employees or writing documentation for the system, Company 101 is to put 10 or 100 times the amount of dev time into catching up for the devs replacement when he quits, after he quits.
In Asia, it's not as cut throat as USA, where you shop around every 2-3 years. Japan they'll train you, and quitting isn't something that's easily done -- watch any Japanese netflix series about slice of life/normal life and you'll see the daily struggle or just read the news, or if you have the chance, go to Japan. Death by overwork is real and on the other hand, companies such as Rakutan will hire newly minted devs from schools that may know nothing and use the herd of workers to make them catch up.
Philippines and Indonesia is also similar with OJT training and filling seats.
Can't comment for anywhere else in Asia. But it is really 180 compared to USA.
Back when I was graduating, we had TCS come to our Tier-I college. The recruiter started off by telling that the salary they will be offering was 250,000INR/yr (then about 7K USD/yr) and that those who found it too low were free to leave. About half the class walked out. The rest stayed, most were offered a position.
which is where the service contract comes in
^ this, can't agree enough.
If you have a strongly cross-functional, collaborative team, then a new person isn't nearly as much of a problem to bring on. As an example, Atomic Object is a midwestern software development shop that follows practices like pair programming, collective code ownership, short iterations, and a lot more. For them, interships and apprentices aren't a big problem, and have been key to their growth:
https://spin.atomicobject.com/2011/10/04/interns-and-apprent...
I also think it's worth looking at why people change jobs. I agree it's common, but I also believe that sucky jobs are common. If people leaving is such a problem, I'd like to see companies put more effort in to making them happy where they are. Not only would that be the humane thing to do, but it would make the ROI on investing in employees higher.
<plug> http://skillerwhale.com </plug>
Speaking with a CTO of a small web company recently I got to understand the issue from both perspectives.
CTO’s thoughts when hiring junior devs:
- Can be great for company but only if it makes economical sense I.e the developer stays with the company long enough after training
- From experience, the best devs from training move on to other companies soon after training
- Junior devs ask for frequent pay rises that aren’t viable for the company, holding the companies investment in the dev against them
Thoughts of a junior when considering other roles: - How respected & valued will they be old vs new
- How interesting is the work, and will there be continued opportunity to develop themselves and learn new skills old vs new
- Salary old vs new
- The potential for future career prospects old vs new
Good junior devs will naturally be very enthusiastic and eager to learn, and the company needs to support this through and beyond the training to keep them motivated and engaged. On top of this, juniors will want to see regular progressions through the training process in forms of clear recognition and increases in pay and responsibilities as they progress. If these are not given, it’s likely the junior will feel under appreciated / taken advantage of.
Progression through a training course like this is motivated by success, and rewards, not unlike video games.
In my opinion the best way a company can keep a junior happy is to follow this and apply some of the proven methods researched and applied all over the video games industry.
- Progressively difficult but achievable tasks (missions)
- A sense of accomplishment from these (contributing towards real projects)
- Regular checkpoints ( targets and 2-3monthly reviews to support these)
- Regular rewards (small but regular pay increases, matched with greater responsibility and clear recognition of progression in the company; mutual respect is important!)
The list goes on.
If an approach like this is followed, the dev is much more likely to come out of training with a great sense of achievement and an attachment to the company for the support and rewards that were received. I think this massively increases the chances of a dev staying on, Provided salary, job title and sense of respect are matched with other members of the team in similar roles. I feel this is something many companies don't put enough thought into considering the large investment they're putting into the dev.
A 4 month training program, while beneficial for the students, works as an extended interview for me. I get to teach them skills which I think are relevant and fix what I think are cracks in their learning. All in all, at the end, I get employees who have skills that I want and with whom I share a rapport.
The approach has scalability problems since I'm just one person but I see no reason why companies shouldn't formalise something like this and hone good talent rather than fish in the labour pool for it.
Junior people around the world get to benefit from the mentorship, and we get access to talented people early on. Without that much internal risk, since it's open source.
The problem is exactly as you describe: scaling. Mentoring is an extremely time-intensive process and when things go rough, such "charity" activities are the first to suffer.
Instead they resort to the simplistic. Senior developers have made it through several filters. They've proven they can do the work, they've done it at several companies, and they've survived in the role enough to be promoted a couple times. That's just signal that they're less likely to run into problems, and that there's less risk the hire won't work out.
So, companies are lazy. Not intentionally—but because they're literally squeezing every ounce of time and focus on the very complex and wildly difficult task of managing a company and staying solvent and productive and going in the right direction.
They shouldn't be—they should have room for training and developing a talent pipeline—but this is the real world, and most companies can't even do basic company things really well, so the prospect of also doing on-the-job training really well to de-risk the hiring of junior engineers seems pretty far out.
In addition, many hiring managers have learned the hard way what '5 years of experience' means, because they've had 5 years of experience themselves, and only on the 5th year of that figured out how to do their job in the way they now know it needs to be done.
It's not an arbitrary set of skills they know they need, but an experience working in an ecosystem in specific ways that they know are crucial. Experience is not necessarily just skills, but a sequence of realizations, hardships, events, and successes that teach you things you can only learn by going through them.
Hiring managers hiring for a Senior role and pointing to a checklist of technical skills are probably not being fully forthcoming—they're likely looking for someone who does not see their own value as a checklist of technical skills.
Not saying that's you necessarily, and they could certainly be wrong, but personally I've learned that when the team needs someone with 5 years of experience, it takes 5 years to develop it, and there are no shortcuts to gaining that experience. The one thing I've found that speeds it up is experience in smaller companies or starting your own business—you'll experience a lot more much faster.
That said, there are companies that truly invest in on-the-job training, and with a holistic business model centered around that as a core value, it can be successful. It takes a philosophy, though, that most businesses will never mature enough to reach, dare I say, especially tech businesses.
The one I know of is the Greyston Bakery in NY, which was started by a Zen monk named Bernie Glassman (who passed away a couple weeks ago, sadly). His book "Instructions to the Cook" is really interesting, and outlines how they made a policy of hiring anyone who wanted a job work very well. They now run the Center for Open Hiring that helps other companies do the same thing.
It would be pretty incredible to see a tech company embrace that kind of thing and really invest in hiring and development as a strategy. I'd almost imagine it as a merger of something like General Assembly with an actual product and long-term business. It would be interesting to see if the significantly greater investment would be worth it over the traditional model.