Forem: Miko

I read: The Shortest, Strangest Engineering Interview I've Ever Done

Miko — Mon, 28 Oct 2024 00:21:07 +0000

This post was originally written for my blog at miko.ademagic.com/blog/i-read-the-strangest-interview

I read The Shortest, Strangest Engineering Interview I've Ever Done, a blogpost by Daniel Brain a.k.a. @bluepnume – what I would have called "The most productive interview" he'd ever done.

I thought it was so good that I had to write to him to tell him, something I typically don't do. He had me hooked through the entire read, and I left it feeling satisfied for both parties involved, even though it seems the writer didn't. I also felt compelled to write my thoughts down for the blog, something I am hoping to do more of.

tl;dr

Daniel puts out a job, uses reasonable hiring practices that have worked for him for years.
A funny response hooks him, and the Candidate actually looks really good. Gets an interview.
Chat starts off well. Candidate asks some clarifying questions and doesn't like the answers. Interview is cut short, despite Dan trying to save it.
Further exchanges occur, but they're all strangely hostile.

I think 2 bullets were dodged here.

Bullet 1: A short interview is a good interview.

At the beginning of interviews, I like to tell candidates something like "I blocked out (an hour) of your time to be safe, but it should only take about (45 minutes), maybe even less if we get to the answers we're after". Sometimes, interviews can feel like a dragged out interrogation where someone tries to poke holes in your experience and intelligence until one of you breaks.

I like to run interviews as two-way, and both parties should know where they sit as the conversation unfolds. My goal is to get to answers as quickly as possible for both of us. If I need more info, I'll dig further. If you don't have it, I want you to feel comfortable enough to tell me.

This can be challenging as the power dynamic is usually in favour of the Interviewer, especially with all the redundancies in the tech sector over the past few years. But in Dan's case, it didn't seem to be an issue for the Candidate. As Dan points out, they could have been burned by long interview processes where it was the case, or they could just not be desperate for this job.

In any case, the Candidate did an awesome thing. They asked about the process, determined it did not suit them, and declined further consideration for the role. Everyone saves time and energy. Dan did what any professional in the situation would do by trying to find a compromise, but the Candidate already had their mind made up.

They saved themselves a lot of effort for a role that they felt they would end up not aligning with. They could have stopped at any other point along the hiring process, but they made a key assessment at the beginning and decided progressing was not worth it. Beautiful. Everyone should feel good about this. Everyone dodges a bullet.

It should have ended here. But then...

Bullet 2: Avoid brilliant jerks.

For some reason, the Candidate decides to respond soon after to confirm the end of the exchange. They do so unprofessionally and sometimes even offensively, personally targeting Dan with insults.

I don't know what the motivation is for this kind of response. Based on what Dan wrote, it felt so clean-cut – even if they didn't, everyone should have felt closure. A confirmation is a nice paper trail, but further interaction, especially not constructive, is totally unnecessary.

As a hiring manager, I'd be thankful this person didn't continue with the process. If they managed to land the role on technical ability alone, they would be difficult to keep happy, and even more difficult if unhappy. This kind of attitude would no doubt bring down the rest of the team, compounding the issue. But I bet it'd be tiring for the candidate, too.

So, another bullet dodged.

What should have gone differently?

As the Hiring Mananger, in this case Dan, I would have been satisfied with the end of the phonecall as the end of the conversation. Its obvious the candidate did not want to progress, and it sounds like Dan agreed. But then the next email came, and Dan took the bait. Its a waste of energy, and it should just have been "thankyou, next". I'm glad this blogpost came out of it though.

I would also take away from this that candidates (at least one) find it valuable to know what the interview process is. I typically outline the interview structure before the first interaction, and will also ask for it if I'm the candidate. Recruiters will usually ask for this, too. If you've considered the structure of your interview process, and you can justify the value, then why not share it in advance?

As the Candidate, I would not have written the follow up email if I couldn't do it in a professional manner. They obviously felt a need to respond in such a way, almost like they were on the defense. Or on a power-trip?
Maybe the conversation felt different to the discussion Dan describes, but regardless, the relationship ended with the phonecall. There was no need to burn a bridge, despite the short-term satisfaction it may have brought.

Finally...

Dan ends the post with a question. "What the fuck did I do?". The answer: spent far more energy on this than he should have. Hope he got a good hire in the end, and if you do read this, thanks again for the lesson :)

