biggestriverman

K2 horizon is the closest to actually releasing everything that I am aware of https://ifm.ai/blog/k2/

The way you describe your ideal interview is how I conducted leet code style interviews. Ask a problem with a simple algorithm and then ask extensions until the time ran out. This worked pretty well.

For interviews where candidates are using AI I think you can supercharge this approach, but I do not think there is value in turning it into a code navigation puzzle as there is little value in that can be evaluated in the ~45 min you have for coding in a 1 hr interview slot. Ultimately in many software engineering jobs these days we need to understand how to build quality systems without looking into the underlying system except as necessary. I am not sure how to best evaluate this judgement in an AI assisted interview

I used to use this approach as well for managing many agents and myself. I do think the bloat problem is real as well as the need to handle multiple disjoint workstreams.

My solution was to put tasks and their dependencies in a sqlite db. https://github.com/mhalstrom/maximizepm take a look if you're interested

You have to design your process for writing code to handle more code than you could ever read. To do this you also have to accept that you will not be able to hand manage all of your agents and all of your projects. The key thing is to figure out how to manage your time better and spend your efforts unblocking your agents.

What I did was build my own process for this: https://github.com/mhalstrom/maximizepm

The main take away is: 1. You need an agent to manage your agents that you mainly interact with. 2. You need a durable way to manage tasks and the dependencies between them. 3. You need agents with multiple roles ie manage, build, review etc 4. You need to manage yourself across projects so any system you build needs to take that into account

HOA's are necessary when you have shared resources or have physical connections between units. Sure they make little sense if they exist just to control what color you paint your house but having a agreed upon method to have discussions/ manage resources is important.

Its funny the worst code I used to notice was my old code that solved the problem I had faced at the time but had some flaw in the thought process that I later corrected. The same thing applies to generated code. Yes there is a lot of garbage but you can figure out ways to generate better output as you learn the tools and the models get better

We live in the real world so individual principles don't make as much of a difference to your community as leaving a decent tip.

Then consider on top that the perceived time needed for implementation has dropped so additional work that would have never been taken up in the past gets added.

Actually learn to code instead of just prompt. Get any internship you can as early in your college years so you can understand if you like working in the industry before getting to far along. Once you have an internship take it seriously. Just because the company or team you are on is terrible its much better to be in a position to get a return offer instead of being desperate to find a job upon graduation.

Interns that I have seen be successful at Amazon do the following:

1. Show interest in the process.

2. Work really hard to unblock yourself. (You should feel like you're stuck a lot of the time. If you're not the project is too easy)

3. Learn when to get help to unblock yourself.

4. DO NOT tell anyone on the team or adjacent to the team you are on that you are not interested/ would not accept a return offer. This will guarantee no offer. Our best intern did this. (If you are skilled everything will turn our fine but it is nice to have options)

It all depends on how hands on you are willing to be.

If you are using the model to write to code faster with extensive human oversight you can develop a lot faster using the non-frontier models. I was doing that extensively last summer.

But now my thought process is I want to focus on architecture and product direction. I have not seen Sonnet level models be capable of performing autonomously enough to take a feature end to end reliably enough to be completely hands off. In fact there a many cases where Opus will fail as well where Fable will succeed.

Of course that is not to say that Fable will always do things correctly. It will happily take an under-specified problem statement and happily use up all of your usage to build the wrong thing, while Opus at least recently stops constantly to check in.

I built a workflow execution engine that dispatches to my tool service. I had previously looked into using Temporal but at the time decided to focus on what differentiated the idea. Maybe in the future execution durability will be important enough to make using Temporal the right solution however as of now I am focused on explore the problem space using chat -> convert the good parts to a repeatable process -> trigger appropriately.

When I was working at amazon (left May 8) working on agents was all the rage. Combined with initiatives that set goals for nearly all services to have a MCP built and available by the end of the year agents will be even more emphasized in the future.

However what happens when you actually build and launch your agent is customers try it, do some initial runs and then go ask your manager to automate their use case. That is why I have been building https://toolscaled.com/ The goal being work through your problem space using agentic chat (like Claude Desktop) and then at the end convert it to a workflow. I am pretty close to launching and have been testing. If you're interested send me an email! (if you do sign up just fyi its still in beta so YMMV.

I would've commented earlier but couldn't get the link to load

my team at amazon has an intern starting may 1st