What we learnt from building a jobboard
A few months ago we built a jobboard — pieline.net. It was mostly a programming challenge — we wanted to learn more about databases and Node.js, and we thought that this would be useful and straightforward.
There used to be the Geekup Jobboard, run by Andrew Disley, free and for everyone (except recruiters). It was split up by functional areas — business, design, development and others. A few years ago, Andrew focused his efforts on a better solution — NeedHQ and the site received no new jobs.
Tim had talked to an Agency owner who was sad that the site had gone and we also knew new developers who weren’t aware of the volume of jobs available, because they didn’t know the names of all the different companies to look at their websites. Other jobboards didn’t have jobs outside of London, didn’t have a clear UX, or were full of recruiter jobs which obscure the name of the comapny you’d be working for.
The idea was to create a simple job board — listing one job from every tech company around Manchester for 30 days. Ideally, people would submit their jobs to us. In practice for the time we ran the site, we manually added ~200 jobs by hand, and never had one submission.
Learnings about companies
Companies are hiring all the time. Even the small ones. Everybody would like another developer or two.
Most companies suck at designing their websites with recruitment in mind. At least half of the sites we visited buried their recruitment page — we often found ourselves trawling sitemaps for a link. Given how competitive it is to recruit developers, we thought that every company would list the main technologies a developer would be using in the job, but all too often we found that ‘Front End developer’ really meant ‘PHP developer’, or there were just no useful details at all. When we looked over recruitment pages, we were struck by a unifying theme — they put no effort in. We rarely had enough information to say whether we could do a job, let alone if we wanted to choose one over the 200 other jobs in Manchester.
When we talked to employers, whilst they were interested in receiving better people, they were totally uninterested in yet-another-jobboard — especially without any candidates already coming in. There are many job boards, and it seemed like putting the jobspec together at all was a labour. They were understandably deeply suspicious of anything that resembled cold calling recruiters (even when we approached via email!).
A very small minority of companies listed clear breakdowns of the job and requirements, with renumeration, perks, and insight into company and engineering culture. We’d probably say AO.com has one of the best hiring pages of the companies we’ve reviewed. If your page is half as good as theirs, you’re above average.
Learnings about technical things
If you don’t know if you’re building the right thing, use duct tape, not superglue
On the technical side, we learnt how you (in a very hacky way) use Node, Express, Bootstrap, CSS, MySQL (especially joins), resolve git conflicts, and Tim learnt some JavaScript. We wanted to use a fairly lean approach, and we had a somewhat functional site live within hours. This was possible because we borrowed a lot of the backend from an open source Node CRUD app.
When we needed to secure the admin area where we could add and review jobs, we didn’t want to learn about authentication in javascript — so instead we created a password protected area via nginx and left it at that. Not rock solid, but good enough.
We never had a staging site — we deployed straight from our git repo. This wasn’t ideal but did force us to test a lot, and fix it if we broke it. When we wanted to move fast and get it out the door — we got it out the door.
Learnings about UX
To figure out how it worked in the hands of users, we went to tech meetups, and asked people if they wanted to see this thing we’d been building, and when they said yes, we asked them to apply for a job on the mobile site. As we watched them use it on their phone, we saw them click on the wrong bits, expecting things to work differently, and instantly gathered feedback about which bits worked and which bits didn’t. Some more experienced developers (I’m thinking Bobby and Martin in particular) were kind enough to critique the UI for us as well, which helped us get some of the common-sense navigation in place. We were reading Lean UX at the time, which gave us some great approaches for iteratively improving the user experience.
Users said many things — often they asked for features we didn’t want to implement in an MVP like search. Almost everyone wanted a clear salary range and we just didn’t have the data.
One of the challenges was that people often didn’t know what jobs they wanted.
People who could be hired into junior or graduate jobs, didn’t know whether they had the qualifications, when all they really needed was enthusiasm, the ability to learn and not being unpleasant to work with.
For more senior people, it often wasn’t really clear what the most useful details were to put in front of them. “Can I actually do the job?” seems like an important question, but understanding what the company is like, why they might want to work there more than where they work now, is also important information, which we couldn’t figure out a way of displaying.
One idea we had was that most job adverts are sparse on details, and so it seemed like the ability to ask each company a question — in an anonymous, ebay-style public Question & Answer might be an appealing feature.
We still think it’s a good idea — imagine: You read the job advert, you’re happy with the salary, you know where they work, you have the skills, they seem nice enough — however, you have some questions…questions that might be awkward to bring up in an interview. Questions like “do people ever pull all-nighters to finish things for a deadline?” or “will I be able to leave early some days to pick up my kids from school?”. Ultimately, although we tried our upmost to seed the board with questions, and use this feature to add value — we weren’t able to get it moving. We think it’s a neat idea, and perhaps might work really well — unfortunately we didn’t hustle hard enough to see any traction.
We tried adding Optimizely A/B testing to gather data about incremental changes. We might have been better off testing more radical variations but we learnt that with the amount of traffic we had, we were never going to learn much fast with very subtle A/B testing. Ah well.
Learnings about Growth
We never had a growth strategy that was sustainable, real or existant. We tried some paid adverts to get traffic, but since we never received any revenue from the site, this was clearly unsustainable. The idea never had a ‘purple cow’ so there wasn’t much virality potential. The question feature is probably the closest we came to it.
We feel this is an area we would give more thought to next time. Really, we should have tested this part first. ;)
In conclusion
One great outcome is that a several people found jobs because of pieline! This was without doubt the best part of the experience — we’ve heard from a couple of people who found companies on pieline, applied for the jobs listed and got them, which is very satisfying. One of them became a good friend, and we got to hear all her stories of starting her first development job. It was also a great side project for Clara to show off to employers as she was looking for her first coding job at the time.
We learnt a lot from the project — about technical things, about product, about UX. I think the main thing we learned, was that a job board isn’t the best way to solve this problem. We’re not sure what the best solution is, though better company careers pages are clearly somewhere to start.
The site is mostly now offline, though it survives on archive.org, Github and trello. As for us? We’re better prepared for our next adventure.
Pieline was made in the People’s Republic of South Yorkshire with love by @czmj2 & @tdobson.
Originally published at blog.tdobson.net on October 1, 2015.
