entee

One thing to note is that mRNA therapeutics are a really tough area in part because:

1.) RNA and the lipids used to get it inside a cell are inherently pretty immunogenic (a huge plus for a vaccine). If you think about it, you basically never see free mRNA/DNA in the blood stream other than if something has gone wrong (usually a virus), so the immunogenicity here is pretty ancient.

2.) RNA gets shunted to the liver and chopped up. Hence most RNA based therapeutics target the liver.

Vaccines are a really great use case, not just a, "we could help out here too," side-case. They're delivered intra-muscularly so there's less "go to the liver!", and the immunogenicity is a feature not a bug.

Lots of this comes from siRNA therapeutic research that is older than mRNA work, but the principles are very similar. Some older articles that touch on some of these issues:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3378126/

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3269031/

https://www.sciencedirect.com/science/article/pii/S016836591...

Agreed. Boosters will probably be required yearly or so, and those will then be the “second shot” for lots of people.

The only caveat is that partial immunization can create the conditions for viral escape, but hopefully we’ll have boosters by then.

Burying the lede:

“ While millions of people have missed their second shots, the overall rates of follow-through, with some 92 percent getting fully vaccinated, are strong by historical standards. Roughly three-quarters of adults come back for their second dose of the vaccine that protects against shingles.”

Things are going relatively well, headline is overly alarmist.

Yes. Monoclonal antibodies are single antibodies that are produced at scale. Regeneron has 2 mABs that they mix to create a cocktail. Your immune system generated a polyclonal antibody response, which is to say it creates a multitude of different antibodies against the virus. If most aren’t great, that’s fine as long as one is good enough. If a few work together to neutralize the virus, that’s also fine. If you can identify one of those antibodies as especially good, you can then clone it and make a bunch of it artificially, hence “monoclonal”.

To be clear, almost all of these studies showed very small effect sizes. The best therapeutics we have are remdesevir (small but real effect on severity, unclear effect on hospitalization and death), dexamethosone (moderate to large effect on death when hospitalized), and antibody drugs for which Lilly’s has already been remove because ineffective against variants though Regeneron’s cocktail seems quite good. Fluvoxamine is I’m sure under investigation, we’ll get a readout eventually but that’s a relatively new result.

The best drugs we have are either:

1.) treat the virus with a novel entity (Regeneron, the other antibodies)

2.) treat the inflammation (dexamethosone, possibly eventually fluvoxamine)

The repurposing and general antivirals (including remdesevir) have little effect and likely won’t make a difference. There are novel drugs being developed (Pfizer just started a protease inhibitor trial) but that’s the only place I’d expect to see real impact, with fluvoxamine as a treat the symptoms wildcard. People have been trying to find drugs or repurpose, and academic medical centers have been working on it. It’s that almost nothing works when subjected to the hard trials.

Anagenex | ONSITE or REMOTE | San Francisco | Infrastructure Engineer, Computational Chemist

We are a seed stage biotechnology company building a novel platform for drug discovery focusing on difficult targets. Machine learning has struggled in early stage drug discovery efforts because most of these efforts do not have enough data for the models to parse. Our technology solves the data problem with massively parallel biochemistry in the form of DNA Encoded Libraries (DELs), allowing us to analyze 100-1000x more compounds compared to traditional approaches. By feeding our algorithms with this data we can identify better compounds faster than competing solutions. We recently closed a substantial seed investment (2+ years runway) and are assembling a highly interdisciplinary team of both bench and computational scientists. Come help us build the future of drug discovery!

Infrastructure/DevOps Engineer: We are looking for our first back-end infrastructure hire. This person will be driving technology choices, designing and building distributed computational and model training infrastructure. This infrastructure will be used to handle billions of datapoints and train models on those datapoints to hopefully discover new medicines. We currently use a Kubernetes cluster, Spark, and PyTorch among others. Our infrastructure is functional but needs an experienced engineer to take it to the next level.

Computational Chemist: We are looking for a computational chemist to create a cutting edge drug discovery toolchain. We strongly favor open platforms such as RDKit but are open to alternatives that maximize performance. This person should be familiar with traditional SAR, structure based drug discovery, ADME prediction and have some exposure to more recent ML applications to drug discovery.

These roles are both asking a lot, and correspondingly we offer strong equity and competitive compensation. The roles are also a unique opportunity to build systems correctly from the ground up to solve a really important problem!

Odds and ends:

