Standup
On day 5, I set up Tailwind properly with an npm/Vite based build system, integrated the Stripe checkout UX, provisioned 2 DigitalOcean droplets with minimal specs and set up Github workflows for each marketing site to do a dead simple git pull + sighup deployment process on merges to staging in each repository. The final sighup is killing the servers and requiring me to manually restart each Python server - I'll need to look into that when it starts to affect my velocity. Right now it’s not worth digging into.
I also started to flesh out the marketing content on the product marketing page. This required product screens, and after a brief and frustrating attempt to get Dall-E to create a mockup (which it refused to do on policy grounds), I decided to create product screenshots from just enough mocked up UX.
Although at the start of this project I claimed I wouldn’t work weekends, I spent some time on the weekend trying to push this forward, and some more time into the following Monday to get it to this state. That annoying pang of anxiety showed up on Friday evening to tell me that I was starting to fall behind significantly.
I should have spent Monday looking for discussion places and today should be writing marketing material. However, as I write material I’m finding that not being able to just snap a screenshot or a quick Loom of functionality is seriously interrupting my flow. Furthermore, I’m not good enough at graphic design or using any modern design tools to try to mock things up directly for myself.
Naturally I tried AI. I mean, I’m trying to start and run a company by myself with just the assistance of AI technology so of course I should try to solve this problem using AI. Unfortunately, various corporate friendly policies these AI providers put in front of their models means that the models refused to generate my requested mock up due to the “video chat” feature and requesting a realistic face. As it turns out, realistic depictions of video conferencing are specifically called out to ChatGPT as morally questionable and it’s told to refuse it1.
I’m not enjoying this. I’m not enjoying being dumped out of the flow of writing by needing to figure out how to mock up some part of my app that doesn’t exist. This is an intense project over a relatively short time, and I’m not even being paid for it - if I’m going to do it, I damn well better be having fun.
To that end, I’m rearranging tasks a little, doing half of the MVP work upfront for screenshots and then will deploy marketing sites and write content. As I finish the app prototype, I’ll drip out some content marketing posts that I’ve already written. This keeps the same general timeline with the same limits on work, but re-arranging some work.
Before committing to this decision though, it’s worth really taking a close look at the motivation. Am I trying to avoid uncomfortable work and just fall back into building, which is my comfort zone? What would my situation look like if I were to keep to the original plan and fight through “not having fun”?
I honestly believe that fighting with design tools and with AI to convince it to output the quality of graphics that I have in my head is not going to be productive. I can feel the slow down each time it happens which is part of what’s contributing to the process not being fun. The other part is the frustration of not feeling skilled enough in any of the tools available to me to mock things up, including prompting image generation language models, and getting sub-par output as a result.
I also don’t have the time to skill up in those tools. I basically need to be operating in a space of pure productivity. Mistakes are OK as long as they keep momentum up and keep me moving forward. Generating sample screenshots that I’m not happy with is not moving me forward in anyway.
The worst case is that I fall into a rabbit hole of building and at some point realize I’ve strayed and course correct. At least if that happens, I’d have made progress on the MVP itself. If I spent that time instead creating mock ups and fake imagery, I might have output that I’m happy with and grow my LLM prompting skills - but none of that materially moves this whole thing forward.
This decision makes sense for me. I am most productive in code. I know product managers and UX designers who feel more comfortable in Figma. For those people, creating mock ups and faking the app will be faster than building it. For me, it’s a tarpit best left avoided - I’m faster at actually building, and I’m already $300 deep in code-based design tooling. May as well keep at it.
Yesterday had my intro call with InsuranceCo that I booked last week. I feel the screen went well - there seems to be a good alignment on my skills and what they’re looking for. On our call, the recruiter outlined the interview process and told me what I could expect, which I really appreciated.
I explained my real-estate and housing situation to him, and he said they’d be able to make it work. I have a take home coding assessment that I need to complete for evaluation by the team, then if I didn’t screw it up, I’ll have a follow up review then more interviews. We booked one of the follow-ups on the spot, so there’s a time limit on how long I have to complete this take home.
I have another intro call today with AICo that I will need to work around. I need to actually schedule time in for the take home assessment to ensure that I do it, and that I take it seriously enough.
Take Home Assessments
Ah, the take home assessment.
Or, “hey computer guy, show us you’re actually good at computer stuff and that you didn’t just fake your entire 20 year career.”
My relationship with the take home assessment has been a tumultuous one. I first encountered them when job seeking in the US for the second time back in 2016. Until then, my experience with proving my skills in interviewing was in person coding on a whiteboard.
I remember when interviewing for my first US job sitting at the CTO’s desk in his office, scribbling a substring search algorithm in pseudo-Ruby in pen on paper while he was working in front of me. After sweating it out for 15 minutes, I told him I was done and showed him my scribbles. He took a brief look, spun his monitor around and showed me a quick 3-liner he also whipped up in actual real Ruby to do the same. Looking at my 20+ line scrawled solution on the paper in front of me, I was sure I wasn’t going to get the job. I did get the job, and in my defense, my solution was faster and more efficient.
I still have the code to my first take home test. They wanted me to write a function to query a few API endpoints and collate the results. I snooped around the API endpoints they told me about, found a single better API endpoint that returned more or less the info they wanted, and wrote a function to query that API endpoint. I didn’t get the job even though that is absolutely, 100% the right call to make when actually working in a job. I didn’t much care for take home assessment after that point, even though I preferred them to whiteboard coding.
Take home assessments have a reputation in the industry and it’s not great. Most take home assessments/whiteboard coding sessions are seen by programmers as an annoying, pedantic obstacle to overcome. The nice thing about programming is you either know what you’re doing or you don’t2 and the thing either works or it doesn’t. If I’ve been working as a programmer for 20 years, it stands to reason that my stuff must work and I must, to some extent, know what I’m doing.
Yet, continuously, we have to prove that this is the case. And not on actual real problems that the company is facing for money (like a job) - either on pale facsimiles of the kinds of problems they face, or worse yet, completely arbitrary “leet-code” problems that only demonstrate you remember college, all for free. Whether we write the solutions in real-time in front of the interviewer, or we do it at home from the comfort of our own text editors, we’re usually writing the kinds of code we’d never write on the job to prove that we can do the job.
You don’t have to do that, you know? I mean, you can straight up refuse to work for free on a junk problem just to prove yourself.
Of course, it’s easier in a good economy where the employees have more mobility than the employers have leverage. In that kind of employment environment, you can just say no and that’s it.
I interviewed with one company who, at the time of the event in question, was already 3 interviews deep with me. I’d done the whiteboard coding in person and chatted with my potential team. Recruiting wanted me to have another interview with an offshore team member. That team member ended up no-showing to our scheduled interview. When the recruiter tried to reschedule the interview, out of frustration, I told them that I wasn’t doing anymore interviews, and that they ought to have enough information by now to make a hiring decision. I was hired.
That’s not to say it’s impossible in a bad economy, you just can’t outright refuse - you need to offer alternatives. I spend a lot of my free time coding. Not just because I’m trying to create and put out a product of my own, but just for fun sometimes. I like automating things, I enjoy writing tooling to make my own personal life easier. I have a lot of code I can show people in a lot of different languages.
If the goal of the take home assessment or whiteboard coding session is to:
evaluate if you can at least pass “fizz buzz”3
explore your thinking process and problem solving process
simulate working alongside you without committing to actually doing it
to some extent, see how you operate under pressure
It then seems reasonable to me that showing you some of the real, actual code I’ve written to solve a problem I had is just as valuable as the takehome or whiteboarding exercise. Yes, you miss the pressure of live coding, but the general move toward take home assessments has watered that pressure down somewhat, and the interview itself is stressful enough already!
I have, in the past when asked if I would do a live coding exercise for a fake problem, instead offered to show the interviewers around a project I’m currently working on, or a particularly big codebase that I have created for myself. I’ve done it live mid interview where it’s harder to refuse me in person4, and I’ve done it ahead of time and granted read access to entire Github repos to interviewers.
The thing is, I’ve never been refused.
Most interviewers don’t want to interview you. They have code they need to work on, projects to deliver, and they probably would rather be doing that than interviewing you. They don’t like talking to strangers much more than you do. They’re also not looking forward to your white-boarding session or reviewing your take home assessment. At best you’ll provide some form of answer they’ve never seen before and have an interesting conversation, at worst they get to uncomfortably watch you squirm as you try to jump through their hoop.
Reviewing code and reading code is such a large part of the real job, and something you actually do with co-workers, that interviewers tend to prefer to do that over their coding exercise. They get to see how you write actual code that gets executed, see how you structure your code and architect your applications. They get to discuss your reasoning with you with a concrete example and get a feel for how you communicate.
Obviously, it’s win-win for you too. You get to drive the technical portion of your own interview, highlighting code or application design that you’re particularly proud of. You also start to get a picture of the development culture at the company, too. What kind of questions do they ask you? What do they focus on? If the company is overly hung up on your commit messages5, maybe that’s a yellow flag? Are they interested in how you do CI/CD in your project? Maybe that means the role is very DevOps hands-on.
Now, I’ve gone to great lengths to put myself in a position where I’m able to do this. Not that I’m well known in the programming community, nor so good that I can’t be ignored. I did this by intentionally writing in open on-and-off over the last 15 years or so, by writing code and learning about technology in my free time, and by publishing any of my coding projects that transition out of active development (or continue to be actively maintained). I link to these on my career related social profiles and on my resume itself.
I go out of my way to show anyone who cares to know that I know tech - I’ve been doing deeply technical work over my entire career, and the growth in both my skills and the scope of my personal work is evident in my published work. Subconsciously, I think I’ve always been working toward avoiding the take home assessment entirely.
Ultimately, I think the take-away is to remember that interviewing is about matching skills to requirements and ensuring that the candidate can produce the quality of work a business is after for the price they’re willing to pay. All the processes of multiple interview rounds, coding assessments and reviews, architecture discussion, all of it is to work toward the above goal. Underneath all of that are people that just want to work. Anything you can do to help speed that process along is probably going to be welcomed.
When I wrote this post originally, I asked ChatGPT to generate a realistic interface for a teleconference. It refused. When I asked why, it claimed that it was a violation of it’s content policies. I queried further and it told me about the potential misuses of generating realistic imagery of people. Today, to get an example of that, I tried it and it worked. Which is both annoying and not annoying at the same time.
I’ll talk about vibe coding later
I hate that I’m old enough to have to link this
You might find being so analytical about social norms to be a bit icky, but “don’t hate the player, hate the game”
Assuming they’re more than “checkpoint”