First Steps
Pathways

Inspiration

Most hires come through referrals, yet most job seekers still apply cold. They usually know someone who knows someone at the company, but they can't see that chain, and asking a near-stranger for a referral feels awkward.

We came up with the idea originally from the idea that you can reach anyone on earth in 6 steps. We though this is a small amount of work to find an employer. We are going to be graduating soon and we will need jobs, so this was a very relevant project for us.

What it does

• Search roles and people. • Strongest path, not shortest. • Warm introductions, one hop at a time. • Accounts and connections. • Privacy by default. • Light and dark mode.

How we built it

The backend is Python with FastAPI, storing people, contact details, connections, job openings and introduction requests in MariaDB. The same server delivers a plain HTML, CSS and JavaScript frontend, so there's no build step. Passwords are stored as salted PBKDF2 hashes, and sessions use signed tokens. The core is the path search, built on NetworkX:

Edge cost = −log(strength). Dijkstra's algorithm adds costs and looks for the smallest total. We want the path whose strengths multiply to the largest value. Taking the negative log turns one into the other, and because strengths are between 0 and 1, every cost stays positive, as Dijkstra requires.
Load only the nearby network. Any path of six or fewer hops stays within three steps of the seeker or three steps of a hiring manager. We expand three rounds from each side, in batched SQL queries, until the two areas meet. On a 20,000-person test network, a search loads about 8,000 of 100,000 connections.
Hop-limited Dijkstra. Our own version of Dijkstra tracks hop count alongside cost, so it finds the strongest path within six hops rather than the strongest path of any length.
Early stop. Routes leave the priority queue strongest first, so the search stops as soon as it has the top three hiring managers.

Search-as-you-type uses a separate suggestion endpoint that ranks matches by starts-with, then word-start, then anywhere in the text. The frontend discards stale responses, so fast typing never shows outdated results.

We also built a web-scraped dataset as a proof of concept, showing the same pipeline can run on real public relationship data instead of our synthetic demo network.

We wrote 79 automated tests, including one that checks our search against an independent brute-force method.

Challenges we ran into

• Plain Dijkstra quietly gave wrong answers. Our first version found the strongest path of any length, which was often 8 to 16 hops, then discarded it for breaking the six-hop limit, even when a good five-hop path existed. Checking against a brute-force method exposed it: plain Dijkstra found valid paths for 21 of 150 test pairs, versus 150 of 150 after we built a version that tracks hop count. • Loading the whole network doesn't scale. Our first draft loaded every user and connection into memory on each search. We replaced it with loading outward from both ends until they meet, which keeps searches fast as the network grows. • No real network to start from. Nobody hands out their connection graph, and scraping LinkedIn isn't an option. We built a synthetic network generator for the demo and a scraped dataset as a proof of concept. • Keeping contact details unique. "+1 (555) 123-4567" and "555 123 4567" are the same number written differently. We normalize phone numbers and GitHub usernames so duplicates are caught, and save everything at sign-up in one transaction so a rejected phone number can't leave a half-created account. • Setup and teamwork at 3 AM. Database logins on Fedora, a revert that removed our frontend from the main branch, and commits landing on the wrong branch all cost us time. Small pull requests and a growing test suite kept us moving.

Accomplishments that we're proud of

• A path search that's both correct and fast. It matched an independent brute-force check on every test case, and the early stop cut a broad search on the 20,000-person network from about 400 ms to 2 ms. • The whole loop works end to end: sign up, add the people you know, search, request an introduction, and watch it travel to the hiring manager. • Search that feels instant, with suggestions and live results as you type. • 79 passing tests, written alongside the features rather than at the end. • A proof of concept on scraped data, showing the idea isn't limited to our synthetic demo.

What we learned

• Textbook algorithms need adapting to real constraints. Dijkstra is correct for "shortest path," but our real question was "strongest path within six hops," and that needed a different algorithm. • Test against something independent. A brute-force checker caught a bug that looked like reasonable output. • Data is the hard part of a network product. The algorithm was the easy half; getting realistic connection data is the real challenge. • Git habits matter under pressure. Small branches and pull requests let us recover quickly from a bad revert.

What's next for GitConnectd

• Real tie strength. Score connections from shared employers, GitHub co-contributions and, with consent, email and calendar signals, instead of self-ratings alone. • Real communities. Launch inside one dense, opt-in network, such as a university's alumni or a hackathon's attendees, building on our scraped-data proof of concept. • Confirmed connections. Today one person can add a connection on their own; next, the other person confirms it. • Tighter security. The introduction endpoints should take the user from the sign-in token rather than trusting a user ID. • AI-written introductions, tailored to each relationship. • Referral rewards. Many companies pay referral bonuses; we'd like to share credit with everyone along the chain. • Profile editing, and reroute suggestions when someone declines.