When I had been on the other side of the process, submitting resume and cover letters felt like lobbing random stuff over a fence.
Here's a quick thread that might be helpful to people applying to jobs. 1/
There are two main things I look for on resumes: 1. evidence that someone gets stuff done and 2. the ability to communicate this to me.
More so than what companies someone has worked at, I look for bullet points and results. What did this person do and what was the impact? 2/
Here's what separates a good resume from a "pass" for me:
✔️ Clearly states roles and impact
✔️ Past experience either shows a cohesive career arc, or there's a cover letter that explains it
❌ Lots of words ("collaborated cross-functionally"), but I can't tell what got done
3/
Something I didn't realize before was how much a good cover letter can make a difference.
I don't know how much recruiters a bigger companies read these, but I read every cover letter.
Cover letters highlighting relevant experience have led me to interview people. 4/
Related, something that's surprised me is how much I check supporting materials.
If someone includes a website, GitHub, and/or talks I always dig in if they're remotely a fit. It helps!
Interviewing takes time, so spending a few minutes to save 30+ minutes is worth it. 5/
This might go against advice for anyone applying to big companies, but school, current and past companies, and current title matter a lot less to me than what a person has actually done.
We're looking for scrappy builders and that's pretty much all we care about! 6/
I'm curious to hear from other people though!! How I've ended up evaluating resumes actually departs quite a bit from how other people trained me to look at resumes.
I'm sure it would be helpful to people watching this thread to hear a diversity of opinions on this! end/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A few months ago, as users started throwing more API traffic at the Akita client, we started seeing multi-GB memory spikes. 🙀
At first, we hoped for an easy solution. There was none.
This is the story of @markgritter's 25-day journey taming memory usage in a #golang client. 1/
@markgritter The first thing @markgritter did, as you would do in most languages, was to profile the system for obvious bottlenecks.
There was one, in the #gopacket reassembly buffer. Memory was persisting even though it wasn't getting used.
Mark fixed this, but the problem persisted. 2/
@markgritter At this point, the team and I weighed possible next steps.
Since #golang is memory-managed (2x memory overhead no matter what 🙀) and does not expose much control over the garbage collector, we were worried that it was not possible to be able to get memory usage low enough. 3/
Been talking with a lot of people who are burned out at work right now. I got quite burned out at the end of college and in the middle of my PhD. Today, I work way more than I did back then and am able to feel really fulfilled. Here are some lessons that helped me get here. 🧵 1/
First and foremost, it's helpful to recognize that you're burned out. Are you feeling less creative? More irritable? Over the years, I've learned to recognize micro-burnouts (from "I need lunch" to "I need a vacation") and I like to believe that's kept me from macro-burnout. 2/
Working sustainably is key to preventing burnout. For me, i's not about limiting hours but about building in recovery. The recovery needed depends on the intensity and duration of the work. If I go for longer without recovery, the recovery will need to be longer/more involved. 3/
Every now and then, I see a thread about how functional programming languages are The Way, wondering why they aren't more popular.
A big problem is that people talk about functional programming as The Way for Everything. FP has its place. All tools have their roles. 🧵 1/
The elegance of functional programming makes it an appealing "silver bullet" candidate.
But here are the domains where FP really shines: 1. Programming education 2. Prototyping language features and analyses 3. Domains where you're mostly specifying transformations
2/
I fell in love with Scheme and SML in undergrad. I taught myself Haskell and extended it for my senior thesis. In grad school I worked in Haskell, then OCaml, then Scala.
But by the end of grad school, I was mostly using Python.
Why aren't there more startups based on programming languages and software analysis?
There's definitely a need for SOMETHING, as developers have so much pain.
I was recently on a panel where someone asked this question. I didn't have time to answer then, so here's a thread. 1/
There's often a gap between the creators of "principled" programming tools and the needs of working developers.
There are two common technical assumptions: 1) code correctness is a top priority and 2) it's possible to understand the whole system.
Often, neither hold. 2/
In programming languages and formal methods there's the dream of "soundness:" if there's a bug, the tool will find it.
People don't want to know all of their problems. They want a prioritized list of problems that matter. This technical goal is often at odds with user needs. 3/
@kaifulee Jeannette Wing, who co-developed the Liskov Substitution Principle. Leader in formal methods research. Head of @SCSatCMU 2004-2007 and 2010-2012.
My answer: figuring out how to build a team that balances user-focused product thinking with the deep technical expertise required to power it (in our case).
Thread. 🧵
@the_prion@AkitaSoftware At Akita, we're making it easier to detect the API regressions that matter. We want to do this as non-invasively as possible, with the highest information content possible.
This means keeping code changes/perf overhead as minimal as possible, while keeping false positives low.
@the_prion@AkitaSoftware Keeping code changes and perf overhead as low as possible is not easy, and constantly requires balancing software architecture decisions with user-facing tradeoffs.
Keeping false positives low is also a really hard trace analysis problem that also has many user-facing tradeoffs.