While there are many posts criticizing how difficult hiring processes are, especially for entry-level roles, it's only in private you hear interviewers and hiring managers talk about the other side.
Here's a short thread on a few observations that also explains some criticisms:
1. Entry-level applicants are on a very wide spread skillset-wise. They range from people who can only follow a tutorial to those who are hands-on with production-ready code. It skews towards the former though.
This is one reason there are so many automated closing assessments.
2. Resumes don't tell you much about entry-level people. Within the same bootcamp grads, there will be some strong candidates, and plenty of week ones. Same with colleges. It's impossible to predict how well a person will do on a coding exercise.
3. Most entry-level people are *not* familar with things many of the "better" companies expect. Like testing. Demonstrating understanding beyond the basic syntax. A lot of this has to do with shorter training programs with bootcamps and self-study. I'm noting the generic trend.
4. The number of applicants is overwhelming for entry-level positions. The number of entry-level position openings have been very low, while bootcamps never stopped recruiting, and during COVID, even more are trying to transition to software development. blog.pragmaticengineer.com/advice-for-tec…
5. Onboarding an entry-level dev, done remotely is *a lot more* time-consuming than it has been with non-remote settings, or with non-entry-level people.
With pressure to ship, senior engs resigning, companies feel they don't have time to onboard, so throw money at the problem.
6. The main ray of hope for entry-level people is how the rest of the market is on fire, and very hard to hire experienced people.
This, and lockdowns easing, should push companies to hire more entry-level people.
7. And a quote from an engineer, from the hiring side:
"Hiring is bad. Candidate after candidate shows up, unable to write basic React for a React position. People come in as condescending & overconfident on interviews. I want to stay positive, but it's hard."
• • •
Missing some Tweet in this thread? You can try to
force a refresh
That first day as the Head of Engineering at a fast-growing startup is always glorious.
Not an engineering manager anymore, but a Head Of. The non-technical-at-all founder hired them because they *really* needed someone to get sort the eng problems.
A new story starts today:
The first week is done, and it's exciting. Well, a bit annoying as well. The founder keeps checking in, and talking about how they see this role, and what they want the EM (not Head of Eng) to do.
Problem is, much of it is not how the EM worked in the past, and it doesn't work.
Like the obsession the founder has with what are essentially micromanagement practices.
"This is how we work. High autonomy+high accountability is our culture". But then eng is told the work they should do, given deadlines with no input, and judged on "getting shit done".
A month into a paid newsletter for eng managers/engineers, it's taking off faster than I ever hoped:
~ 500 paid subscribers (thank you!)
~ 15,000 free subscribers
~ $62K ARR
- A top 10 @SubstackInc technology newsletter
Here's what I learned and advice on writing/newsletters 👇
1. Start writing. I started The Pragmatic Engineer blog years ago. At first, no one noticed. 70 essays later, a lot of people do.
If I started today, I'd join a community for feedback/encouragement like @bloggingfordevs by @monicalent (a community I'm a paying member of).
2. Write what *you* want to read. I always liked articles that shared observations on where tech is heading or explained important things with plain language.
My article on how big tech runs projects is on the frontpage of Hacker News (news.ycombinator.com), and the comments are really interesting.
I particularly like this one from a person at Shopify, who are out-executing most tech companies. How do they do it? Like this:
This is exactly how high-performing teams have always worked, from the teams at Apple building all their products to ones at Amazon, to those at Google etc.
Scrum, bundled with consultants can help, sure. But ever stopped to wonder about why many places never needed these folks?
When you ask "Why did Company build 7 of the same products that all failed?", it always starts with the current solution struggling. This is an opportunity. Not to fix - which doesn't get you promoted - but to start anew.
An all too real story about Promotion Driven Development:
1. Opportunity.
The PM identifies the opportunity as Company's current product(s) are struggling. The root cause? Incorrect positioning/not understanding new market dynamics.
Opportunity: build a new product that addresses all these issues (and can get the PM promoted)
2. Proposal.
The PM makes a business case and an investment ask. "If we fund a team of 10 engineers, 2 data scientists, 1 designer, and 1 PM, we can ship a new product in 12 months, and an MVP in 6. This will result in this many users/revenue/market share: 📈"
On equity: "Our CEO doesn't believe in awarding equity to employees b/c it creates the wrong types of incentives. People stay hoping for a payday."
I hear you. Companies that obviously did not get this memo include Microsoft, Apple, Amazon, Google, FB, Tesla, Twitter, Slack...
... not to talk about most of the fastest moving & innovative startups.
What the same C-levels don't like to admit is how they *do* have large amounts of equity, and hoping for a payday is one of the many reasons they also stay.