Met up today with one of the first recruiters I worked with at Uber as an eng manager - and one of my favorite ones! - Keki Mwaba.
After a decade of sourcing and recruitment at Uber, Flow Traders, Disney and Reddit, she just launched her career consultation business (cont'd):
Keki is offering resume reviews and career conversations as a service.
In what is very cool, she helped with input in The Tech Resume Inside Out book, given she has reviewed hundreds (or more) of resumes every month, for years.
I have not recommended services like career coaching, resume reviews etc because most of these are a coin flip, often done by people who did not do the job before (eg recruiting, hiring etc).
In this case: I’ve known Keki for years and she’s the real deal: I do recommend her.
There's the old argument of is it worth paying for {X that can be researched online}
How to work out, how to write a resume, how to do your accounting for the business is all there.
Sometimes you trade money for convenience. Sometimes it makes no sense.
Career management is minimal. But so is attrition in that region, as there's very few places to leave to. The lack of alternatives (and low attrition) likely contributes to the low ratio
A big difference between two type of software 'architects':
#1: Speaks the tech jargon. But *only* uses the jargon.
#2: Speaks the tech jargon. But *only* uses jargon when it's helpful - and they know the other party understands - else uses plain language to explain ideas.
I've observed the #1 types of people stick to deliberately speaking jargon for a few reasons:
1. They think it shows they are smart
2. Keep an artificial barrier to entry for less experienced team members to not join the convo
3. Mask their own gaps in not understanding things
I remember as a new hire sitting in a meeting when an experienced engineer threw around stuff like weak/eventual consistency, idempotency, durability, egress.
Afterward I asked another eng in the meeting what this meant:
"I also don't know. But he's Staff so must be right."
Interesting how, with Cloud and SaaS solutions spreading like wilfdire, devs need to context switch to use more and more custom tools to eg find services, docs, roll out feature flags, manage infra etc.
There's now a movement to centralize all these in Developer Portals.
Some of the most popular Developer Portal tools are:
Open source:
- Backstage by Spotify (seems like a very popular one)
- Clutch by Lyft (more for workflows)
- Hygieia for Capital one (more for dashboards)
SaaS:
- Cortex
- OpsLevel
- Port
By the way, if you are working with Backstage: I'm writing about how this works. DMs welcome both on sharing your experience, and if you'd like to review the draft.
What I noticed is that in all cases, the spammer is using old accounts - registered in 2012 both cases - which were dormant (less than 10 followers). I’m assuming it’s because new accounts would trigger automated alarms or perhaps checks.
A mistake less experienced software engineers make when it comes to estimations:
They break out maintainability/quality. Eg “building the feature is 2 weeks, adding automated tests another 3 days”.
What follows by less technical stakeholders is a push to remove the latter.
Non-functional requirements like correctness, quality, maintainability, performance etc should be baked into estimates, and not made part of bargaining. That bargaining is how sw becomes less maintainable over time.
Ofc this is not universal: you get better at it w experience.
Every time I mention estimates someone comes saying “ignore estimates just do the work”
The reality is the world runs on dates, dates can help people and teams focus, and you don’t get to dates without estimates.
A great example of some hiring managers thinking they are doing job seekers a favor w inviting them to further interviews.
In reality, every interview is one more barrier. Not everyone will jump through them: and that is fine! It’s not entitlement: it’s the free market at work.
That the more interview steps you have, the fewer people will want to go through them (tho you collect more signals).
Bemoaning dropping out of a long process is pointless. It means they have better options. Either accept or change your process.
Applies to dev hiring as well.
By the way, a very good point in the age of remote work, on why asking to see a supposedly local candidate in-person is not that silly.
Again, I’m not saying the HM should not have this interview step. Just saying don’t complain that some people drop out: in fact, expect it.