thdc

I only go through job listings directly (though some listings may say email this person with your resume and I'm including that), and the response rate has always been low for me. I'm pretty strict with requirements and the kind of work I'm looking for. To cover the past 5 years or so:

In 2019, I submitted 400+ applications and had only 4 or 5 responses which eventually converted into 1 job. I hear the market was hot then.

In 2021, I submitted around 40 applications with 3 responses where I had 2 interviews, and 1 job offer (through HN whoishiring!) that I accepted; stopping the process with the 3rd company at that point.

Now I've been looking for 2 months, and have so far sent around 15 or so applications with 1 interview that I did not pass.

I understand that networking and referrals are basically key nowadays, but I won't do that based on my values - I think it's unfair to be prioritized based on who you know over skills - this is a hill I will die on (or at least leave my profession over).

Furthermore, I do have a solid work profile (open source, personal site, blog with mostly technical posts, etc.) but am not willing to associate my real life identity. Not because it's inappropriate, but because I value privacy.

It's probably alternating the comparisons.

Compare [0, 1] [2, 3] [4, 5] ... in parallel and swap if necessary, compare/swap [1, 2] [3, 4] [5, 6] ... in parallel, then go back and forth until no more swaps are made - second element in pair is always greater/less than the first.

That does suggest that the theoretical ideal number of threads is n / 2 ignoring cores, though you'll also want to consider things like cache line size, cache coherency, and actual problem size so it's probably less.

At the end of the day, the important thing would be to actually benchmark your attempts and seeing how it scales with processors/problem size and checking the isoefficiency.

I think it was a bad question.

Knowing to DRY there depended on business knowledge that the original author did not have.

While they were wrong in this case, I would say it was a reasonable move to not DRY based on the code pattern itself at the time. And that's the big difference imo - DRYing based strictly on the structure of code vs business processes.

I feel like I've been in this situation for the past year - the place I'm working at had a large culture shift for the worse.

I would change jobs, but I hate interviewing and everything else in the process, so instead I work at my standards and stopped trying to impose them on others.

I'm not satisfied at work, but personal projects and activities help fill the void (as a software engineer). I'm never sure if a down period is temporary or not, so I'll always tough it out for a bit.

I started looking for a new position very recently, though, since it's been long enough.

I like to think it went like this

1. Interviewer: If you're a good software engineer, you can answer basic algorithmic questions.

2. Interviewees: Practice algorithmic questions so you appear to be a good software engineer.

3. Interviewer: People are just studying leetcode to get jobs, what can we do? Ask harder leetcode questions.

4. Other companies: Let's copy them since they're successful.

In short, the questions used to be reasonable until people specifically prepared for them. No one knew what to do about it so they just raised the difficulty, which made it even more unfair for people who don't specifically prep.

Yeah around 1.5mb transferred but less of an issue with caching of course.

You also won't have something nice like $$ or \[ \] and will have to put the

    <script type="text/tikz">
        \begin{tikzpicture}
            ...
        \end{tikzpicture}
    </script>

tags directly in your markdown, if that even works.

You are correct that good code does not translate directly into revenue, but it affects it indirectly e.g. through ease of future development, maintenance, and fixes.

If the thing being written is not going to be updated at all, then, sure, quality is not important.

I like to say that users includes the people working with (using) your code in the future. It changes the definition of user compared to the normal usage, but I think it's a good point.

Email obfuscation has a lot more techniques than what would be encountered in a text response, so I find the title too broad.

I'd be interested to see attempts to extract emails from pages that utilize javascript/css. For example, I have at least two implementations of email obfuscation on my personal website:

1. for non-js users, I have a collection of elements in a noscript tag where a subset are hidden or shown based on some css which uses a combination of pseduo classes and selectors to only show the (full) email after some page interaction

2. for js users, I run some pretty trivial javascript (string manipulation to build b64 encoded string, then decode) to modify the dom after certain events fire

It's very important to me because it's an instance of one of my values - keeping something borrowed in the same or a better condition. For example, we're "borrowing" the earth/environment from future generations.

Of course, we could have a lot of discussion over what "better" means and if making X better is worth it at the cost of Y and so on, and I understand that the criteria, definitions, and interpretations could vary between people. For me, the focus should be on sustainability.

I can't have much impact on the overall direction of things as an individual, but I still try to do my part.

Arguably it's less direct due to the superlatives and exclamations. For example:

> Christ. That's literally the remap_file_pages() system call definition. No way in hell does "ON_BEHALF_OF_KERNEL" make any sense in this context.

This could be

> That's the remap_file_pages() system call definition. "ON_BEHALF_OF_KERNEL" does not make any sense in this context.

If someone I didn't know or was unfamiliar with gave me a review like this I'd frown, but since Torvalds is known for this then I'd shrug it off probably. It's a good, thorough review though.

Will you follow up with stats and analysis on response rate and further steps in the application/evaluation process? I'd be interested in that.