Agreed. Reading the rest of these comments are makes me feel crazy / like I’m missing something. It doesn’t sound like the interviewer was making the candidate divulge traumatic information - but rather assessing how they deal with adversity.
This is really awesome! Dream home project for me as well, but can't justify the cost of large e-ink displays so far (was shocked at the nearly ~$2k sticker price of that Boox Mira Pro!)
Great read, thanks! Could you dive a little deeper into example 2 & pre-registration? Conceptually I understand how the probability of false positives increases with the number of variants.
But how does a simple act such as "pre-registration" change anything? It's not as if observing another metric that already existed changes anything about what you experimented with.
There's no confusion about the type of edge. Just pointing out that if you are selling an edge rather than trading it yourself, you're either grifting or naive.
This doesn't make as much sense as you think it does. If you could predictably trade a flip from bearish to bullish (for example, of course there are other trend-based signals), you would not share that signal because others would overcrowd your trade (by buying/shorting and moving the price more quickly towards the trending direction than you).
A potential argument is that these signals are only applicable to a certain bracket of portfolio sizes (e.g. larger AUM funds would not be able to trade this strategy) -- but you are sharing this with folks presumably in your range of portfolio size.
You're correct about valuation, but the parent post was meant to address "how much liquid dollars should you expect to receive vs. 409a." You are likely to receive less in most cases (read: unless there are wildly successful public liquidity events) due to liquidation preferences.
Definitely agree with you that it's a problem that will be hard to generalize a solution for, and that the eventual solution is likely not embeddings (at least not alone).
Very interested to see what the next steps are to evolve the "retrieval" model - I strongly believe that this is where we'll see the next stepwise improvement in coding models.
Just thinking about how a human engineer approaches a problem. You don't just ingest entire relevant source files into your head's "context" -- well, maybe if your code is broken into very granular files, but often files contain a lot of irrelevant context.
Between architecture diagrams, class relationship diagrams, ASTs, and tracing codepaths through a codebase, there should intuitively be some model of "all relevant context needed to make a code change" - exciting that you all are searching for it.
Many SaaS products are tools. I'm sure when tractors were first invented, people felt that they didn't "control" it compared to directly holding shovels and manually doing the same work.
Not to say that LLMs are at the same reliability of tractors vs. manual labor, but just think that your classification of what's a tool vs. not isn't a fair argument.
> LLMs are a codification of internet and written content
Only true for pre-trained foundational models without any domain-specific augmentations. A good AI tool in this space would be fine-tuned or have other mechanisms that overshadow the pre-training from internet content.
This reaction is primarily an emotional one. Why is a human rejecting a claim better than an AI rejecting a claim? Presumably the AI will one day -- if not today -- be more accurate in following decisioning logic than humans, who will continue to make human errors.
Great article, really hits a little too close to home. Definitely gives me the little extra boost in the form of a reminder that acting is always better than not acting.
Could you share some specific tactics/metrics you've defined to measure things like roadmap churn or unexpected feature demands?
This problem definitely resonates with me, and I have some very primitive ideas of tracking (i.e. tagging tickets that fall into these buckets), but I would love to learn from your experience if you're willing to share!
Why do you believe that? If the goal were to measure your individual programming skills in a vacuum, then your recommendation makes sense.
However, software engineering in a larger organization has a different goal -- it's team sport of building & operating software to serve the business purposes of that organization.
With this goal in mind, one's ability to build upon & maintain an inherited codebase is definitely relevant to success.