I am a low-level Windows developer with extensive knowledge of Windows internals, Win32/NT APIs, debugging, research, etc., and—most importantly—expertise in the Windows logon area, credential providers, and related technologies.
For the specific position I mentioned, I don't think there are thousands—or even dozens—of truly good candidates. I’ve outlined my reasons based on general factors (such as my Stack Overflow rating) and specific expertise in the field of credential providers—for instance, I am the only one who has published a list of interfaces like this one: https://github.com/rbmm/StateMachineState/blob/main/ni.h. There are even YouTube examples demonstrating the use of some of those elements (https://www.youtube.com/watch?v=5SpEfFGE5N8), along with many other things directly relevant to the role. If I were just one of dozens of candidates, I wouldn't be asking this question (I wouldn't have the standing to do so).
I watched a few videos, but I didn't understand them. Do you have a blog?
I'm not sure if it's helpful, but there is an official monthly post for jobs https://news.ycombinator.com/user?id=whoishiring You can take a look at the current last post, but they are read only now. Also, you can post on the correct thread next month on October 1st.
I watched a few videos—maybe that’s because it’s a very niche topic, and you personally aren't involved in this specific field.
Actually, my question had two parts. The first was general—less of a specific question and more of a general observation.
I believe the current selection process is deeply flawed for both sides.
It’s particularly bad for unconventional candidates (though that’s always been the case). The search for a résumé—which has to follow a specific format rather than just any style—has become an end in itself, even though it’s merely a tool, not the actual goal. And now, it seems like tons of people are using AI to write "perfect" résumés and heavily embellish their knowledge and experience. (Personally, I don't get the point of lying; if they believe you and hire you, that kind of lie—about your actual capabilities—will be exposed immediately. What do you gain in the end other than disgrace?) This breaks the process even further.
The second part was strictly personal. I’m wondering if there’s any way to get in touch with the team handling this position—bypassing the standard process.
I say this because I genuinely possess unique knowledge and experience in the key required areas (low-level Windows development, credential providers, debugging all of that) and had some public proof of this—like my Stack Overflow ranking, for instance, which—unlike a résumé—can't be faked (and can look up "rbmm windows"). but, I can't even apply for the position or make myself known. So, I was asking if anyone happens to know people there (despite slim the extremally low, i nothing have to lost).
Thanks for the whoishiring link. My expertise is in a very narrow, specialized field. There are incredibly few job openings that actually suit me (I don't just "apply" (not in direct sense) for everything; I only target roles where I truly have specialized knowledge and experience). There are literally only a handful of them. However, it has now become absolutely impossible to reach them (following the loss of LinkedIn)—though I suspect there are very few people with deep expertise in such fields too.
Everyone has their own strengths and weaknesses. I’m a developer. I’m good at writing and debugging code. But writing articles isn't my thing—even on my native language, not say already on English (despite the language itself isn't the main issue here). I used to post technical posts on LinkedIn. Not in the style of The Old New Thing, but just about things that were somewhat interesting and not widely known. The posts weren't high-quality, but they did earn me over 2,300 followers there. However, a year ago, LinkedIn deleted my account. So, all of that is gone forever (I didn't back it up anywhere else, and I don't have a personal website). That means my claim about the LinkedIn posts can't be verified anymore. I’ve written a few article-like pieces on my GitHub—for example, https://github.com/rbmm/tbal (or https://github.com/rbmm/StateMachineState). They were nothing special—not top-tier quality. A few years ago, I collaborated with someone, and we wrote some articles together for his site (I provided the technical info, and he did the writing): https://dennisbabkin.com/blog/author/?a=rbmm (We haven't worked together for several years now). To me, it’s nothing remarkable. In any case, my main "creative output" was on LinkedIn. It never even crossed my mind that the platform could delete everything. When your account gets flagged as "restricted," it doesn't just switch to read-only mode where you lose access; it means a total wipe—everything gets deleted: all public posts, all conversations (including the ones with other people). For instance, I wrote about my framework for writing shellcode in C++ simply and efficiently using native code—okay, I think it’s the best implementation of its kind available publicly. I used to write about various other utilities and research projects of mine, amusing PoCs, and little-known techniques. At least there’s still Stack Overflow with its objective reputation (rating) system—though, in reality, it doesn't bring me anything, and the topic I primarily answered questions on (WinAPI) is pretty much dead these days. That leaves GitHub (obviously, I don't make all my projects public) and the occasional YouTube video.
Hi from Argentina! For HN comments, I just write them and they may have a few typos. For long post, I use Google Docs to write the draft because it detects most errors.
> LinkedIn deleted my account
:( I tried withe the WaybackMachine, but It's not cached there.
> The posts weren't high-quality, but they did earn me over 2,300 followers there.
It's hard to know what other people will find interesting. If you decide to start again and make some blog post, you can post them here. (Not too much, not too short, not too long, bonus points for photos or screenshots, ...) Don't expect that to get a rain of job offers, but it's a nice hobby for when an interesting problem appears and deserve to be shared.
I’m simply looking for a job—nothing more. I posted updates on LinkedIn solely to draw attention to myself, hoping to turn that into a position; writing articles for their own sake doesn't really interest me. In reality, though, it hasn't helped at all. I’m trying to reach out only regarding roles where I possess—in my view—extensive knowledge and experience in the key area. It feels impossible to land these roles without an inside contact, which is why I asked about Duo Security. Then again, to be honest, even that usually doesn't help—but I try to seize even a hypothetical chance.
what is shared mode ? this is by fact optimization for speed, if we need read-only access to data, we allow to system let another thread into the section that requests shared access also
allow but NOT DEMAND this. If one thread has acquired the shared lock , other thread can acquire the shared lock too. but only CAN. in some case system not let another thread enter to lock, despite it also request share access. one case: if another rthread request exclusive acess - he begin wait and after this - any thread which acquire even shared access to lock - also begin wait
If lock_shared is called by a thread that already owns the mutex in any mode (exclusive or shared), the behavior is undefined.
and
Shared mode SRW locks should not be acquired recursively as this can lead to deadlocks when combined with exclusive acquisition.
why is this ? because if between 2 calls to lock_shared ( AcquireSRWLockShared ) another thread call AcquireSRWLockExclusive - the second call is block.
the code in example make assumption that ALL threads can enter to lock at once. that if one thread enter to lock in shared mode, another thread also ALWAYS can enter to lock in shared mode (if no exclusive requests). but i not view clear formalization of such requirement. and we must not based on this.
i be will add next rule:
thread inside lock must not wait on another thread to enter this lock
this is obvivius for exlusive access, but not obvivous to shared. but must be cleare stated along with the recursive rule ( should not be acquired recursively as this can lead to deadlocks, even in shared mode)
The read threads block because the ReadWriteLock algorithm tries to prevent thread starvation (i.e. when the exclusive lock never gets acquired). Most ReadWriteLock implementation alternate between giving the read locks then the exclusive locks access to the lock.
of course - SRW lock allow shared access only if no waiters ( request to exclusive access) on lock. so even if lock in shared mode, new shared request can block, if was waiter(exclusive) already. in case OP no exactly this, but anyway - i be say that shared access is only hint to system, that it can optimize access - and allow multiple shared threads inside lock. but this was not always
https://github.com/rbmm/SRW-2 - possible better repro code . where i guarantee repro this without hundreds loops. i be say that "question" in RtlReleaseSRWLockExclusive implementation. it first remove Lock bit from SRW (and after this any thread can enter to lock) and then call RtlpWakeSRWLock. but this 2 operations not atomic. if in the middle (after Lock Bit removed and before RtlpWakeSRWLock executed) another thread acquire shared access - it got exclusive. and RtlpWakeSRWLock also "fail" after this - not wake any waiters. but when shared/exlusive owner then release lock..RtlpWakeSRWLock will be called again and self job. i be of course use bit another implementation, link to which i paste in another comment here
The lock in unfair. We are unfair because you get better performance by not allowing the lock hold time to be extended by context swap. As a result, we always unconditionally release a lock when an exclusive acquire is release or the last shared guy releases. Then we go find people to wake. In this gap the lock can be stollen. The threads that steal all look like exclusive guys.
My overall rule of thumb is that in the presence of any exclusive acquires you can never assume a shared acquire is compatible with any other shared acquire. A second shared acquire might wait for the first acquire to exit. We do this for example, so a stream of readers don't starve a writer. This is another case like that but somewhat less obvious.
I have no idea if the owners will attempt to fix or take the view that you're trying to assume something we don't guarantee. I'll admit that this is a kind of strange case. You could obviously queue a wait block and the in progress waker will sort this out. Could well get a performance impact from that.
I tried to explain this general rule of thumb to you this morning when you contacted me. I could not understand much of what you said.
> My overall rule of thumb is that in the presence of any exclusive acquires you can never assume a shared acquire is compatible with any other shared acquire.
Contract #1: In reader writer locks in general, after I share-acquire a lock, I know that there are no active exclusive owners of that lock and won't be until I release my shared lock. I can also expect that as long as I hold this shared lock, other threads can share-acquire the same lock without waiting. ony share-exclusive threads would have to wait.
This general contract seems useful to me.
The contract you're describing, contract #2, is one in which shared-acquire is an optional optimization over exclusive-acquire (not a contractual guarantee) and that the system is free to promote shared to exclusive lock acquisitions.
This other contract seems finnicky and error-prone.
It's typical not to allow a second share acquire to proceed if we have an exclusive waiter:
t1: share
t2: exclusive so waits
t3: share also waits
Thats how we arrive at the rule that shared acquires in anything, but a trivial system (no exclusive acquires) may not be compatible.
So, contract #1 is typically not satisfied. Of course, this particular case is slightly different and so you might decide to support it.
Blocking new readers when a writer arrives is perfectly good and desirable. Blocking readers when the writer finishes, and there isn't any new queued, is definitely not.
I meant that contract #1 is that when I, thread A, already have a lock held in shared mode, I can expect shared-acquires on thread B to succeed without my first giving up my shared lock. The problem that we're discussing here is that I, A, can ask for a shared lock but actually and unknowingly get an exclusive lock. There's no exclusive-acquire involved.
"other threads can share-acquire the same lock without waiting."
can but not always and mandatory. you really allow to system enter another shared requestor. but only allow,not demand. system not let shared requestor enter to lock, if before it the exclusive request will be. after first exclusive request - all next shared request will block, util this exclusive request not acquire and then release lock. can be and some another reason, in the end - this is only optimization - you only *allow* multiple shared enter at once. so i be not say that this is implementation bug
yes. after any thread request exclusive access to lock, the sequential shared acquire request will block. this iswell known fact, i hope. this is example when shared request will be blocked, despite shared owner(s) now inside lock
if say true - i here in very strange position. i am by self under debugger research exacly what happens in concrete case and create repro code. i think that implementation of the RtlReleaseSRWLockExclusive is not the best and may be really containing "bug" as i in more details describe in comment on reddit. but from another side, if you want pure formal c++ rules - can you explain - in what exactly was bug in concre case ? what rule/guarantee is violated ? why demo code decide that ALL shared waiters can at once acquire the lock. formal documentation not state this. this intuitive must be true, because no exclusive request more. but.. i really dont know. and i also for fun create own implementation of SRW lock ( if someone interested to look -https://github.com/rbmm/PushLock ) which free from this roblem - i always ( hope) do only single atomic change to lock state during api call. and finally - sorry for my english and too long answer
they have slightly worse performance compared to MS, when high contention, but in test with this OP case - work well. in my test i not found bugs in implementation, but of course can not be sure that they not exist, very complex logic really. nobody test this, however very simply replace SRW calls to my implementation, by macros in h file
I am a low-level Windows developer with extensive knowledge of Windows internals, Win32/NT APIs, debugging, research, etc., and—most importantly—expertise in the Windows logon area, credential providers, and related technologies.