Interview process is generally phone and video conversations with the computational team followed by the larger team. We are currently 7 strong with both laboratory and computational people and it's critical that everyone on the team enjoys each other's company. We are also a diverse team across the company and welcome people from all backgrounds.

Onsite would be in SF or Boston where we have our lab, however our team is hybrid/remote for the foreseeable future.

We offer healthcare coverage and typical technology startup benefits.

If interested please apply on our jobs site:

https://jobs.lever.co/anagenex

It should be noted that past the early stages virtually none of that investment and valuation came from institutional VCs and people who had a clue. The valuation was driven by rich people who didn’t know any better and they sadly got defrauded.

I used to think this way, but I think it’s a mistake. If something happens to men but happens far more often to women, then there’s a problem. The fact that we keep hearing about these stories, with various shades of face-palming awfulness should be a sign that something is wrong. “Use your femininity”? I’ve been working professionally in various STEM positions for 15+ years, never once has someone told me to “use my masculinity” to help smooth a working relationship.

We can assume that all of these people, across the industry, in dozens of different contexts are all just whining, or we can do some introspection and wonder if we could do better. Even if some things are unintentional, if they make people en masse feel less welcome, we should re-examine how we do things, and if they are truly necessary.

I’ve personally known several women who are insanely smart and good at what they do who have felt rejected, mistreated and unwelcome in tech. It’s a tragedy they faced that, and it’s sadly way too common. We cannot deny there is something systematic at play here.

Note that as far as I know, all the founders of FAANG were white guys. As for why many Asian people work there, I think there is a strong bias toward engineering/medicine among many immigrant communities that came from a relatively educated background in their home countries (I count myself in that cohort, though I’m not Asian). Crucially though, once they got into the community they were more likely to blend into the group at every stage.

It’s hard to be the only one in a class/company/group that looks like you. That’s a big obstacle and we should be more supportive of those who overcome it.

Also, while Asians make up a large portion of line engineer positions, they make up a smaller fraction of leadership positions. That’s troubling to me as well.

To be clear, I don’t think input pipelines are not a problem at all, I think they’re just a part of the problem. Sounds like this person is doing things right by investing time and effort across pipeline AND developing talent once hired. You can’t have success without both and the latter is often a secondary consideration at best.

Fully agreed, there's a whole lot going on beyond stories of bad experiences. It's a complicated issue, I just think we're focusing on the wrong problem if we're just looking at this from a pipeline point of view and not asking what factors contribute to the pipeline being sub-optimal. Too often I hear, "women just like people more than men," and other similar BS, which lets us as an industry off the hook for creating sub-par environments.

Surely it does, a culture that makes people feel unwelcome and doesn’t invest in helping them thrive in an environment where they are in the minority definitely plays a role.

Respectfully, this is the wrong way to look at the problem. It’s true, objectively, that there are fewer minority/female CS graduates. But there’s no way that gets better if a person who is “not a subject matter expert” gets dismissed. That person needs to be trained. If they want to be expert at that subject, we as an industry need to be able to help them get there.

Increasingly I believe the problem with diversity in tech is a retention and training problem, not a pipeline problem. If you’re a woman and you want to be a coder but all you hear about is hell stories, why would you sign up for that major? Our job is to make those who are generous enough in spirit to decide they want to do this thing, in spite of all the pain they might face, the best coders they can possibly be. Only then will they be able to provide the positive reinforcement necessary to improve input pipelines.

Same applies to any underrepresented group.

Can someone better versed in this area give a decent sense of how this works and whether this is feasible? Also, as the article mentions, given an unencrypted dataset similar to the original, couldn’t you figure out important elements of the underlying data by brute force reverse engineering of the resulting algorithm?

I'd have loved that at the time! But clients don't like it when we ask them to fix these things.

Less flippantly, with large organizations, the people giving you the data aren't necessarily the people who entered the data or have the ability or skills to fix it. They may also be legally prohibited from altering the data, so correcting errors can get tricky.

Obviously, for downstream analytics you need good data, so we have to fix it as well as possible. Usually, it involved a lot of back and forth with the client. We'd tell them things like, "you have a lot of dates that are set as January 1, 1900, we'll treat those as undefined, does that make sense?" That's why a tool like Great Expectations, especially as it adds data introspection features can be super helpful. I can write a quick spec, compile a report and send the client that report in record time. Even without major errors, the client has all sorts of tribal knowledge about how to use that database is used, and often you have to deduce those rules or do good data introspection to ask the client the right questions.

It is the bare minimum to do data tests throughout your pipeline, but a good, open source, structured framework that I don’t have to write myself is kinda nice ;)

