While job searching last fall I got a couple of offers in September, accepted one of them, and put in my two weeks. As my start date approached I got more hesitant about my decision. Not only did the offer letter include one of those "anything you create while working for us is owned by us" clauses, but their equipment agreement had a buyback policy that if I left within two years I would have to pay for all of it.
I pushed back multiple times to no avail and ended up starting my job search again with some baggage and no employment. Baggage in the sense that I soon had to update my resume to say that I was unemployed. Ooof
From then on I brought it up in interviews. I wasn’t bringing it up intentionally, but my default was “honesty is the best policy.” So when pressed it just came out, and I would stutter through explaining their equipment agreement and inevitably waste 50% of my first interview defending myself.
This has been really hard to learn because I have gotten this wrong for most of my life. Me feeling compelled to tell all the facts made me tend to downplay the positives for the negatives. What recruiter is going to move someone forward that just bailed on a company instead of all the other candidates that didn't? Not many. When we get consumed by every last detail we miss the point. The point was: I cared enough about the culture of where I was going to face unemployment. That is actually a positive quality, but I wasn’t communicating this because I was focusing on the details.
We all form abstractions on the road of life. When we back these with the story of how we formed them, people can more easily process, categorize, and examine for themselves whether our generalities fit their worldview.
When you tell a story, you are taking the risk that must be taken to connect with someone else. Connecting with someone is the best way to differentiate you from all the other candidates.
let's play this out. You are on the phone with your potential manager, and they mention a line in your resume that says ->
Abstraction: Testing is documenting
At this point you have two options:
1) Repeat exactly what happened: I prefer writing tests as my documentation because tests are source controlled alongside other code, and they provide a running spec.
2) Tell them the Story: My team was rewriting an app with React hooks and crunched for time. We borrowed some people from other teams, who were able to ramp up surprisingly fast. In our retro, we discovered that they were translating code based on the specs that the tests had laid out. This left no guesswork in the rewrite despite their lack of context. That's when I knew our GIVEN, WHEN, THEN standards had worked. The testing patterns I established made tests easy to read and ramping people up a smoother process.
Notice that I didn't mention that there was only 60% test coverage. I didn't mention that weird effect that I had failed to test. It's not being dishonest; it's presenting the relevant information.
People interviewing you are real humans, and it might be the case that their teams don't have 100% test coverage either. Test coverage is beside the point. The point is the impact you made and the lesson that you learned.
delivered right to your inbox