Technical Blogging & Non-Technical Blogging & Hiring
What I’ve Noticed
Blogs aren’t journals. Blogging is public. And because blogging is public, all blogs ultimately fall into the domain of public relations. If it’s public, it’s about image, beliefs and relations with readers. Access to instant self-promotion, publication and information sharing is one of the strong drivers of progress in tech.
Technical blogging is technically supported public relations.
Motives for technical blog posts include: demonstration of capacity of the author, image enhancement through association with new tools+ideas, and/or promotion of a new tool+idea for getting shit done.
Generally speaking, I think there is A LOT of evidence to suggest that technical blogging is a huge public good. That’s not to say every technical blog is worth reading, but instead that while technical blogging is often motivated by some sort of private personal benefit, there is a huge positive externality: free, detailed, often transparent technical knowledge, sometimes directly from domain founders or experts. If open source is the super hero, technical blogging is their unrelenting sidekick.
What I’ve started noticing lately in the software engineering community, however, is an uptick of non-technical self-promotional blogging, mostly about hiring.
Non-technical blogging is emotionally supported public relations.
The two examples that come to mind for me are stories told by two talented and capable software engineers. The first is story about how toy problems are too onerous and hiring practicies are too arbitrary/awful that continuing a traditional job search isn’t worth it. The second story is about how job search is non-linnear, and that competing offers from top companies are the recipe to making bank and working at the most coveted places.
Both of them are emotionally supported public relations. Both of them are part of the respective authors hiring/career image. They are both, after all, blog posts.
Why It Matters
Tech hiring is messy because fundamentally as much as we wish we could reduce the problem to technical constraints, hiring is non-technical. Hiring isn’t a framework, interface or abstraction. Hiring is people. And it’s hard for two technically-focused parties –candidates and tech firms– to reason through the non-technical content of something like interdependent working relationships. At the firm level, hiring is a low efficiency, high resource consumption, non-linnear process with strikingly variable inputs, that you run as few times as necessary until you get adequate results. It’s one of those problems. Even worse, at times it seems to opperate at some sort of constant time complexity, at others it’s somehow worse than O(n^2). Peridically the process will terminate with no feedback. Other times it will generate false error messages. At worst the process will introduce malware into your code, crash your machine, or collapse your business.
The ultimate question that any firm is asking of its candidates is “will you let me down when I need you?” and they imagine all the possible letdowns, which mostly revolve around time: takes too much time to train, takes too much time to implement features, implements features that take too much time for others to work with, takes too much time to debug, takes too much time to talk and reason through simple problems, makes mistakes that take a lot of time.
The ultimate question that any candidate is asking of its firm is “will you let me down when I need you?” and they imagine all the possible letdowns, which mostly revolve around a unique set of past experience, self-opinion and internal dillemas that the candidate comes with: will I be supported working here, will I be degraded, will I be happy, will I be proud, will I be a contributor, will I wake up every morning content with my life. Ultimately for candidates, the criteria is far more subjective and personal: will I hate working here, will I love working here. Emotional experiences like support, happiness, contribution, meaning, purpose, hate and love are deeply subjective and personal.
These are the two complex parties that hiring binds in a complex interdependent relationship. If that seems frightening, it’s because it is. At the low level first principles, this is what we have. Everything in hiring is an abstraction on that foundation.
I think what’s most frightening about hiring in tech, however, is that the process begins with a bunch of letdowns: firms try to laso the biggest candidate pool possible, candidates send applications to every firm that will presumably read them. At that volume of human interaction, tension rises, mistakes are guaranteed and both parties are likely to feel immediately slighted or devalued. And in response, both parties begin putting up guards: candidates start trying to look good by tuning resumes and training for interviews rather than jobs. In response, firms start generating increasingly arbitrary selection criteria. Both parties need a lot of eachothers time to assess whether they’re the right person for the relationship, and yet immediately the “losses” are mounting.
You end up with a lot of wasteful maneuvering; a high friction process that generates a tremendous amount of heat for every little light. We all get a little burned, and spend too much time grasping around in the dark.
What To Do
Tolerate Let Downs.
Failure is a constant in human relationships. In hiring, the magnitude of that constant is potentially large for both parties.
The variable in the equation is how quickly you are able to repair, rebound and recover.
In any field, the masters I’ve encounted have attained mastery by failing and repairing so quickly, that you don’t even notice the failure. And every day you get better.
Be Good Instead of Just Looking Good
Wanting to protect yourself and look good is totally understandable. It’s a natural response to this broken system, and nothing in hiring is getting fixed anytime soon. It’s just legacy code that we have to live with.
Instead of aspiring to protect yourself and look good, aspire to be good.
Find or create opportunities that enable you to both do good and look good. Don’t be afraid to talk about your experience candidly and honestly. Make things. Show them to people. Defend your decisions thoughtfully.
Be patient. Be commited. Be honest. Be enthusiastic. Be warm. Be kind, above all to yourself, and also others, as you –the firm or the candidate– tolerate discomfort together.
Cut to the Chase
Can you create a small sample project that requires all the skills necessary to be successful in the specific job you’re hiring for?
Firms:
Are you a search company? Ask a candidate to build a search demo with some sample data.
Are you a mobile applications company? Describe the specification of a minimal application that involves some of your features. Ask a candidate to build that demo.
Are you hiring for a position that requires a full-stack analytics pipeline? Provide a stream of fake data, and ask the candidate to use it to build an application.
It helps to ask the candidate to perform tasks that match the responsibilities of the position. Both you and the candidate will get a better sense of technical fit and capacity from the experience.
Candidates:
Do you want a full-stack job? Build a full-stack application. Demo it upfront and center.
There aren’t many real shortcuts in life. But we can certainly all get better at cuting right to the chase.
Closing
A week ago an engineer at a media company described his hiring experience as hazing. “Everyone goes through it. It binds the team. The team perpetuates it on future hires.”
Last night another engineer used the same word to describe their most recent onsite. One side effect they noticed was that onsite stress somehow made the offer they received seem more valuable. The value was somehow linked to the effort put in. They commented that it reminded them of the experience they had of their 6-day-a-week 12-hour-a-day engineer program; the effort put in seemed linked to the value of the experience.
I sat there for a moment, quietly, and wondered.