I can then separate testing from the transformation code (which yes, should be tested too in unit tests and the like), and use this tool as an audit to say, “did my code do the right thing on the dataset in this latest ETL?”, and “where did it screw up?”

You can also use it to write a specific data spec and rely on the tool to guarantee that spec. It’s a lot easier to write a spec than the tool that does the checking. That spec also documents your data standard, is machine readable, and versionable.

Ideally the cost is low, you spend 15m with the client data dictionary, write the spec, and then go have a coffee while the tool sees and highlights where the dataset is out of spec.

You’re missing the need this product addresses. It’s not about your database, it’s about the data someone sent you that you’re about to ETL into your database.

I used to work at a medical ML company, the datasets we got from insurance companies and medical providers were generally awful. Occasionally, it didn’t even match the data dictionary they themselves provided. If you need to connect to or ingest outside data sources or check the output of an ETL pipeline, this tool is extremely useful.

We were experimenting with this a couple years ago and were very impressed but it didn’t quite fit into our workflow at the time (mostly our fault). Really cool to see how far this has progressed, it’s a really helpful tool that should standardize all sorts of necessary data checks especially in gnarly, human entered datasets.

It’s also apparently a closed protocol, so Zwift and third party apps can’t use it. Maybe peloton will open that up at some point, it would bring it a new market. I have a bike on a wahoo kickr core and it’s great, and I don’t have space for a dedicated bike. If I did, I’d totally go for one of the newer all-in-one bikes (easier, less hassle) and peloton is interesting if it can do the same things as that hardware.

This. Management is harder than many, especially junior, engineers think. The key is that you have to intrinsically want to do right by your team, sublimating your ego for the greater good of the whole. Not everyone does, and to me that’s table stakes for management, it means the person has the raw material to be a decent manager. That said it’s not sufficient. The hard part is trading off the team needs and desires versus the larger strategic imperatives. That and resolving conflicting priorities within the team.

Still, “doing right by the team” is distressingly not universal, or even when present, many don’t actually know how.

Admittedly I know few, but not zero. That said they’re all relatively older and have been in the business for a while. I used to manage a team with 4 racks, ~40 machines at a COLO. When we hired for new people, it was usually older folks who had the experience necessary. Maybe you’re right and I agree the concentration is disturbing.

My only response is that when I look at bigger orgs and places like Fortune 500 cos I still see/hear about home built server farms, so those people must be out there. I think maybe we get blinded in startup/SV land and only see people using cloud infrastructure but miss a huge, silent mass of people.

I think there's a risk here but I'm not sure it goes as far as you suggest. There are still plenty of entities, particularly larger ones, that buy their own metal because at some scales it becomes far cheaper to run in a COLO (at least acc to near monthly articles posted on HN). I'd therefore put the risk that only big vendors will be able to buy hardware as low. That said, as ARM or custom chips gain market share within cloud providers, there's a risk that x86 or standard suppliers will struggle, but AMD/Intel see this too and surely one or both will adapt.

On skills I think there's a small risk of people not knowing how to manage/set up their own racks, but doing a passable job there isn't that hard. On general sys-admin stuff, cloud infrastructure seems to have parallels to hardware infrastructure, so it shouldn't be completely unfamiliar to set up a hardware router/network/linux server. There are definitely skills and details missing (remote admin tools for hardware maybe), but this doesn't seem like a big gap to bridge if $$$ is on the line?

Really hard to do. Not because it’s a bad idea but because it’s hard to identify a vacant apartment. One example using utility bills as proof of residence can be gamed by paying people to go turn on the lights for a while. How can you tell that the property is actually empty?

I can’t say what percentage of wealthy people did this versus just regular asset hiding, but it happened enough to be visible among Belgians (my family lives in Brussels). Either way, hiding assets is relatively easy if there are millions of dollars on the line. Also, moving to CO or UT is even easier than moving to Belgium from France.

Put another way, the more complicated the tax, the easier it is to find loopholes. It’s basically impossible to write a simple wealth tax. If you do, you end up capturing people who shouldn’t be captured (for example a founder with illiquid stock and purely paper wealth). I’m actually all for taxing income pretty heavily especially in a progressive manner. Better yet, tax consumption. I think a luxury consumption tax, especially one that penalizes things like expensive cars, jets, boats, and similar would be a more effective way to tax the rich.

