DEV Community: G

TruthCV - self hosted job posting aggregator and application manager

Fri, 13 Nov 2026 09:18:25 +0000

In July, my last company let over 200 people go due to a shift in direction. Unfortunately, I was part of that and that same day I created TruthCV to share with my colleagues to help on their job hunt.

I developed it agentically with Forestree which puts architecture first.

How I use it
After set up, I let it find applications and I just review them with my morning coffee. I've mainly been using it as a filter to only find the jobs I'd be really interested in reviewing. If it brings me any I go to the site and apply manually.

It has a feature to generate cover letters which I use to spit out a base doc then manually edit as I see fit.

Finally, it helps with keeping track of the applications you've put in. I usually add little notes about what salary range I requested, whether I reached out to some one personally, etc.

High Level Instructions
You load your CV, set up your job search and schedule and just let it run on a server or whatever machine you have running 24/7.

TruthCV searches five job boards out of the box (Greenhouse, Lever, Ashby, Workday and Arbeitnow). You can add any other site on the Job boards page. Give it the domain, and optionally a search link with {keywords} and {location} slots. The agent then either searches the site directly or finds its postings through Google.

Some sites need a login. The agent uses its own built-in browser, so you sign in once through that browser inside the app. TruthCV remembers the login. If the agent ever hits a login wall, the site shows up under "Needs attention" with a one-click "Sign in" button.

For deploying TruthCV
Harness users: You can use your own agents to set this up by telling them to check the README for instructions.

Manual set up can be done by following the README

Must haves

Docker, installed and running. On Mac or Windows that means Docker Desktop; on Linux, Docker plus Compose.
One AI model connection:
- Claude: a Pro/Max subscription sign-in, or an Anthropic API key Didn't test the following:
- ChatGPT: a subscription sign-in, or an OpenAI API key
- OpenRouter: an API key
- Ollama: free and local, no key needed Your CV as a PDF, DOCX, TXT or Markdown file. A LinkedIn PDF export is the easiest.

Good to know

Install: double-click the launcher for your system in scripts/launch/ (.command for Mac, .bat for Windows, .sh for Linux). No config file to write.
First start takes about 10 minutes, because it builds the app once. After that it starts in seconds.
It runs 3 containers: the app, a Chromium browser and the job-application agent. The browser container reserves 2 GB of shared memory. Ollama is a 4th container, only if they choose it.
Data stays on your machine in ./data. There's no database and no account to create.
Optional: Gmail response tracking (needs your own Google Cloud OAuth app, plus a Jev key) and Jev cross-checking (needs a Jev key).

The app has no login. It only listens on the machine itself (port 5627), and that's on purpose. If you put it on a server or the open internet, you must add your own login in front of it. I use mine over vpn when I'm away from home.

Hope it helps with the daily grind, I've gotten a few interviews by using it but nothing has landed yet ¯\(ツ)/¯

My Website
Linkedin

Windows: change default sound source with 1 click

Wed, 04 Nov 2020 23:06:09 +0000

I found myself switching between my monitor speakers and my headphones frequently and having to click 3-4 times through the taskbar every time I wanted to change started to get annoying.

I figured it could be useful to others so here it is.

Default Audio Switcher

Purpose:

Created for switching default sound source between my monitor speakers and headphones with 1 click.

Prerequisites:

Windows OS
Download and copy NirCmd to your windows directory
Download my defaultaudioswitcher repo

Setup Switch Sound Source:

Find the names of your sound sources for your PC via command prompt

nircmd showsounddevices

Pick the two you want to switch between
Edit the SwitchSoundSource+.bat file with the names of your sound sources

SET defaultSoundSource="exampleSource1"
SET soundSource0="exampleSource1"
SET soundSource1="exampleSource2"

Save the SwitchSoundSource+.bat
Run (double click) SwitchSoundSource.vbs

Optional:

Create shortcut to the .vbs file and set icon location to ico file in this folder (or your own custom icon)
Set hotkey via shortcut properties

I just have my shortcut set up on my Nexus Dock

@author Glenn Chon

How do all of you handle user sign up flows?

Sat, 26 Sep 2020 20:38:08 +0000

I've seen:

⚫ Sign up form (email and password) ➡ Verification email ➡ User logs in

⚫ Sign up with email ➡ Verification email to account setup page (details and password) ➡ User is logged in

What benefits do you see in your method?

Architecture planning of an on top filter over multiple public search APIs?

Tue, 14 Apr 2020 20:10:04 +0000

I'm in the beginning stages of creating a service that gives users more filtering options on top of multiple public APIs.

I think I've gathered the basic pros and cons of setting something like this up with different stacks and wanted to see if I was missing anything big or I have anything wrong. (Or if you have any other recommendations)

Option 1:
Normal front end + back end for auth and config saves to DB.

Front end > User requests search > User search configs > Request from individual APIs > Filter > Display
Back end > handles user auth and config saves

Pros:

Simple to set up.
Public API end point requests come from client so there’s less cost for my server.
No chance of being blacklisted for too many API calls from 1 IP address.

Cons:

All filtering done on client side, code will be accessible to anyone who wants to copy.
UX speed dependent on client machine/connection – Must wait for multiple API requests from different sources and then filter.
Speed dependent on 3rd party API servers and whether they’re available at time of request.

Indifferent:

Will still need to implement an auth server and save user settings.

Option 2:
Normal front end + REST back end API + auth and config saves to DB.

Front end > User saves configs > User requests search
Back end > Use user search configs > Calls 3rd party APIs > Results formatted and filtered in server > Return to front end > Display results

Pros:

Simple to set up.
Don’t have to worry about bogging down client UX.
Hides filtering from anyone who wants to just copy the code and business model.

Cons:

Increase in cost due to many api requests from my server.
Risk of being blacklisted if there are a high number of users.

Option 3:
Normal front end + REST back end API + Redis cache + auth and config saves to DB.

Front end > User saves configs > User requests search
Back end > Use user search configs > check if end-points are in DB or end-point results are in Redis cache

If false, Calls 3rd party APIs > Format results > Results saved Redis cache > Filter results > Return to front end
If true, get results from Redis cache > Filter results based on user configs > Return to front end ________________________________________

Pros:

Less requests done from my server than option 2.
Less risk of being blacklisted.
Requests are only called when needed or the cache result has timed out.
If there are a lot of users with the same base API search requests, this will have a constant number of requests within a specified cache timeout time-frame.

Cons:

Same speed as 2 if users request search after a cache item has timed out.
Increase in setup complexity.

Option 4:
Normal front end + REST back end API + Redis cache + auto rolling API calls+ auth and config saves to DB.
Same as Option 3 but instead of getting results on demand when Redis cache item times out, the server automatically gets the results for each unique api endpoint upon timeout. (aka 4 times a day it’ll make all unique api calls and cache results)

Pros:

Same as 3
Constant number of 3rd party API calls, x:1 relation in number of calls and Unique API. X being how many times I want my server to auto get results.
Decreases costs substantially as user numbers get high. Scales effectively.

Cons:

Not as cost effective as 3 in the beginning as it may be making calls unnecessarily with small user numbers ( could halve the number of calls at first to 2 instead of 4 times a day) and change that as users increase.

Option 5:
Front end with GraphQL + Apollo GraphQL backend + Redis cache + auto rolling API calls + auth and config saves to DB

Setup same as Option 4 but basically implement it as a GraphQL API

Pros:

Reduces number of calls between client and my server for relational calls
Decreases costs on my end when implemented for large number of users.
Would be fun to learn and useful in the future for other projects

Cons:

Time to learn setting up GraphQL
Not really worth it if I don’t have a large number of users accessing relational data