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.

Here's an older submission about using ChatGPT to de-obfuscate the more basic methods:

https://news.ycombinator.com/item?id=38150096

Some comments claim that it can break some of the more complex techniques presented in the article. I've tried it a few times myself with varying results that tend towards not working.

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.

I use TikZJax https://tikzjax.com/ (wasm tikz).

It works well, but you have to figure out the markup and dynamically styling the images are difficult; For example, to make darkmode work, I have to apply css filters over the generated svgs.

It also doesn't show anything if javascript is not enabled, so I duplicate the contents into a noscript tag as part of my site's "build" process so users can at least know a tikz diagram is supposed to be there.

I have an entire custom build process though, so that might be why it was straightforward for me to incorporate it.

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.

Agreed, they have a pretty nice setup for a "big" company. I've been contributing code to Mozilla for the last few years despite not working there and I got started on https://codetribute.mozilla.org/

The most annoying parts would be familiarizing yourself with mercurial/phabricator and getting commit access for certain projects.

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.

I think this is a perfect example of why "We don't have Senior Engineers anymore".

It's hard to show the thinking process to others, so the person who says an answer faster is assumed to be better/more senior.

Yep, but op also mentioned spammers that get through signup without being flagged and having to go and manually flag them.

My thoughts on the loop overall are:

- maybe users are false flagged but not complaining because the "bugs" are rare enough

- spammers with automation may brute force through the "bugs"

- handles manual spammers well because they will encounter the "bugs" more often and just leave; or they'll report it as an issue that you may have to look into.

To draw a comparison with my own experiences, I have to jump through hoops when I visit sites with bot detection or other related security measures. I am the normal user being flagged as a spammer being frustration looped in this case.

I assumed that the two paragraphs were connected

> Enter Akismet. This is a spam detection tool by the Wordpress people and is pretty accurate and easy to use.

> Blocking spam on signup worked somewhat, but was easily circumventable by spammers who are well versed in dealing with these kinds of barriers.

But now that I look at Akismet's description, it sounds like Akismet does a lot more than block on signup. Perhaps they use it after signups but apply the frustration loop instead of blocks because it's less accurate there.

I'm missing the part on how op determines valid users for the frustration loop.

> Enter Akismet... Blocking spam on signup worked somewhat, but was easily circumventable

> some spammers found ways to parade as legitimate blogs... which I would have to manually sniff out and flag.

> This lead me to an idea: The Frustration Loop... When spam is detected... Waste their time and make them give up.

> "Now hold up there Herman! Won't this be triggered by valid users?"... it's been running in production for the past 3 months and I've only had one user report this as an issue.

imo that would be the most interesting part of the article. It's cool that the action that's being taken is to frustrate the spammer but I wished there was more info on separating spammers from real users, figuring out false positives and false negatives and the like. I understand that giving details on detection is probably not a good idea and that the article is about The Frustration Loop, though.

A quick glance at the script (I may have missed important parts) shows that everyone costs the same so you should only need to consider the effectiveness of the type of hire; every type has a manual click button effect and a daily automatic effect that scales with count which affect growth and product quality which affect users and valuation.

=

Developer:

write code: growth + 0.3, quality + 0.2

automatic: (growth + 0.3, quality + 0.1) * developers

=

Designer:

create design: growth + 0.1, quality + 0.2

automatic: (growth + 0.2, quality + 0.1) * designers

=

Marketer

promote product: growth + 0.5

automatic: growth + 0.5 * marketers

=

And quality caps out at 4. So I guess focus on hiring developers/marketers and writing code until product quality is 4, then just marketers until you run out of money. Poor designers...

> (in selected cases)

The tweet presents the quote without context so I interpret it to be a sweeping statement and therefore disagree based on that. If someone could provide a transcript of the cross-examination (I couldn't find it easily), then that could help with making a more informed opinion.

Yeah, it seems like the author is storing more information than just the position but not enough to figure out all of the possible next states of the game.

Another straightforward thing missing is the player's turn; this could determine whether the position is a stalemate or not.

You would still need a STUN server, though there are many public ones out there.

The main idea in removing the signaling server is to somehow transfer the session description between clients e.g. one client scans a qr code that encodes the session description of another or sending session description through some existing chat application and allowing a user to enter it manually instead of having your own server do the transfer over some mechanism.

Also it may be possible to avoid the multiple qr code thing this blog is talking about (qr code per ice candidate) if you just wait for the ice gathering state to be complete then send the session description, though they are correct that the session description in its entirety will most likely exceed the qr code capacity (coincidentally they use LZ compression in an attempt to lower the length, similar to what I tried long ago though I ended up deciding it wasn't worth it).

I'm all for alternative sources of energy (including nuclear) but I feel like generating and storing nuclear waste for future generations parallels how coal/oil/gas/etc. ruined the environment that our current generation has.

What are some points that I could use to differentiate the two ideas? e.g.

- not enough waste to be an issue

- waste is properly secured so won't be an issue

- less impact than coal/oil/gas

I would argue it is quite similar to an Angular.js moment, even if it's not a breaking change.

> React suggests mixing server-side and client-side rendering, using what feels like black magic. You can use client components in server components, and vice versa.

This is reminiscent of hybrid Angular apps[1], which allows you to use both Angular.js and modern Angular components together and was introduced to help the upgrade from Angular.js to modern Angular. The only issue is the "black magic" there isn't as good as advertised and you'll run into many holes if working on a moderately complex hybrid Angular app.

I can only hope that the "black magic" for a mixed React app is more complete, though lack of documentation for the wire format that the author pointed out does not inspire confidence.

Interestingly enough, there is a picture of a tree of mix of components[2] on the Angular upgrade guide which parallels the one in tfa. It is basically why I think these scenarios mirror each other: an introduction to a new paradigm which can be used with the old one in a mixed/hybrid application (and a possible lack of documentation which will make that application terrible to maintain without fully transitioning to the new or old paradigm).

[1] https://angular.io/guide/upgrade#how-ngupgrade-works

[2] https://angular.io/generated/images/guide/upgrade/dom.png

I wonder how the employee who purchased a multi year lease for a cruise cabin in anticipation of permanent wfh feels

The most entertaining part of when I first ran into endless verification loop/Cloudflare error codes is that I couldn't access their official forums/support articles for information due to the same problems.

Same here, I may browse various places periodically in search of an interesting article/content but I don't aim to be informed of every current event.

I may research topics individually if I want to "catch-up" (learn) about something that someone else has brought to my attention.

A senior interviewer's guide to the system design interview*.

I've speed read over the existing two sections and while it's informative, I'd argue that the maybe 10+/12 of the core design concepts are things that someone with a formal CS education should have picked up - you don't need to be a senior software engineer.

The barrier is knowing how these things can be pieced together to make a system from scratch which is the more difficult part as it is a much rarer occurrence in most people's experiences. Even seniors may not have much experience in setting up large scale systems (depending on your definition of senior), so at the end of the day anyone that studied or memorized the material is good enough to pass - practical experience or not.

I'd much rather have a high level view of an existing or theoretical system, be provided with some issue that occurs, and be asked for ways to diagnose and remediate said issue. Forget the dance around setting the system up. This is similar to the practice of providing existing code in an interview, describing a bug with the code, and watching the interviewee debug and fix it - but with systems. It mirrors actual work more closely.

I tried it on an iPhone and noted that it said I visited several times before even though this was my only time. Previous instances varied in IP, incognito mode, and location.

This was through the demo on their main page fingerprint.com > view live demo using Safari w/ private mode and some ad blocking extension.