Thing is we’ve done the experiment and it doesn’t work. France had a wealth tax (called the ISF, impôt sur la fortune) and it never actually garnered the expected revenues. This is because wealthy French people moved to Brussels, where you still have a pretty nice city and you can still speak French. Macron got rid of it and there was a mini-crash in Brussels real estate as people move back. There’s nothing stopping me or anyone in CA to move to CO or UT or TX. Sure I’m further from the ocean but those are still pretty nice places to live. I love CA and I’m very far from the $30M threshold, but if I did have this sort of tax it’s hard to justify not moving for lower taxes AND cheaper cost of living with very little downside. With the rise of remote work, there’s even less of a downside.

I’m pretty sure that despite the fact that statistical models are used in credit scores, those models are subject to regulatory review. For example, I’m pretty sure a “black, therefore, no loan” algorithm is illegal, regardless of whether that parameter was learned or programmed. It’s a huge problem in some of these models that latent racism can bubble up into a putatively unbiased algorithm. In some industries, including finance, I think that can expose to some regulatory risk, hence explainability being quite helpful.

I think that’s totally true in cases where the market is a rapid and reliable feedback mechanism. It’s a delicate balance, and I can see how a large bank account leads to avoiding the hard choices or the rapid iteration necessary to find a good product market fit. See Quibi.

However,in some industries, the relationship isn’t quite as straightforward. I work in biotech, so in my case the market is realistically not going to be part of the story until we have a drug, which will be a long time from now. Until then our “market” is pharma partnerships or financing opportunities, both of which are only partially rational exercises in value determination. For us, lots of money is helpful to weather the storm and really build a great technology. There’s also little risk that if we treat a disease, we won’t have people want the treatment, so product market fit isn’t quite the same issue.

That said, it’s easy to lose focus by forgetting that the tech isn’t the point (finding a good drug is) and that we can’t try all options. But those are in our control.

I think it really depends. Money in the right hands can be amazing because you can aggressively pursue an idea that takes a lot more money to get off the ground. This requires a clear idea of what matters to the business. If you don’t have that idea, money can allow you to pivot and tune your product quickly and hire the very best.

The downside is the temptation to do everything, to not make decisions. Money enables you to do that too with disastrous results.

In short, money is great. Not having a clear, disciplined strategy is the problem.

Anagenex | ONSITE or REMOTE | San Francisco | Lead ML Engineer, Computational Chemist

We are a seed stage biotechnology company building a novel platform for drug discovery focusing on difficult targets. Machine learning has struggled in early stage drug discovery efforts because most of these efforts do not have enough data for the models to parse. Our technology solves the data problem with massively parallel biochemistry in the form of DNA Encoded Libraries (DELs), allowing us to analyze 100-1000x more compounds compared to traditional approaches. By feeding our algorithms with this data we can identify better compounds faster than competing solutions. We recently closed a substantial seed investment (2+ years runway) and are assembling a highly interdisciplinary team of both bench and computational scientists. Come help us build the future of drug discovery!

Lead Engineer with Data and some ML focus: We are looking for our first computational hire who in time will help build and manage this team. This person will be driving technology choices, designing and building data architectures. These systems will take in raw experimental data as well as other information from lab instruments and integrate that data into models predicting several biochemically relevant properties. A flexible skillset incorporating database design, familiarity with current data pipeline tools, and ability to engineer practical solutions to a variety of computational needs is a must. We favor python, but aren’t dogmatic.

Computational Chemist: We are looking for a computational chemist to create a cutting edge drug discovery toolchain. We strongly favor open platforms such as RDKit but are open to alternatives that maximize performance. This person should be familiar with traditional SAR, structure based drug discovery, ADME prediction and have some exposure to more recent ML applications to drug discovery.

These roles are both asking a lot, and correspondingly we offer strong equity and competitive compensation. The roles are also a unique opportunity to build systems correctly from the ground up to solve a really important problem!

Odds and ends:

Interview process is generally a few phone/video conversations and some small practicum work, but is adapted to the individual at this stage of the company. Also expect 3-5 conversations with other members of the team to ensure culture fit (we're 3 strong now, everyone needs to get along).

Onsite is expected to eventually be in SF, but we are launching a Boston location for our lab operations. Of course, given the pandemic is hybrid/remote for the time being, and is likely to continue for longer term.

We offer healthcare coverage and typical technology startup benefits.

If interested please apply on our jobs site:

[https://jobs.lever.co/anagenex]

Nice! I always assumed unless there was a known crystal, you’d be in for pain. “Good and globular” is the way to go I guess.