Now now now, now.

Miko — Mon, 08 Jul 2024 05:16:34 +0000

This post was originally written for my website at miko.ademagic.com/blog/now

I've been interested in the Indie Web as a new (old?) way to connect with a community on the Internet without an algorith holding my hand (amongst other reasons, but that's for another post). One of the things I found a lot of people setting up was a Now Page. I liked the idea, so I made my own a while back. If you have a personal website, I think you should too.

A what now?

Yes. It's a page you put on your site with short-form, frequent(ish) updates similar to what you'd put on a post microblog. Read the about page, it explains it a lot better than I could.

You let Derek Sivers know you have one, and he puts it into a directory, and people find you (or you find people). No recommendations, no promoted listings, no ranking, no preference or order – all just based on location and a bit of random ordering. It's beautiful.

Why's that good?

Total creative freedom over what you want to build. No standards or structure to feed an algorithm. Share as much (or as little) as you want. Have it indexed, it's up to you. Then find like-minded people, see what they're doing, and learn from them. Or, don't make one and just browse! Pure old school Internet.

Since creating mine, I've already connected with others who have one. I've even made improvements to it and got inspiration for more.

I've had to make changes to my Now page a few times before, or have had questions about it, and all I've had to do is email Derek. He's responded like he was sitting next to me and I tapped him on the shoulder. Quick, straightforward, personable, and even constructive. This doesn't feel like it's a labor of love for him (though it might be, sorry Derek) – it all just seems natural. No revenue, no passion or ego behind this... he just seems to do this because this is what should be done.

But also, when's the last time you felt that the results you got from a search were totally unbiased? Not dependent on outside factors, like what's selling well, who's paying for engagement, or what people like you have viewed before? At the very least, there is a refreshing purity to this network that I haven't seen in a while and I want to get behind it.

But most of all, it's just fun. Get a now page, and let me know you have one!

Dungeon Mode

Miko — Mon, 04 Mar 2024 04:00:29 +0000

This blogpost was originally posted on my personal site at https://miko.ademagic.com/blog/dungeon-mode/

Hollywood loves to push the cliché. If you're any kind of developer, you've probably spent some time sharpening your coding blades in your Mum's basement illuminated only by RGBs, surrounded by screens dripping matrix-esque code, furiously typing away on a clicky keyboard pumping techno/drum&bass. Hell, you're probably hacking some sort of mainframe right now.

It's tired, and we all know it's incredibly wrong. But what if there's something to it?

What are you on about?

I was reading a post on dev.to about procrastination and productivity. It got me thinking about my own methods of trying to stay productive and focused, which also made me think about all the various tools and methodologies people adopt to do the same. I'm a big fan of simplicity, and reflected on my own simple toolkit - paper, pen, a stopwatch and a simple (and very flexible) methodology. There's only one thing I've ever done to abstract my process, and it's made it strangely more effective. And I did it by accident.

Dungeon Mode

Around Covid I resigned from my people-focused role at a mid/large team and joined a startup to become an IC. This required me to be "100% on the tools", which I welcomed. I strapped in for long days and nights of learning, coding, and intense focus. I took advantage of the lockdown, retreated to my study, and got to work.

I like to work with music on, and discovering ChilledCow's Lofi Girl radio was an excellent source of non-invasive "ambient music" that I could listen to for hours. I found the almost whitenoise-like record-player crackling of LoFi music was more pleasant than active noise cancelling on my headphones.

I also had some health issues, and would frequently experience migraines that brought on photosensitivity. It wasn't enough to use Dark Mode on my OS, or turn down my screen brightness. I had a warm grey wall in front of me which would reflect the lights overhead, straining my eyes. I found it best to dull the monitors, and then turn off all the lights to work. To make sure I didn't have to adjust too much, I had some warm white LEDs under my desk as ambient lighting.

Winter in a poorly insulated apartment also meant it was usually cold and I was quite rugged up, often wearing a hoodie. Wearing the hood over my head not only kept me warm, but felt like a set of comfortable blinders that further blocked any light in my periphery from annoying my eyes.

After a while I found myself employing all of the above as soon as I got to my study. I'm not sure whether this came first, or if it was overhearing my partner speaking on the phone to our family and friends and telling them that I was off in my "Dungeon", but my new habit soon got its name. Dungeon mode.

A Productivity Hack, Though?

