Monday 3-2-1 – hot potato handoff, code-based diagramming, screening interviews💡
Hey, Luca here 👋 welcome to the Monday 3-2-1 ✨
Every Monday I will send you an email like this with 3 short ideas about:
🎽 Engineering Management
🔨 Technical Strategy
🎒 Hiring & Onboarding
You will also receive the regular long-form one on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
1) 🎽 Hot potato handoff
In many teams I have seen, the relationship between designers and devs only goes one way.
Designers pass requirements to developers, and developers write code. That’s it.
When you think about it, the very word handoff seems to suggest this. You push the designs, and it’s done!
While this may work for small features, most projects instead benefit from continuous back and forth collaboration, in what Brad Frost calls “The Hot Potato Process”.
Ideas are frequently passed from designer to developer and back, for the entirety of the creation cycle.
Again, this is nothing new — it is iteration and collaboration, instead of "waterfall".
You can take the same advice and apply it to almost any company process!
2) 🔨 Code-based diagramming tools
A couple of weeks ago we talked of diagramming tools. These may be handy, but one common limitation is that diagrams are cumbersome to update and are not version-controlled.
Enter code-based diagramming tools, that transform code into actual diagrams.
Last week, Pablo surveyed the community about what are the best tools for this, and we got some great responses:
DB Diagram — for creating ER diagrams.
Graphviz — the old-school open source solution! Many tools have been built on top of it — you can find them from the linked page.
Diagram.codes — one of the most flexible ones out there. You can use it to create graphs, mindmaps, ER, and much more.
PlantUML — for sketching sequence flow diagrams.
Cloudcraft — for creating gorgeous cloud architecture diagrams. You can also directly import your AWS environment and keep diagrams updated automatically. Neat!
3) 🎒 Screening interviews
Screening interviews are the unsung heroes of good hiring. Good screening provides alignment and makes sure it is worthwhile to go on with the process.
Conversely, bad screening wastes everybody’s time — especially precious engineering time spent on technical interviews — by pushing candidates who are a bad fit.
A screening interview has three major goals:
Cut down — the number of applicants
Provide context — about the process / position
Build rapport — with the candidate
It is usually run by hiring managers, who will stay the point of reference of the candidate throughout the whole process.
A screening should be mostly a chat between two humans rather than a first round interview. Candidates tell more about themselves, describe their previous achievements and what they are looking for in their next role. The recruiter tells them more about the role and the team.
Here are a few topics you should cover:
About the position — responsibilities, vision, team.
Interview process — how it will unfold and what you need to prepare.
Salary range — and/or salary expectations from the candidate.
Interest in the job — why are you interested in the position? How does it fit into your journey?
When you can start — notice period from current company, personal needs, etc.
Should you relocate? — is the position location-based? Are you willing to relocate?
Answering these questions brings everybody on the same page and highlights glaring problems before you move forward.
More about interviewing candidates 👇
And that’s it for today! If you liked the article, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️