“Have you tried applying on LinkedIn? Messaging recruiters or hiring managers on LinkedIn?”
“Oh no don’t use LinkedIn, everyone ignores those because of bots, apply directly”
“Put keywords from the job listing in your resume so the algorithm will rank you hire”
“Oh no don’t use words from the listing in your resume or you’ll be flagged as a bot”
“Hire a headhunter to apply to many positions for you”
“Avoid headhunters because when they spam your resume, you’ll get flagged as a bot”
“Complete a tedious and time consuming project for the company and post it on your personal site so they see you’re not a bot already qualified”
“Oh they didn’t even open the link to look at it? Well do one for the next company and the next and the next…”
Looking for a white collar job today is basically an arms race with the net result recruiters spend the bulk of their time weeding out bots, and applicants spend the bulk of their time trying to not look like bots. It’s ridiculous and I kind of wish places just accepted in person applications again.
yeah, people shit on the boomer ‘firm handshake’ thing but at this rate, even as a card-carrying introvert i’d rather take my chances and at least get a feel of the place rather than filling out another godawful application that no one will ever read
One way I was able to land a job was doing the old fashioned “speak to the hiring manager and shake his hand”. She said out of all the online applications (hundreds by the way every month) I was the first person to actually go up there and express interest. Still had to put in the online application, but a week later I interviewed and got the offer.
These businesses love to dehumanize the employee pool when they should realize it’s so easy these days for them to get in the exact same position.
LinkedIn is fine, my past 2 contracts both were off LinkedIn
Yes, include keywords but spread them out, absolutely. Also include them in your cover letter.
Don’t use headhunters, but you can use recruiters.
Pick a specific tech stack to specialize in, one that is popular abd high demand. 100% yes you should have a portfolio using that tech you can link to on your resume or applications. Focus on applying to the smaller but refined pool of jobs that explicitly need the exact tech stack you have in your portfolio.
Example: I specialized in .NET tech stack. C#, azure, EF Core, NUnit, Sql Server, etc etc. The full windows stack.
It’s a super popular stack, and there’s tonnes of demand. I don’t waste my time applying for python or c++ or lua or go or rust jobs. I stick to my stack.
I have many projects on my github using that stack, including install instructions, releases, docker containers, etc etc.
As a result I can talk about the tech used in these stacks extensively, I know them like the back of my hand. I have strong opinions on patterns with them, I can teach others about them, etc.
I despise the current paradigm of mock’ing everything, abstracting everything, and unit testing 100% cide coverage for no logical reason.
Instead I only unit test the following:
Any code I truly want to unit test, because it does something that is iffy on if it works or not, I break out into atomic logic that can very easily unit test.
Code coverage is a business requirement and we already have 100% coverage from integration tests, then I’ll start worrying about unit testing the shit out of stuff.
In other words if you waste time on mindless unit tests to assert that 1+1=2 when you dont have 100% coverage on your integration tests yet, you are wasting time.
In terms of atomic code, consider this example:
<span style="color:#323232;">public class StudentService(IStudentRepository repo)
</span><span style="color:#323232;">{
</span><span style="color:#323232;">
</span><span style="color:#323232;"> public bool AnyGrade12()
</span><span style="color:#323232;"> {
</span><span style="color:#323232;"> var students = repo.GetStudents();
</span><span style="color:#323232;"> return students.Any(s => s.Grade == 12);
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">}
</span>
This would be very normal as a pattern to see, but I hate it because to test it, now I need to mock a stubbed in IStudentRepository.
Now this is what I consider atomic logic. The rule of thumb is, if the class has no dependencies or all it’s dependencies are atomic, it too is atomic.
Generally it becomes clear all the atomic logic can just be declared as static classes pain-free, and there’s no need to abstract it. It’s trivial to unit test, and you don’t have to mock anything.
Any remaining non-atomic code should end up as anything you simply must integration test against (3rd party api calls, database queries, that sort of stuff)
You’ll also often find many of your atomic functions naturally and smoothly slot into becoming just extension functions.
This approach goes very much against the grain of every dotnet team I’ve worked with, but once I started demoing how it works and they saw how my unit tests became much less convoluted while still hitting ~90% code coverage, some folks started to get on board with the paradigm.