I would start telling my partner I'm off to "Dungeon Mode". She knew that meant that I had headphones on and likely couldn't hear her talking to me, and that I was trying to focus and would try not to leave the room for a while. It worked really well. Less stimuli meant I wasn't checking my phone, losing my train of thought, or even looking around the room. I'd also find it easier to enter flow state, and I'd even need to be reminded to take breaks or about other tasks I have for the day.

It's definitely not maintainable for long periods of time. It's probably not great for your health, likely not ergonomic, doesn't look good on zoom calls – generally, it may not even be good for any other role. So does the trope have it right, then?

If your job is to look at screen all day and translate complex and convoluted logic into scripts only your computer has to understand, is this sort of sensory deprivation something that will magically help you stay focused for long periods of time? Or will it work for other jobs, too? Or am I just an outlier who became motivated, feeling like some hacker from a movie he enjoyed?

The Sequel

Today, my study is an open nook of my living room. It's sunny and lit, it has a lot of plants around, a window I can open to let the breeze in, and no way to close myself off from the world. When she's home, my 2yo will run over periodically and demand my attention with great urgency. It generally feels like a healthier work environment. But I look back on Dungeon Mode fondly, and sometimes wonder if needed, could I replicate it?

Do you work like this? Does it sound like it would help you be better? If any of this experience resonates with you, or even if you disagree, I'd love to know. I'm borderline embarrassed about it, but I can't be the only one who has connected to the stereotype like this. Tell me your story.

On Daily.Dev

Miko — Thu, 01 Feb 2024 03:52:05 +0000

This post was originally written for my personal website at miko.ademagic.com/blog/on-daily-dev

Where Developers Suffer Together

Part of the challenge of being a web developer (and my job as a manager) is to find ways to keep up to date with this ever-moving industry, its standards, and the available tools. I'm always on the lookout for good methods to do that.

Recently I came across daily.dev, a slick looking app that promises to help you stay in the loop, as the place "Where developers suffer together". So I signed up and invited my team as well.

What is it

In short, it's a personalised news feed geared towards tech and the web in particular. It takes news from the RSS feeds of various well-known publications or developer blogging platforms, and presents them to you according to the topics you've said you're interested in.

Sure, personalised news feeds are nothing new and if you have an RSS feed you've probably got some sort of reader/aggregator doing what you like. Daily.dev sets themselves apart (in my opinion) by sprinkling in a bit of gamification for habit forming, and social features so you can learn with friends.

Their main feature seems to be a browser extension, but I've been getting by fine with the web app alone. I will try the extension soon.

What I like about it

Dev Cards

I'm a big fan of gamification in UX, especially the "achievement" mechanics that games have popularised. Dev.to got me to sign up with badges, and so naturally I signed up as soon as I discovered the Weekly Goal Badge. It was a great hook to bring me back almost daily, and I'm bummed I've been de-ranked and I'll definitely be reading more this week.

You can flex your weekly goal badge with your Dev Card, which is a slick looking, license-like ID card they generate for you.

They even have a series of instructions on how to embed it, and even how to add it to your Github Profile and keep it up to date with a Github Action. Such a well-executed feature, looking forward to what else they'll do with it.

Squads

You can invite your friends and create a "Squad" together, which gives you a common board where you can write posts and share links of things you read. Its a great way to give each other reading lists and share resources about a topic common to you, or a challenge you're facing together. You also get to find out about things that interest your squad mates which is a great way to foster diversity of thought.

I created a squad for my workmates just to try it out. So far they aren't as hooked as I am but we've shared and spoken about a couple articles. Usually this would be something that happens over slack or another platform, but having this presents it in a much more consumable way.

TLDRs

It's actually strange how useful I find this but how little I use it. I'm not used to articles being effectively summarised for me, but interacting with something in your reading list provides a small synopsis to help you decide whether you'd like to read further. I'm so not used to it that I forget it exists.

It really helps with clickbaity content, or sensationalist youtube videos with misleading titles. Sure I gotta click the card to read the TLDR, but at least that's where I stop.

I'm skeptical of products like these content feed providers since I always suspect some kind of prioritisation/favoritism. This synopsis feature (which could also be biased i suppose) helps by offering transparency before you "convert". I think it's great.

What I don't like

There's not much, but here's a summary.

