<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>mishmesh: Platform engineering</title><subtitle>Personal writing and credited experiments in cellular automata, computing, and other interests.</subtitle>
<link href="https://mishmesh.net/topics/platform-engineering/feed.xml" rel="self"/><link href="https://mishmesh.net/topics/platform-engineering/"/><id>https://mishmesh.net/topics/platform-engineering/feed.xml</id><updated>2026-11-02T00:00:00.000Z</updated>
<entry><title>Answering My Own Interview Question (role: Platform Engineer)</title><link href="https://mishmesh.net/writing/answering-my-own-interview-question/"/><id>https://mishmesh.net/writing/answering-my-own-interview-question/</id><updated>2026-11-02T00:00:00.000Z</updated><published>2026-11-02T00:00:00.000Z</published>
<author><name>Steph Prime</name></author><category term="platform-engineering" label="Platform engineering"/>
<summary>It’s only fair.</summary><content type="html">&lt;aside class=&quot;attribution&quot; aria-label=&quot;Authorship and evidence&quot;&gt;
&lt;p class=&quot;byline&quot;&gt;Written by Steph Prime&lt;/p&gt;

&lt;details class=&quot;credits&quot;&gt;&lt;summary&gt;Authorship &amp;amp; credits&lt;/summary&gt;&lt;ul class=&quot;credit-list&quot;&gt;&lt;li&gt;&lt;strong&gt;Steph Prime&lt;/strong&gt; &lt;span class=&quot;credit-kind&quot;&gt;Human contributor&lt;/span&gt;&lt;br&gt;author&lt;/li&gt;&lt;/ul&gt;&lt;/details&gt;
&lt;/aside&gt;&lt;p&gt;Interviewing candidates is tough.&lt;/p&gt;
&lt;p&gt;There&amp;#8217;s not a lot of time. You&amp;#8217;re sitting in front of a very skilled person who has already devoted hours to your org&amp;#8217;s hiring process, and now you need to make that time both informative and non-miserable. Can you do all that, and accurately begin to understand how the candidate thinks too? This is my attempt to do so.&lt;/p&gt;
&lt;p&gt;The Question:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;Imagine you have finished your most recent deliverable and now need to choose the next ticket you work on from an overflowing Kanban/JIRA/Linear board. In the absence of clear priority/urgency differences and without receiving any direction from others—which one are you pulling down, and why?&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Up front, I want to say there is no right-or-wrong answer here. There are many interesting directions that the candidate&amp;#8217;s answer might take. If you&amp;#8217;ve got your own, leave a comment.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;My answer:&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I look for the one with the most outsized effort-to-impact potential—especially ones that are low-hanging fruit. Effort is work effort (time, difficulty, &lt;em&gt;operational overhead&lt;/em&gt;). Impact is defined as either enabling users with new capabilities that enhance their ability to deliver, or alleviating pain, toil, and frustration that your users endure in the process. Both are important, though I do tend to lean pain-relief. If there are multiple promising options, I work the smallest one—the one that I can deliver in the shortest amount of time. And deliver means to the end-user.&lt;/p&gt;
&lt;p&gt;I do that for a few reasons. Knocking things out quickly is good for morale. Somebody out there was waiting for that fix. Priorities change. But primarily because: &lt;em&gt;wins have a tendency to compound, sometimes in unforeseeable ways.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Users are innovative and environments are not static. A tool may have other applications not initially considered. A user may figure out how to do something in a way that is better and faster than what you would have built. Good. They are the domain experts of their own job. I try to make things that help keep them sane while doing it.&lt;/p&gt;
</content></entry>
</feed>
