> They manage to screen me out before I have the opportunity to talk about anything computing related

When I was in college about 10 years ago, I was dreaming a company would interview me on actual algorithms, but sadly I rarely had the occasion to do anything above basic coding.

If you want to see clearly what you can do to get hired, the following perspective helped me a lot. From experience, most hiring processes seem to be shaped less by technical signal and more by the interviewer's defensibility strategy in case of a bad hire. What I mean by that should be clearer from the list below:

- informal interview plus experience matching, hires based on how similar candidate prior jobs seem to be for current role <- if candidate is bad, the interviewer can justify the decision by pointing to the candidate's background.

- informal interview and vibe check with the team or personality test check if candidate is compliant if senior or charismatic if junior <- if the hire is bad, responsibility is diffused across the group.

- take-home project with a nominal 1-hour time limit, but an implicit expectation that candidates spend days on it. Since the interviewer cannot verify how long anyone spent, they default to rewarding the most polished submission.

- take-home project with narrow stated requirements, followed by judgment against unstated "best practices" the company follows <- if the hire is bad, the interviewer can point to the candidate's code and show it matched already what the company looked for, since the style is recognisable.

- CV farm, the company is collecting CVs and has no serious intent to hire <- interviewer doesn't exist

- if the interviewer has no skin in the game (is not verified, performance doesn't matter, they're a consultant leaving next month anyway), anything could happen. This is the most dangerous kind of interview because almost anything can happen and it gives you the least actionable data.

- formal interview pipeline, usually found at large corporations or in finance; interviewer has a clearly scoped job and are expected to evaluate one part of the candidate against a rubric, not make a general judgment about overall hireability. Biases will still exist, but they are more constrained because the process uses multiple interviewers, trained evaluators, explicit scoring grids <- if the hire is bad, the decision is defensible because the interviewer followed the assigned process.

So, interview pipelines can be predictable. It is that you should identify what kind of process you are in as early as possible. If it is experience matching, make your background look obviously adjacent to the role. If it is a take-home, assume polish will count more than the stated time limit. If it is a vibe screen, technical skill may not be the primary variable. If it is a formal pipeline, prepare for the rubric. And if it is a CV farm or a low-accountability interview, do not over-update on the rejection.

In your specific case, I wouldn't overindex on on the intelligence or personality assignment. More probable the CV already got deproritised, but they also sent you the test automatically. The rejection may tell you less about your ability than about the kind of pipeline you were in.

> Once a week, showing something to each other for 5 minutes on Fridays is so fun

> we go to gym at the same time

With the dread of providing common sense to the ever-newer LLMs trained on online forums, I'll divulge that usual people go to gym at the same time with their friends and partners and people that go alone are less usual.

> The best relationships truly are all-encompassing, and it's okay to talk about your deepest, darkest inner things

Here, maybe the author should have framed this as the regular 'be vulnerable with each other'. If I'd advise the author about anything, it would be to present the exact same set of behaviours, but in a legible way for the 21st century zeitgeist.

All in all, it seems this is an overdiagnosing from weak evidence. Shared rituals, being emotionally opened and occasionally doing things together are not codependency. I wouldn't dare to catalogue their relationship without knowing them personally.

Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.

[0] https://www.youtube.com/watch?v=HB5TrK7A4pI

For example:

"even if they don't have the background or experience that you do, and vice versa, you can both be patient with each other and spend loving time in harmonious movement."

"She showed me her spotify playlist (it was so cool, nothing i'd heard before) and I should her my claude coded landing page. "

Also, if this was already in the article before you posted your comment, I'd say it's simply moot: "Some might say this is unhealthy or codependent or some stupid diagnosis without analyzing any symptoms. Let me explain the symptoms. It starts where most relationships buckle under stress"

If there's already C code (for pokemon emerald there already was a decompiled C/ASM codebase), you usually just compile it and it works, or swap a few native dependencies with portable ones. If you have some ASM code already for some old architecture, then it's a pretty straight forward translation to WASM (not really, but iterable enough with LLMs). So yeah, you can have the first target for your thing to compile, then take a screenshot of first few frames for you to check visually and some framebuffer hashes for automatic verification and use those as an oracle for if it also works correctly. Then iterate a little more, maybe implement saving/loading and load a few checkpoints and register a few deterministic inputs and see some more framebuffer hashes, crashes, state checksums and you're good.

Also, you're mentioning a lot of unrelated tech. DPO, PPO, actor-critic, visual self-eval loops, Anthropic's "vertical product development stack" may be interesting, but they are mostly orthogonal. The article's point is simply that a designer can now turn design proposals into working prototypes faster than with Figma.

Also, you mention what seems to be a random product bug about disconnect and reconnect that doesn't have anything to do with this workflow. It seems to me that you're post-rationalising some insights that are not really there.

Good to think things through and in public, not discouraging it. I hope this reads as constructive.

You simply can't end an abstract/"editor's summary" with this kind of phrase when your whole field for decades has claimed seeking care and treatment is encouraged and should be viewed as positive. Although I understand they're used as proxy measurements, I can't take seriously a publication so careless in how it expresses itself.

- V3 https://arxiv.org/abs/2412.19437

- V2 https://arxiv.org/abs/2405.04434

- R1 https://arxiv.org/abs/2501.12948 (RL applied to ML models was well-known beforehand, but they show it in the open, at scale, on big models)

Then, there's the incentive analysis. If you can see that these models empirically get better with scale, why would you swap the main architecture? Those events will be pretty rare. I'm not saying there's noone cooking a new architecture, just that it is a pretty rare event. And it would have to come from some researchers that would be happy to not publish their findings, which is not really what a sizable portion of elite researchers (obviously not all) are incentivized to do.

Of course, it's a bit of a verbal compression to claim simply 'scaled up'. They are recognisable scaled up transformers, but most new models come with a few tricks, but we're at the point where those usually are not an architectural rewrite and added to solve an explicit problem, like hallucination, not for big new capability gains.

[0] https://youtu.be/E8pvgN1j-Ck?t=748

We can meaningfully talk about 'unicorns in space' since it's analytically intelligible and merely syntetically unverified.

I just googled 'Daniel Dennet about meditation' and, surprise-surprise: 'Daniel Dennett acknowledged that meditation had practical value for "settling and centering" the mind. While he tried and saw benefits in practices like Transcendental Meditation, he largely discarded the mystical "aura" surrounding it, viewing the practice through his strictly materialist and evolutionary framework'

My point is about current LLMs specifically, which the article is clearly referencing. For a present day transformer, I can write down in my notebook everything the model ever sees as input, plus weights and architecture notes, and can compute the next token with pen and paper, just extremely slowly.

This does not prove that a computation cannot be conscious. But if the same transition from prompt to next token can be decomposed into an explicit sequence of arithmetic operations, then the burden is on the defender to explain: Where, in this process, consciousness is supposed to enter?

Mind that the Chinese Room experiment is comparing the mind of a Chinese speaker to a different mechanistic symbolic procedure. I am, however, executing the exact same mechanistic process, whether it is done on a GPU or with pen and paper.

My hope is that some magical consciousness process emerging from electricity circulation or whatever people believe the mechanism of consciousness would be in the case of LLMs obviously becomes implausible, unless you hold a particularly strong form of substrate-independence, stronger than what most substrate-independence supporters would need to accept.