The Feed duplicates, sometimes showing me the same card I saw earlier in my scroll. I suspect this is to make it seem like an endless feed, but I've observed it happening a bit too early. Granted it may be due to the amount of topics I've selected, but I would have appreciated a "You've seen all the new stuff! Browse more topics or See results again" interface at the end of my feed moreso than an infinite scroll.
Sometimes my dev card is wrong, or at least it is right now. I've only ever seen one youtube video of t3.gg in my feed (and am fairly certain I have downvoted), but somehow it's wound up in my favourites on my dev card. Which not only makes me question the algo, but also raises the question of how this made it into the feed anyway? Where do you draw the line between a personal blog and an influencer/creator's youtube channel being a "well known publication"? Follower count? I digress...
Ads are not obvious enough. Sure they're not the guiltiest, and you gotta make money somehow. Daily.dev has just done a few things that have impressed me, so putting an ad into a feed that looks close to a regular article gets me a little peeved. I would have liked if the card received a different colour treatment so I can ignore that design; the variation they have is just different enough to stay similar.

How it's going

It's been about 2 weeks since we joined Daily.dev as a squad. I'm the one mostly using this but have heard positive feedback from other team members, despite their read counts not being as active as mine :) We'll persist with using it since it's not a demanding part of our daily flow, and I'm interested to review this in about a month or two. But so far it's been a positive experience and I'm interested to see how this app grows.

Migrating to Astro's Collections

Miko — Mon, 29 Jan 2024 23:46:41 +0000

This post was originally written on my personal website at miko.ademagic.com

I’m trying very hard to keep up with Astro’s upgrades, but they move through majors faster than any platform I’ve used before. One of the new features they introduced as part of v3 was Content Collections. This blogpost outlines my experience of migrating.

Why upgrade

I have worked in web long enough to understand the potential pain of falling behind in dependency upgrades. As much as possible, I try to stay up to date with every project I work on but with personal projects in particular.

Astro’s active development is something I really enjoy about the platform. The new Content Collections took some time for me to wrap my head around because I prefer the simplicity of Astro’s old file structure and organisation, and it was one of the original reasons why I chose to build my website with Astro. Engaging with the community and Astro’s documentation helped me understand the power and flexibility that comes with collections, and while it unlocks a lot of complexity, it can also be adaptive and kept simple.

I currently have two types of content - blogs and releases. I could technically store any kind of data, though. Authors, favourite songs, short posts etc. Each of these can have a defined type, and I can make sure I can define them correctly and predictably. And then display them in any way I want.

My plan

Migrating seemed like a lot of work due to the move from a simple file structure to JSON and typedefs. I felt I couldn’t dedicate the time required to do this all at once, and was worried that I’d never get to it if I had to leave it unfinished.

I planned to migrate my Releases first. The content was predictable and simple, there wasn’t a lot of it, and I didn’t really care if it broke. I’d create a type definition for it and move my content to the new directory and file structure, then ship. Once I’d tested and confirmed all ok, I’d move on to blogposts.

What actually happened

Creating a content collection seemed to immediately switch Astro to using its new API. Not only did all my pages using the old structure fail to build, but any reference to Astro.glob now became invalid and content had to be retrieved from the new getCollections() function.

It meant I had to go through and reactively bugfix rather than proactively make changes to my site as per my plan. In the end, this did not take as much time as I expected and I managed to resolve all errors across a couple of sessions. Astro’s error messaging, and the Astro Language Support Extension for VSCode was very helpful in telling me what to fix next.

How it’s going

This will be my first post since the migration, and nothing seems to have gone wrong. My old pages and links all work, as do my redirects that handle previous iterations of my site. Sound the “Everything’s OK” alarm 🚨

I am not using typedefs at the moment, and my implementation of content collections is the simplest it can be. But I look forward to flexing this function a little more as I add to my site this year.

But first, Astro v4.

Why are styles on my Astro site not working in GitHub Pages?

Miko — Tue, 31 Oct 2023 23:25:14 +0000

I've been hosting my website with GitHub Pages in its last three iterations, and have most recently rewritten it in Astro. When I uploaded my first static build to my repo, I noticed that the rendered output was not the same as on my local even though all the files were identical. Something was off, and my suspicion was that it was GitHub's doing. I fixed it in Release 6.

TL;DR

Astro generates static files which start with underscores
GitHub Pages is preconfigured to use Jekyll as a static site generator.
Jekyll considers filenames starting with underscores to be special resources and ignores them. This means they will not be served by your site.
To fix this, bypass Jekyll by adding a file named .nojekyll to the root of the repository for your site.

