HN user

christophergs

288 karma
Posts7
Comments60
View on HN

Pydantic | Solutions Engineer | REMOTE (UTC-8 - UTC+1)| Full-Time | https://pydantic.dev

If you write Python, you've probably heard of Pydantic (400m downloads per month) and if you do AI engineering you've probably heard of Pydantic AI (one of the fastest growing agent frameworks). We are also building Logfire - our commercial observability platform, and we are hiring our first Solutions Engineer to take ownership of our post-sales success.

See the full description here: https://pydantic.dev/jobs/solutions-engineer

Yes. When I was very inexperienced I still remember being interviewed by an extremely big dog in the open-source world (he was VP of engineering at a very successful startup). I was probably about a 3/10 in terms of quality of interview answers, and unsurprisingly didn't get the job.

Despite that, he still managed to make me feel good about the whole experience. At some points in the interview where I was close/slightly off he'd first coax "that's quite similar to X or Y, don't you think?" then if that didn't work he'd coach "here's how X works, elegant explanation, ok, let's talk about Y".

I remember this vividly years later with a smile. Just like I remember all the negative experiences where people were dismissive or ghosted.

I agree that ending an interview early is a no-go. However if it's an onsite/process with multiple interviews, I think the fairest approach (and I've done this in the past) is to manage expectations ahead of time that the full interview sequence only happens if you pass each one.

This way you don't waste the candidate or your time if it's clearly a no after interview 1. They feel a bit bad because they obviously didn't pass, but if you've communicated ahead of time it's not a rug-pull.

Timing matters. The latest generation of VR headsets are incredible. I feel like this point matters, the same way that Netflix needing broadband to be fast enough to stream video mattered.

Great post. A key point you don't bring up is the aftermath, even if you do deliver. Especially in non-tech companies there still remains the tendency to view these projects as "done" after the end of the project/MVP etc., with no understanding that sites need ongoing maintenance and improvements. And that this work is still considerable.

You can build your own site like this with CourseMaker[1] (disclaimer: I'm the founder). We don't have SQL support yet, but you can create interactive exercises with JS, Python, Go, Rust, C# and Java.

I learned to code through these kinds of sites (codeacademy and code school especially), I think being able to tinker in the browser with no setup is great.

[1] https://coursemaker.org

Could you elaborate on what living non-traditionally looked like for you? What was your thought process going off script, and what made you decide to change course back to a regular job?

Shades of PG's "Why Nerds are Unpopular" [1]

"As far as I can tell, the concept of the hormone-crazed teenager is coeval with suburbia. I don't think this is a coincidence. I think teenagers are driven crazy by the life they're made to lead. Teenage apprentices in the Renaissance were working dogs. Teenagers now are neurotic lapdogs. Their craziness is the craziness of the idle everywhere."

[1] http://www.paulgraham.com/nerds.html

A lot of busy, smart people have seemingly random side-projects. For example, Von Neumann:

"A professor of Byzantine history at Princeton once said that von Neumann had greater expertise in Byzantine history than he did" [1]

I don't know for sure why, but I think two possibilities are likely: (1) An extremely strong, natural intellectual curiosity and/or (2) Working on other things allows them to bring fresh ideas/insights to their "main" work, and in this sense is also rejuvenating.

[1] https://en.m.wikipedia.org/wiki/John_von_Neumann

At my last gig I got budget to bring in the maintainer of an open-source testing library we using for some really important stuff.

We paid him $1500 for a couple of days consulting. He showed us how to fix a couple of tricky bugs and gave a talk to the eng team. At this point we've more than recouped the investment.

He was psyched to see his tool being used and I feel the visit contributed to him continuing to maintain the project.

After those two days we also tried to hire him (he declined because he was making bank elsewhere). But those two days were also the best interview process ever because we did hours of pairing in non-interview mode.

If you're a senior dev at a tech company with money you can easily make this kind of thing happen and it's such a win-win

Same, sometimes people volunteer to help me code https://coursemaker.org for free because they like the idea. In one case this has worked out well. But in a couple of others the engineers have vanished quite fast. Sometimes I wonder if I made a much more serious effort to onboard/document/give ownership then would they stick with it. What do you reckon - how was the onboarding in your case?