It Starts With a Three-Way Handshake: What Computers Can Teach Us About Candidate Outreach

No, I’m not here to say computers will replace recruiters. Instead, I want to offer my vision of how to make sourcing more structured and streamlined, using the operations of computers as a metaphor.

I promise this is going to be easy.

Recruiters often face challenges while contacting candidates. Before initiating outreach, they ask themselves many questions: How can I write better emails? Is it better to send one long email or several short ones? Should I share details about the vacancy up front or later?

To answer these questions, let’s consider computers and communication between them. They send data to each other and face the same kinds of issues as recruiters do when conducting candidate outreach. The most famous solution to these communication issues was developed in the 1970s by a group of developers led by Vinton Gray Cerf. It is called the Transmission Control Protocol (TCP).

TCP is, essentially, a batch of rules that regulate the communication between computers. It sets parameters that help computers send and receive data correctly with no omissions or errors.

Now, let’s imagine a recruiter and candidate communicating via TCP.

The Recruiter’s Guide to TCP

Before the recruiter can begin any conversation with a candidate, they conduct a greeting ritual: introducing themselves and telling the candidate why they are reaching out. In TCP terms, this kind of warm contact is called a “three-way handshake.” It is a kind of connection initialization in which, before the first computer attempts to connect with the second one, the second one must open itself up for connections by binding to and listening at a port. This initialization is called a “passive open.” Once the passive open is established, the first computer may initiate an active open.

With a connection established, we can get to the substance of the communication. The recruiter knows to keep their emails short. If they have a lot of information to deliver, they will break it into digestible pieces shared over the course of a few emails. In TCP terms, this method is called “congestion control.” If one computer tries to send too much information to a second one at once, the network may become congested, and service quality will fall. Congestion control prevents this by ensuring that computers only send as much information as the network can handle.

People are a bit like computers: Too much information at once can be overwhelming. That’s why a recruiter following TCP would break their information up into smaller segments rather than sending it all at once.

After sending an email, the recruiter waits for a response. If no reply comes, the recruiter will follow up with a second email. But the recruiter doesn’t want to follow up too quickly or too often. Otherwise, the candidate will just become overwhelmed again. The TCP principle of “flow control” can help us understand what’s happening here. TCP ensures that a sender is not overwhelming a receiver by sending information too quickly. In the TCP, the receiver sends feedback to the sender to let it know that it has received and read the information.

Finally, when the conversation has reached its conclusion, the recruiter closes communication. The recruiter doesn’t simply disappear. Instead, they conduct another ritual. They thank the candidate for their time, answer any last questions the candidate has, and share their contact information so the candidate can stay in touch. In TCP, this part of the conversation has the beautiful name of “graceful connection release.” The connection remains open until both computers have closed their ends of it. Basically, it’s a polite way for computers to ensure the receiver doesn’t hang onto a closed connection.

TCP Isn’t the Only Approach

That’s how candidate outreach would work if a recruiter followed TCP principles. Now, what if a recruiter used a different protocol: User Datagram Protocol (UDP)?

UDP differs from TCP in that it does not require connections to set up communication channels or data paths. Instead, it is a simpler, message-based protocol. Connectionless protocols do not set up dedicated end-to-end connections. Instead, communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver.

The UDP recruiter works in the completely opposite way from the TCP recruiter. He is a more easy-going person. He has no time for formality. He does not care about greetings and farewells. He has a lot of candidates to work through. Composing an email, he can even forget the name of the candidate. He just inserts information about the open role and clicks “send.” He appreciates the rapidness. He does not worry whether an email hits a particular candidate because he can always try again.

Every protocol has its merits and its drawbacks. The main merit of TCP is the quality of communication. It is a protocol that cares about your candidate. It helps establish warm, long-term relationships. On the downside, the process is slower. The sides have to get to know each other. Communication is built gradually. That is why the protocol is perfect for high-level and niche positions, especially when talent is scarce in the market.

The UDP protocol, for all its obvious drawbacks, is good for mass-hiring efforts. Its advantage is its speed. The UDP recruiter is good at reaching people in crowded markets and getting candidates into open roles quickly.

Two summarize, then, two things are important to keep in mind:

1. On the internet, there is no single best protocol. Rather, we have to choose the best one for whatever our task might be. Recruiting is the same: TCP works for high-level and specialized roles, while UDP for mass hiring.
2. The protocol analogies also help us understand what happens on the candidates’ side. In our analogy, every computer recipient is a candidate receiving tons of emails while still doing their day job and juggling their life responsibilities. When that candidate opens your email, they should not enter a state of buffer overflow — i.e., when a program attempts to write more data to a block of memory (a buffer) than the buffer can hold. Keep your outreach digestible.

Marat Mingazov is CTO of CandyJar.