Source: GitHub Blog - Bypassing Jekyll on GitHub Pages

My issue

I pushed the first production ready build of my site to my GitHub pages repo with excitement. It was a simple copy-over from the dist folder to the root of my repository. Once GitHub pages deployed my site, I noticed that my blog article title was far too wide, and my Bio component in the footer had my headshot too large and the typography sizing was wrong; in other words, both components were unstyled.

I dug deeper and discovered that the styles for these components lived in the blogpost's template, named [slug].md. When Astro built the static files for the site it put these styles into a file named _slug_.a3a4f792.css, which was then loaded on each of the blog pages.

When I served the site locally, these files were loading fine. But, when I deployed my site, looking for the URL of the CSS files returned my 404 page. Other CSS files would load fine, and I could see their raw contents in the browser. But it looks like this one wasn't being served at all. Hence, unstyled components.

The Details

Astro's Dynamic Route Parameters

Astro lets you dynamically generate multiple pages by letting you specify dynamic route parameters in your filenames. You can do this by creating a template with square brackets in the name, like [dog].astro. You then tell Astro all the paths it should generate with this template by exporting a function called getStaticPaths() from it, and having the function return an array of objects which tells Astro the possible values for the [dog] parameter.

---
export function getStaticPaths() {
  return [
    {params: {dog: 'clifford'}},
    {params: {dog: 'rover'}},
    {params: {dog: 'spot'}},
  ];
}

More information in Astro's docs on dynamic routes.

If there are any extra styles in these templates, Astro will pull them out and scope them with hashed classes, and will generate a CSS file based on the template's original filename, but with the square brackets replaced by underscores. In the above example, this would look something like _dog_.b8f7f6g5.css. This file would then get loaded by each instance of the generated template.

Jekyll's configuration

Jekyll has been used by GitHub to serve static pages for some time now. The format for its configuration files start with underscores (e.g. _config.yml). There's not much point to serving these from your static site, so Jekyll ignores them by default. Ipso facto, this means that Jekyll won't serve the CSS files Astro generates for templates with dynamic paths. So all of those generated static pages will reference a file that isn't being hosted.

There are a bunch of ways of telling Jekyll not to do that, but in this context we don't need Jekyll at all so there's no need to maintain a configuration. Instead we can easily tell GitHub Pages that we aren't using Jekyll by adding a file to the repo's root called .nojekyll, and the static files will get hosted as-is. GitHub Pages does the rest.

This was originally posted on my personal website at miko.ademagic.com/blog/astro-styles-on-github-pages/

I block bots.

Miko — Wed, 13 Sep 2023 01:15:52 +0000

A couple months ago, I posted probably my second-most-popular social post ever, and it was reposting what I found was an insightful blogpost by Jeremy Keith. The message was simple, but hit me deep.

"We can rescind our invitation to Google."

-- Jeremy Keith

Part of every website go-live checklist I ever completed included integrating Google Analytics, or at the very least somehow ensuring that the site was being crawled as expected. I never actually questioned it.

When I started building this site, I also looked at moving my analytics interface elsewhere. Getting another website to collect, host and display my data felt less unsavoury than Google doing it, especially because I figured Google did other things with it, in ways and at a scale that no other website could. The more I thought about it, the more intrusive it felt.

Why

I never actually considered saying "actually don't crawl me ever" until I read Jeremy's post. I don't actually need to result on Google for my personal site at all.

I'm not monetising it or selling any ad space
I don't directly benefit from increased traffic
I don't want to compete for high positions in results lists with paid professionals who benefit from 1. and 2.
I don't care to teach Google stuff

Upon further consideration I decided I'd rather

Get organic traffic from sources and circles I'm actively involved in (and post to)
Leverage the SEO Pros of platforms that are incentivised to help me show up in search results
Be selective (or at least have control of) the content I share to 1. and 2.

And so, I block bots.

How

my commit for blocking Google's bots, apparently.
And in case it's changed, my robots.txt.

As many people have pointed out, Google could just as easily ignore this, there are probably more thorough ways to do this, and even (slightly) malicious ways to protest. I haven't gotten that far and am content with this for now. If you've got any other things I should be adding to my robots file, please reach out.

This was originally posted on my personal website at miko.ademagic.com/blog/i-block-bots