Question about disabling resume tailoring and per-task model overrides

[rohanmarichi]

Love what you've done with resume tailoring, genuinely a great idea. But I'm very particular about my resume, I use a heavily customised version of Jake's LaTeX template that I've spent a long time perfecting, so having it auto-tailored every time I move something to Ready is a bit frustrating.

A few things I wanted to ask about:

Is there a way to use a custom .tex file as the base template since JobOps already supports local LaTeX rendering via Tectonic? I'd want my own version used rather than having it go through RxResume.

If that's not possible, is there any way to just turn off auto-tailoring entirely? I don't want to waste LLM queries on output I won't use.

Also on the topic of LLM queries I noticed you can set model overrides for scoring and project selection but not separately for Ghostwriter and tailoring. Is that something being considered? Would love to throw the cheapest model at tailoring (Since I don't wish to use it unless I can upload my custom version of Latex Jake's) and set better models for Ghostwriter. Currently the setting for both of those is merged into one.

Might be missing something in the docs so happy to be pointed in the right direction. To add some context on why I want to disable the tailoring, I actually started using JobOps mainly for the job search, database, and application tracking side of things. Not having to maintain my own spreadsheet is a huge win for me and the app is genuinely super useful for that alone. So tailoring being on by default feels like it's getting in the way of a workflow I'm already happy with, which is why being able to turn it off would mean a lot.

Edit: Quick follow up question thats unrelated to the discussion title. When using JobSpy websites when I set a city like NYC does it only pull jobs within the geographical boundary of the city itself or does it search a default radius around it? And if there is a radius, is there any way to configure it?

[DaKheera47]

Hi Rohan,

Thanks for this well thought out comment. I'll try and address each point separately

Custom TEX files are not supported even though there is an issue for supporting these (#408), I have a feeling that the return on investment for this feature wouldn't be great as not a lot of people would be using it. As such I think it's unlikely that I would be adding it. I'd be open to accepting a PR if someone was to open it ofc. If you wanted to contribute your own TEX file as a resume format, you could do that fairly easily, and that would work as an interim fix for you and also for other people

Turning off auto tailoring is also something that has been discussed in the past (#66) and I feel like that is a feature that I would like to think about now, because just the job board aggregation and job tracking is enough of a reason to use the app. I can explain my rationale for having this in the first place.

Originally, and I guess even now, the idea about the app is that I want to hit (as unobtrusively as possible) the main pillars of modern job hunting, which is:

• to get to a job fast
• to tailor your CV for every job
• to reach out after the filling the application to recruiters and people in the company to build rapport
  Everything else around this is something that's been done before, and is not entirely unique to my work, though maybe bringing it all together is new.

I do think that my pillars could be quite specific to me, because I am somewhat early careers, software engineering, in the UK. So this advice might not apply to people who have several decades of experience in another industry entirely, which is why I greatly appreciate getting feedback from other users like you!

The idea behind the separation of models is almost by behavior. For example, the scoring model is differentiated because scoring happens a lot more often than all other AI features so the ability to use a cheaper model is good. The other type of model, if you can call it that, are the writing models which are used in the tailoring and the Ghostwriter because you want these to be more creative models for example the sonnet series by anthropic. I think for your case specifically, the ability to disable tailoring entirely would solve this problem because then you could have a better model for writing and tailoring would never happen when disabled.

Search in this app works somewhat differently from JobSpy's features because we have several different extractors to support and not all of them have the same features that we want. For example, there's been an issue open for a bit (#506) about having distance based search. Currently, what happens is that (If supported by the extractor we ask the extractor for a specific location). But rather than blindly accepting whatever the extractor gives us, we also do a hard string comparison for the location that the user entered. So if you ask for "New York" and the extractor returns a job in "NYC", that job would actually get dropped because the normalized string doesn't match. Hence why I allow multiple inputs in so that you can add permutations of the same place. I guess New York is a bit of an extreme example because it has three different possible names for it but it's definitely a thing to consider

Does that answer some of your questions? If not, I am happy to have a chat back and forth about this and to find a solution that works for as many people as possible!

[rohanmarichi]

Thanks for the detailed response.

On #408, I'm genuinely unsure whether the return on investment is there for most users since custom formatting is probably a niche concern. That said, it's valuable enough to me personally that I might look into contributing it myself, so I'll keep that in the back of my mind as I get back into open source.

In the meantime, getting #66 sorted would be the pragmatic first step for my workflow while I figure out whether to tackle #408. The tracking and aggregation side alone is likely in my opinion useful enough. 

The location search explanation was eye-opening to say the least. I had no idea about the hard string comparison but it immediately explained why certain jobs were being dropped, I just assumed it was an extractor issue. A few related things I think are worth bundling with #506. The hard string matching feels like low-hanging fruit and would probably fix a lot of silent job drops for users on Indeed and LinkedIn. On the JobSpy side there's also the JOBSPY_HOURS_OLD variable which I believe defaults to 24 hours. For someone doing a weekly job search session rather than checking daily that window is way too tight and they'd miss a lot. I had to dig into codebase to find the right variable to set in my env config for that.

On that note I've been thinking about where the most value is actually coming from in my testing. Indeed and LinkedIn have by far the largest job databases in the US and I've found the other extractors to be hit or miss. I wonder if there's an argument for prioritising depth on the high-value sources rather then a broadened extractor support.

I've been out of open source contributions for a while but I'm free right now between job searching and would genuinely enjoy picking some of this up. Would you be open to setting up a Discord or something similar for the dev side to allow for more informal discussions and collaborations. I'd want to make sure anything I work on still aligns with your vision before going too far down a path.

[DaKheera47]

i hate discord for any kind of documentation, i think we can have a chat here, this is informal enough, and this is indexable for future users too. you can DM me on discord if you want for other chats, it's dakheera47 on discord

for extractor depth vs breadth, i agree in that the current extractor breadths is enough, we just need to improve the quality of the responses coming back as much as possible. in a lot of cases, we're actually bound by our coupling to jobspy for features we want to implement, or if we want to show some data. for example, a recent example that comes to my mind is that I wanted to show the age of the posting for LinkedIn and indeed however it doesn't work from jobspy, and there is an open issue on job spy which just means that we are limited by what the maintainers there can do

For any issues you want to pick up, just comment on the one that you're interested in and we can have a chat in that issue's comments just to see what kind of implementation would be the best and I would be more than willing to look at any PRs that you have! Thank you so very much for considering it, really. Somehow it's still wild to me that random strangers want to contribute to a bit of code I wrote :)

[DaKheera47]

whoops, i realise now that the first line comes across as very cold lol

[rohanmarichi]

Sent a request, my username starts with A and ends with X if you need to find it. And don't worry, the first line didn't come across cold at all, I get the sentiment completely. GitHub makes total sense for anything that should be documented and searchable. Discord is just better for a quick back and forth when you're bouncing ideas or need quick communication that isn't related to any single issue in particular.