Job seekers are some of the last people on the planet that need to be
distracted. They need a simple tool to create a CV. They need
to be able to save a PDF version of that CV. If they want to,
they should have a place to put that CV, so companies can find
them. Advertisements, infinite scrolling and "stories" are
distractions they absolutely don't need in their life.
Companies and recruiters should be able to effortlessly get in touch with a candidate
that is interested in an open vacancy. A staggering amount of
time is wasted every day to find out if people have experience
with tool/technology X and if they are available to work from
date Y at company Z. Datacenters are filled to the brim with
messages between candidates and recruiters, that never would
have been sent if a proper platform existed.
Everyone has information overload. Getting irrelevant messages does not
help.
Everyone deserves transparency in how their data is used. There is no
secrecy here: candidates have full insight in the searching
capabilities of companies and recruiters.
Nobody should be discriminated based on their looks, race, name, age,
gender or sexual orientation. These are not searchable, and
never will be.
Your name and picture are completely optional, and are only
part of your own private version of your CV which you can use
to save a PDF or print a physical copy. They will never be included in the searchable version. You can click here to see what your CV looks like when other people view it in
their search results. Currently the best way to print your CV is by pressing Ctrl-p
(Cmd-p on mac) on the "edit" page. This works best in Google Chrome.
We will add an even easier way to do this as soon as possible.
Yes! But not in the way you're used to. We don't track your
behaviour, we don't sell your data, and we don't show you
advertisements. We're going to make money by connecting
companies with you, but only those companies that you want want to connect with as well. This will work as follows: A company is looking for someone
with a skill that you have. They find your CV on this website.
They tell us they're interested. You get an email from us asking you if you're interested as well. Only if you are
interested as well, we'll share your email address with them.
If you do, the company pays us for connecting you with them. If
you are not interested, they'll never get your email address.
This keeps our platform spam-free, the anonymous CVs keep our
platform discrimination-free, and the entire process ensures
you only receive messages from companies that are willing to
pay to get in touch with you.
Note: instead of your email address, other communication
methods may be chosen as well, if that's more convenient or
better for your privacy. This is still in development, so we'll
do some research to ensure we create the best solution without
forcing users and companies to create an account on every
available chat platform on the internet.
Our tech stack is an interesting blend of old-school and
new-school technologies. The application is written in a
lispy language called "Janet". This language boots up our
application very quickly on a dev Raspberry Pi, allows us to
auto-generate a lot of boilerplate you would typically see in
the codebase of a web application, and is an absolute
pleasure to work with. Also, we use a JavaScript library
called htmx to do server-side rendering of html snippets that
are merged into the DOM. This means we have almost no
separate code for the front end: it's just html, served by
the backend.
The combination of using a lisp-like language and the
"everything is written in the backend" concept will allow us
to reach near-100% code coverage in integration tests,
without writing a single line of test code. This is still
work in progress, but you can think of it as having the same
result of using something like Selenium or Protractor, but
without needing a headless browser and without writing any
code. We're probably going to call it NoTractor, because of
the pun and because tractors are kinda heavy.
One more interesting workflow our tech stack makes possible
is related to an 'ancient' technology called CGI. If you work
at a company with a nice CI/CD workflow, you may be
automatically spinning up containers when you push to a code
branch, which your QA people can take a look at. We did
something different: we wrote a wrapper around our codebase
that enables us to run it as a standalone server, or as a CGI
script. When we 'run' it as a CGI script, we basically just
create and deploy a binary file to an Apache server. It
doesn't take up any resources when it's not used. This also
means that we can keep old versions of the codebase alive if
we need them, and we can always go to a url to instantly get
an answer to the question: "What did that look like on branch
X?"
At the time of writing, we actually run the application as a
CGI script in production to save money. Because of that, and
because we're running just one instance of the application
from Europe, it's possible the website may be a bit slow,
depending on where you are querying it from and on the amount
of total traffic we're receiving. If that happens, please
don't think the "Janet" programming language and the "htmx"
library are bad technologies: they're amazing, and not the
cause of any slowness. We're very experienced in scaling out
web apps, but first we'll need to find out if people are
actually interested in this CV tool and the
withoutdistractions.com platform.
One final interesting aspect of our current setup is that we
use one global SQLite file to store all searchable CVs, and
one private SQLite file per user to store your own private
CV/data. This enables everyone to write to their own DB file
at the same time, without slowing down queries to the global
database. A simple cronjob allows us to add updates to a copy
of the global DB file, and swap that copy with the production
version when all updates have been added. If at some point we
need to switch to Postgres, we have plenty of experience to
make that work. But so far things are pretty good with our
"everything is a file" workflow.
Fun fact: having one DB file per user enables us to run
migrations only when a user is active. If someone isn't using
our platform, we don't need to spend computing power on
migrating their DB schema until they become active again.
My name is Harry Prins. The above is all written in the 'we'
form because I don't want to rewrite it if this turns into a
group/company effort - I hope that doesn't come across as
misleading. I learned how to code when I was writing my Law
master's thesis, got completely obsessed with programming, got
hired by IBM, quit my job there to migrate to a brexiting
Scotland during the pandemic, and started working on this
website as a side project until I had enough financial security
to work on it full-time.
You can get in touch with me on... LinkedIn! That's right, I don't have anything against LinkedIn as a
professional communication platform. I'm just deprecating it
for recruitment purposes.