DEV Community: Aaron Decker

Stop JSON.parse From Crashing on LLM Responses

Aaron Decker — Sun, 22 Mar 2026 15:05:35 +0000

I want to show you every way an LLM can break your JSON.parse call, and how to handle all of them in one line.

The many ways LLMs break JSON

If you're calling OpenAI, Claude, Gemini, Ollama, or any other LLM and asking for JSON, here's what you'll eventually get back:

1. Markdown code fences

The most common one. You ask for JSON, the model gives you a helpful little markdown block:

Sure! Here you go:

```
{% endraw %}
json
{"score": 95}

{% raw %}




**2. Trailing commas**

Models love trailing commas. Especially in arrays.



```json
{"items": ["a", "b", "c",], "count": 3,}

3. Unquoted keys

The model writes JavaScript instead of JSON:

{name: "Alice", age: 30, active: true}

4. Single quotes

{'name': 'Alice', 'city': 'New York'}

5. Smart quotes and em dashes

Copy-paste artifacts or just models being fancy:

{"name": "Alice", "range": "10—20"}

Those " and — characters look right but they are not ASCII and JSON.parse will reject them.

6. Inline comments

{
  "name": "Alice", // the user
  "age": 30 /* years */
}

7. JSON buried in a paragraph

Based on the analysis, the result is {"score": 87, "pass": true} for this input.

8. Invisible unicode

UTF-8 BOM (\uFEFF) at the start, zero-width spaces (\u200B) between characters. You can't see them. Your parser can.

The one-line fix

npm install ai-json-safe-parse

import { aiJsonParse } from 'ai-json-safe-parse'

const result = aiJsonParse<{ score: number }>(llmResponse)

if (result.success) {
  console.log(result.data.score)
} else {
  console.log(result.error)
}

That handles every case above. It runs a recovery pipeline — tries direct parse first, then strips markdown, normalizes unicode, does bracket matching to extract JSON from prose, and if needed fixes trailing commas, quotes, keys, and comments.

It returns a typed discriminated union. Never throws. If you want simpler APIs:

// Returns T | null
const data = aiJsonSafeParse<MyType>(llmResponse)

// Returns T or your fallback
const data = aiJsonSafeParse(llmResponse, { score: 0 })

// Throws on failure
const data = aiJsonStrictParse<MyType>(llmResponse)

Safe vs aggressive

By default it uses aggressive mode — it will actually repair broken syntax. If you only want extraction (markdown stripping, bracket matching) without modifying the JSON:

const result = aiJsonParse(text, { mode: 'safe' })

Details

Zero dependencies
~2KB gzipped
TypeScript with full generics
ESM and CommonJS
Works in Node.js, browsers, Cloudflare Workers, Deno

GitHub: a-r-d/ai-json-safe-parse
npm: ai-json-safe-parse

If you hit a format it doesn't handle, open an issue with the raw text.

vector-2-trend easily show trending topics from collections of semantic text vectors

Aaron Decker — Fri, 21 Jul 2023 15:12:35 +0000

I recently have been working on a lot of semantic search related problems at Bounty and kept coming to the same problem.

Tl;dr: the open source library is published here and on npm as "vector-2-trend".

The problem

When you collect user feedback about a product, your boss will come to you and say:

"What feature are people requesting the most?"

But, semantic search isn't truly suited for these kind of quantitative questions.

The new generative Q&A process people are doing with Pinecone + GPT will not give you this information.

So how do you take a bunch of unstructured text data and do some quantitative analysis on it in terms of commonalities and strength of those common topics?

The answer is you run clustering algorithms on the vectors (also known as unsupervised machine learning).

The process for generative Q&A

Ok hold up maybe I lost you, what am I talking about? I am taking advantage of the new openAI llms ability to make amazingly good semantic vectors so you can generate your own semantic search engines and do other things with the vectors (we are doing clustering on them).

This is the new hot thing so you have to understand why you would already be generating vectors.

The process looks like this for making semantic search:

collect text based data (in my case it's tiktok video transcripts)
convert the transcripts to vectors (I used openAI text-embedding-ada-002 API)
feed these into pinecone to create a vector db
when somebody asks a question convert it into a vector embedding using the same text-embedding-ada-002 API
search this question vector against the vector database
get back the closest results semantically (this is the key - if somebody has written "sucks" it understand that this is a complaint when you ask about complaints).
feed into GPT to summarize or analyze, or show the direct results to user

OK got it?

So the point is, if you are doing this kind of stuff you already have semantic vectors!

The solution to generate trending topics

Given that people will start asking "what are people complaining about most" you are going to need to generate an list of things.

But feeding your closest matches into GPT is not going to do this for you. How do you analyze the entire data set, or the most recent 100?

The way I dealt with this is to use clustering to create groups of similarly structured pieces of data.

It ended up working pretty well, on the dataset I used I had a group of people complaining about delivery times and I ended up with a grouping of all of those pieces of user feedback related to delivery times!

If you do this for the entire dataset and you rank the strength of the trend you get something like a trending list like this:

What are the steps

Ok I will next outline the steps I perform in the library.

Input semantic vectors w/ original text to the clustering library
run PCA on the vectors to reduce dimensionality (ada-002 outputs 1536 dimensions)
run kmeans algorithm on this (choses a sane value for number of clusters)
calculate a silhouette score for each cluster
create a "custom density" score for each cluster - which is a combo of silhouette score + number of results.
return all this data, rank by density descending
pass this to the classifier
classifier calls GPT-3.5-turbo and asks it classify each cluster with a descriptive name
output is a simple trending list like above!

Feedback & PRs

If you want to make a PR I would be happy to accept, this is something that I will continue to work on as it is powering some of our features.

If you want to just use it and play around feel free to reach out to me on twitter for questions @ardninja

You can find the project here: https://github.com/a-r-d/vector-2-trend

Reverse A Positive Integer: a visual code tutorial

Aaron Decker — Fri, 25 Nov 2022 01:33:15 +0000

There are some new tools to generate cool demos of short code snippets, one of these is wave snippets.

I put together a small demo of a very basic problem: write a function to reverse a positive integer.

Meaning take a number like 123 and make it 321. Got it?

I wrote this in typescript, and didn't handle a lot of extra stuff but it works for simple cases. Check it out:

Here is the finished code:

const reversePositiveInt = (toReverse: number):number => {
  let source = toReverse
  let accumulator = 0

  while(true) {
    if(source <= 0) {
      break
    }

    const mod = source % 10
    accumulator += mod
    source = Math.floor(source / 10)
    accumulator *= 10
  }

  return accumulator / 10
}


console.log(reversePositiveInt(12345))
// 54321

The method of doing is this is to shave off the last digit of the input number and put it at the front of a new integer one number at a time.

There is a way to do it faster, but written like this step by step I think it makes it easier to see what is going on.

5 Questions To Ask Your Recruiter Before You Send Your Resume

Aaron Decker — Wed, 04 Mar 2020 23:58:56 +0000

Not all recruiters (and recruiting agencies) are created equal.
Generally you want to work with more experienced recruiters specialized in working with technical candidates.

There are advantages to working with a recruiter. The chief one is that you can get a lot of extra information about a job before you even apply to go into an interview. You should ask specific questions to maximize this advantage.

Another thing to understand (and read between the lines on) is that you are the product when working with a recruiter and the client is actually the hiring manager at the company. The recruiter is more concerned about their relationship with the hiring manager because they are the one writing the checks.

Here are a few questions you can a recruiter before you engage with them about a job.

1. How many candidates have you placed at this employer?

This will help you understand if the recruiter / agency has had success working with this company before. If they haven't, you might want to dig into more exactly who the employer is looking for before you spend time trying to set up an interview.

Recruiters don't always understand who the employer is looking for right away and employers are often indecisive and picky.

2. When they reject people why do they reject them?

This is a good question you can ask a recruiter which can give you a huge leg up on other candidates. Often times hiring managers have pet-peeves or dealbreakers that a recruiter might know about.

Here is an example: the position is for a "fullstack developer" and the hiring manager seems to reject people that have a lot of front-end experience. Downplay that and talk about you backend experience in the interview instead.

You can tailor your resume here BEFORE you send it to the recruiter, because ultimately they will be passing it to the hiring manager, and the hiring manager decides if they want to bring you in for an interview or not.

3. What are the things the hiring manager is most looking for?

Again, this a special advantage you get from working with a recruiter. A good recruiter should really be able to dig in with a hiring manager and understand who they are looking for and will actually extend and offer to.

If the recruiter doesn't have any insight on this, see question #1. Maybe they don't know?

4. What do your other placements say about this employer?

Another special advantage you get from working with a recruiter is that they might have feedback from their previous hires.

Now, keep in mind a recruiter is ultimately trying to sell you on a job and sell you to their client (the hiring manager), so they may not be truthful with you. It's up to you to ask probing questions and read between the lines.

5. How many openings with this employer are you filling right now?

This is a good indicator of how willing a company is to extend offers.

Are they hiring for a single senior-level position? This could end up being a hard interview and even if you are a great candidate they may pass because they can afford to be picky.

On the other hand if a company is rapidly expanding and has 20 engineer opens all over the map in terms of experience then you probably have a good chance of getting hired even if you are not the strongest candidate. This is a good thing to understand before you go into an interview.

Before you go...

Why am I writing about recruiters? It's because I just launched Alcamine, a site where we give you a special email to avoid recruiter spam. We want to make job boards suck less!

Should developers even bother working with recruiters?

Aaron Decker — Sun, 08 Dec 2019 23:49:32 +0000

I hear developers complain about working with recruiters a lot.

Any post on Hacker News or r/cscareerquestions that mentions recruiters usually turns into an all out hate-fest and people start sharing horror stories about their interactions with recruiters.

I hear the term "used car salesman" thrown around a lot.

So what is the truth here?

Recruiters don't work for you, they work for the hiring manager

You need to keep this in mind in every single interaction. The person who pays the recruiter is the hiring manager.

Good recruiters do care about maintaining good relationships, finding win-win situations and helping people. But, at the end of the day many recruiters are just trying to make placements.

Ultimately you need to understand this dynamic when you enter into a relationship with a recruiter. The recruiter is going to try hard to sell you on companies.

Recruiters have warm leads. Job postings are cold leads.

You may not realize this but a lot of job postings are fake. They are there to satisfy bureaucratic requirements, or worse, just make the company look like they are growing.

Even if it is a real job, applications to job postings often go into a black hole in the ATS (application tracking system) that a company is using.

A human is likely not even looking at your application when you apply to a job online.

So when a recruiter comes to you with a job well, that is a warm lead. This means you can usually go directly into interviewing and you can skip the the application process if the hiring manager likes your resume.

This is the benefit of working with recruiters first and foremost: you skip an entire step of the process.

The wash-out rate in recruiting is extremely high

There are 3 or 4 enormous national staffing companies (that I won't name here) that hire tons of new grads straight out college with degrees in things like business, communication, and sports management.

What are they looking for? Somebody that can make phone calls all day every day and try to sell jobs to candidates in what often amounts to a boiler-room setting.

You either figure it out or you are gone within a year.

Do you think these new recruiters understand the technical jobs they are placing people into? Do they understand frontend vs backend or .NET vs Java? No they do not, absolutely not.

They often have no experience in tech or recruiting for that matter.

Should you work with a recruiter with 3 months of experience at a big agency? This is the reason for most of the complaints about recruiters from what I can see.

There are very good, very experienced recruiters that DO care about relationships.

Generally, there are many smaller search firms that can be great to work with. Recruiters that understand tech, the local market, and how much you should be getting paid are out there.

So do yourself a favor - check out the recruiter's LinkedIn first. Have they been doing this for 5 years or more?

Or did they clearly demonstrate they actually read and understood your background before contacting you? These are the people you want to work with.

I hope I am painting a clearer picture about the industry here - you have a ton of very inexperienced recruiters washing out quickly, then you have a set of experienced recruiters who actually know tech and know recruiting.

Fresh out of a university or bootcamp? Generally, don't bother.

I have talked to recent bootcamp grads and recent university grads and they almost universally tell me that recruiters completely ignore them.

So I have asked different recruiters why they ignore recent grads. Want to know why?

Hiring managers don't want new grads, and they certainly don't want to pay for somebody to find a new grad for them.

A hiring manager often pays between 20% to 30% of a new hire's salary as a fee to a recruiter. Are they going to spend that much money on a new grad with no experience when they are getting hundreds of applications a month online? No they are not.

What is the answer?

At the end of the day working with recruiters short-cuts the hiring process and it is better than just applying blindly online.

But I think the thrust of what I'm trying to get across here is this: check out who you are working with, and then understand that they work for the hiring manager first and foremost.

By the way...

When you sign up to a job board you are going get a lot of spam. To get around this, I've been working on a system with called Alcamine with Marcus Wood.

We give you a special email address you can use on job boards and we rate the recruiter messages coming in. Give it a try!

Docker explained visually for the non-technical

Aaron Decker — Mon, 25 Nov 2019 16:01:22 +0000

Docker has been out for a while now and is being used widely. I think an understanding of how to use Docker is starting to become as necessary a skill as version control (i.e. git) for professional software engineers.

Yet, many non-technical people don't understand Docker.

And this is not surprising because it is complex and you have to understand several layers of things to really get to what exactly Docker is doing for people.

Nevertheless, Docker is a hot technology and we have to talk about it!

Note: This article was originally written for recruiters, but I tried to break this down so that anybody working in tech (but without an engineering background) could follow it.

Operating Systems & Virtual Machines

You probably know what an operating system (OS) is and can probably name a few. Windows, Mac OSX, Linux. Those are all operating systems. They are designed to be the software that is the base layer you install onto your physical hardware (your physical computer) and run programs inside of. The OS handles connecting your programs to your input devices like the mouse and keyboard, as well as output devices like monitors.

Pretty basic stuff right? Well the idea of a virtual machine (VM) means running an operating system virtually. You can actually install programs that let you install another operating system and run it inside of your host operating system.

So it can look like this:

Physical Hardware: Apple MacBook
Host OS: Mac OSX
Virtualization Program: Virtual Box
Virtual OS: Ubuntu Linux

I made this diagram below to explain an example of doing this:

It is actually like having another computer running on your computer. You get a window where you can go inside of it and interact with it.

So, what is Docker then?

You can think of Docker like software that runs virtual machines. Specifically it runs things called Docker containers, which are derived from things called Docker images.

To be clear, Docker is like a virtual machine runner. It's not though, it actually does something that is much more efficient than running an entire VM, but I am not going to go into those details in this post.

Docker images are like a template for a virtual machine that can contain anything you want. For example you might define these things when you make a docker image:

A base OS, to start from such as Alpine Linux
Programs you installed on the OS (such as Java if your program is a Java app )
Your program’s code - which would be your Java code

Then, when you run this image, it will run your program you wrote! And it will run it anywhere Docker is installed. That is the important part: if you install Docker somewhere else you can run any docker image on that computer too.

Hold on what is the point?

When you "ship" code to the cloud, you are just trying to run your code on another computer in a data center somewhere. So when you read something like:

Docker helps you ship code and run applications anywhere

That is what they are talking about. You are trying to run your code for your software on another computer (probably in the cloud) and Docker helps you do this.

Using Docker

As I said, when you build a Docker image, you are usually doing it with the goal of building it with your application code. So when you make the template you write instructions that copies your application code into the image. You do whatever build steps need to be done (such as installing libraries or compiling code). Now you have an image.

Now that you have an image you can run it anywhere Docker is installed. So for example, on your server running out in a cloud service provider like AWS. You install Docker once, on a machine running in the cloud and then you can just update the Docker image and run the new version of the Docker image!

Here is a diagram of making a Docker image and running it:

Vertical Views of what is going on

I made a few more fancy diagrams to show what is happening when you run containers in two different scenarios. This is a more real world example how you might run multiple containers on the same Docker runtime.

These two containers (a Java application, and a Database) will be like two separate computers running on the host computer just like Virtual Machines. Except that Docker is much more efficient than running entire virtual machines. Docker containers typically run only a single process, which is the thing you want to run. So here you can do this and not experience big performance issues like you would if you were running full VMs.

Why are people using Docker

Again, basically because it makes it easy to deploy apps. If you can ship your development environment exactly to your production server environment your customers are going to use (again, in the cloud) that is going to help you cut down on issues by a lot.

I will let this meme sum it up.

In addition to that there are a lot of tools built on top of the idea of running Docker containers, and containerization in general such as Kubernetes or Docker swarm, so generally people have a whole other system layer in the mix. But I will save those details for another post.

Conclusions

There are a lot reasons why people are using Docker:

Makes it easier to reliably build your application
Makes deploys easier and more reliable
Makes it easier to share and run a complex dev environment
Can easily run things like database servers without installation (traditionally, you could not!)

And most newer software projects have Docker somewhere in their process. Whether that is in their development environment, their production environment, or just in their CI servers, Docker is probably there.

So understanding Docker is important because more and more in the future Docker is going to be foundational to many new technologies coming out. And if you can't understand the foundation, it will be hard to understand the new things building on top of the foundation.

Did this help you? I got a lot of requests to write this post! Let me know if this cleared things up a bit. Docker is really hard to understand because you need to grok a lot of concepts first to get why you would want to have a tool like this.

How I Built A Custom Art Commissions Site In 2019

Aaron Decker — Tue, 19 Nov 2019 17:53:57 +0000

Late last year my girlfriend Meridith's side hustle was blowing up and she was spending a ton of time on administrative tasks, which of course with me being a software engineer made me want to help her automate everything.

What was this side hustle you ask? Pet Portraits. She's a classically trained artist (she went to RISD) working on her own art career but to pay the bills she ended up doing a ton of pet portrait commissions and it kept spreading via word of mouth.

She was spending too much time emailing back and forth with people to get photos and contact info and accept payments. Yeah! I can solve this!

The business process

So let's think about the current ordering process. It goes something like this:

> Customer: Hey I heard you do pet portraits, can you paint my dog? 
> Meridith: Sure! Do you have a good photo?
> Customer: How about this photo?
> ... *Meridith explains the kind of photo she needs*
> Customer: How much does it cost for size "x"?
> ... *Meridith gives pricing info for various sizes*
> Customer: Can you mail it to this address?
> ... *collects mailing address*
> Customer: OK, how do I pay you?
> ... *more back and forth*

Okay, you get the idea. It's like 20 emails by the end of it. It would be much easier to make a site that tells you all of the important information about the photo and the pricing and collects all of the required information (and photos).

So I made an order form with these steps:

Upload Photos
Pick order type (shows size & number of subjects options)
Shipping destination - collect address
Billing info - collect email / phone / let them enter coupons
Order confirm + pay (shows subtotal then trigger stripe checkout)

So I decide to built a custom site

I decided to build something custom instead of using Shopify or Squarespace. I figured "hey I can throw this together in a weekend!". I knew I needed to make something pretty complex where the customer needed to upload images and I figured I might as well build this instead of using some janky plugins.

Plus, I'm a software engineer, I got this!

The tech stack I chose.

I like to call myself a "full-stack developer", but I will admit my front-end skills are a little rusty. In fact, this would be great practice! I almost called this article something like "How I learned how rusty I am at frontend work".

I ended up going with MERN stack, and I used Create React App as my foundation. For my component library I chose Ant Design which I had never used before (and some of the docs are in Mandarin) but I don't mind a challenge.

I used Stripe for payments, AWS SES for email. Just set it all up on a single server on a cloud provider because there was not going to be a lot of traffic. I just threw this thing up on a linux box behind an nginx server and Lets Encrypt was nice and easy to set up. Anyway, I've done all that stuff a million times that was not the hard part.

OK site is done right?

Nope, not yet. Again I am a little rusty at dealing with frontend stuff. There are a ton of things I had to end up dealing with that I didn't even think about. I ran into some issues.

Social Sharing

You may not realize this but there are special meta tags that dictate how a link for a website will show up when you share it on Facebook or Twitter, for example.

Yeah... So for example, if you don't tell Facebook what title, description and image to show your link previews with it is going to look like junk when you share it.

So you need some stuff on your site like this in the header:

<meta property="og:title" content="Starshine Pet Painting"/>
<meta property="og:description" content="Beautiful Hand Painted Art As Unique as your pet."/>
<meta property="og:image" content="https://www.starshinepetpainting.com/images/overlay-logo2-small.jpg"/>
<meta property="og:url" content="https://www.starshinepetpainting.com"/>

Which sucks, because obviously the first time she shared this to Facebook it looked like crap. Protip: Facebook has a tool you can use to make sure all this stuff is set up correctly.

In-App Browser (for instagram and facebook)

Also, here is a thing you may or may not know: mobile traffic exceeds desktop internet traffic these days.

Yeah, you probably did know that. Ok here is another thing: a lot of mobile web traffic is actually coming from in-app-browsers from the facebook or instagram apps for example.

Did you know that sometimes, depending on the phone OS, these in-app-browsers are really super out of date? Also did you know it is very difficult to debug this junk?

Well, I do. Now. 🤦

So what do you do when you photo picker component mysteriously doesn't work on the in-app-browser in facebook in some random Android phones?

Put in a polyfill and hope it works (which it did, thankfully🙏).

The general front-end woes

Generally speaking, I still had to do all the things that are hard about front-end. That means testing on multiple browsers (including IE 10), and multiple phone OSes. I still had to test on a bunch of different screen sizes so that means testing on everything from 4k down to 320px wide mobile devices.

Somehow this all seemed more stressful than normal since if it didn't work I would be turning away paying customers, and it would not be some kind of internal business application like I was used to working on. Or better yet, the backend of a server where I don't have to worry about any of this stuff!

Everything just took longer

I guess I didn't realize the reality of things is now that everything is being shared socially and it is super hard to get traffic from Google. So what we ended up doing was just focusing on how things looked in all the various social media platforms and they all have their special quirks and meta tags and whatever.

Doing the backend even took longer than I thought. The whole goal was to make this quick and easy so I didn't build an auth system since I didn't want people to need to create accounts and all of that, but that meant triggering a emails that had a lot of content in them. Stripe is to easy to use but there still a decent amount of coding involved to handle error scenarios and all of that.

Ecommerce is a lot more complicated than it first appears. You have to collect a lot of information to successfully fulfill an order and there are lot of things that can go wrong. You have to effectively communicate to the user what you are selling and answer all of their questions or they will just bounce. I'm still not sure I did that totally effectively in the landing page, but hey, that is a work in progress!

Pivoting to $30 Sketches

One weekend in Novemeber we had the opportunity to do an in-person popup show at a local community market where Meridith decided to quick 20 minute sketches for $20. We called them "$20 Dog Doddles", well that was an enormous success, I don't think we had any downtime the whole weekend, and on an hourly basis this was just as profitable as doing more fully rendered paintings.

We had acheived product market fit. So we redid the website and started to offer a $30 sketch option (to cover shipping) and the price point just makes the whole thing so attractive to a much wider audience. Here is a screenshot of the landing page for the $30 sketch option:

The other cool thing was since I built the site custom it was pretty trivial to lift any component I needed up one level and refactor the code to handle more order types and prices. In the update to the site I even put in a cool timelapse background header video of Meridith drawing a dog.

So what did I learn?

Anything you are selling these days needs to be optimized for social sharing. This takes a fair amount of work and experimenting.

In-app-browsers are a huge pain, but facebook and instagram don't want the user to leave the app, so they are here to stay. You just have to deal with it and polyfill if you can.

Ecommerce sites are hard to make and they have a lot edge cases. But it was a good experience and now I have the ability to really customize the order process for this niche of custom commission pet painting.

Finally I think another big lesson is that you need to try different things until you find something that is really a hit. The fully rendered portraits starting at $150 a commission (for just a small 5x7) are too expensive for most people, and the more stylized quick $30 sketch option appeals to a much wider audience. So by trying out these different ideas we figured out something that was still economical to produce but had a much wider appeal.

Reviving A 19 Year Old Test To See If An Employer Is Worth Working For

Aaron Decker — Fri, 08 Nov 2019 19:41:00 +0000

Joel Spolsky (the guy responsible for Trello and Stack Overflow among other things), wrote an article on his blog about questions you should be asking potential employers as a software developer.

Talking to newer developers I realized that most of them have neither heard of this guy, nor of this set of questions. Not surprising since this famous blog post was written 19 years ago!

I think this test is still relevant and really will weed out some bad employers, but we should update it! Actually, wait it needs a ton of updates... This was written in the days when you went down to the store and had to physically buy software on disks! 🤢

OK, here is the original test:

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

The idea was, if an employer did all of these things then chances are they would be great to work for as a software developer. So this is a checklist to help you consider if a job is worth taking or not.

Is anyone not using source control?

What sounds outdated here? How about the source control, question - who doesn't use source control? For that matter, who doesn't use git? If they don't use source control they are not doing any of this other stuff. How about the build step - people don't build much desktop software anymore and we are not thinking much in terms of passing builds. The master branch should always pass tests and build!

Lets ask this to cover the question about builds: "Do you have a CI process in place?".

And furthermore, maybe a more relevant question in the age of SaaS apps is this: "can you do one-click deploys?". Or maybe even, "How fast can you deploy a hotfix", that might get an interesting answer.

Do you fix bugs before writing new code?

This is a tricky question. I think most software projects have tons of outstanding issues that maybe can't be fixed or are too hard to fix and you have worked around them. Again, this is more of the mindset of building desktop software you are going to ship in releases once a year and you fix the bugs before the next release... If you are working on a web application you care more about the bugs that are actively going to cause users trouble.

Maybe a better question is this: "How do you monitor you application for errors in production?"

Do you have a schedule?

I'm not exactly sure what he means here even. I think he is talking about when you did desktop software you were going to ship a certain set of features, and when you decide you are done you go mail off the CD-ROMs to your customers. 🤣

Let's skip this, and the spec question, and ask about development methodology. Are they doing Agile, Scrum, Kanban? What?

Do programmers have quiet working conditions?

Keep this question! In my opinion open offices are the worst possible thing you can foist on developers. Really? Shove us all in a bullpen with people running around everywhere having loud conversations while we try to do a job that requires insane levels of concentrations. Really, that's a good idea huh? 🤦

Do you use the best tools money can buy?

Here he is talking about things like nice chairs, servers and services. I think this is important but the most important things are basically free these days. You don't need to buy specific compilers and editors. VSCode is free. You just need to hope your company got you a nice computer. Maybe ask about that if you are worried, but in my experience most companies are now getting devs new MacBook Pros.

Do you have testers?

I like having dedicated testers on my team but many places don't anymore and if you have a good process in place for automated testing you can do just fine.

Instead I would ask this: "How do you test code before you deploy to prod"? Then you can decide if you like how they answer.

Do new candidates write code during their interview?

It makes a big difference if you work with good people or not. There is no substitute for seeing if somebody can code or not. You have to actually see it to know (in my opinion). I think this is still a good question to ask.

The answer is yes if the company does any of these things:

Take home test
Whiteboard problems
Pair programming problems

Do you do hallway usability testing?

This is again, about desktop software. You had to test with your users before you shipped the box of CD-ROMs to Circuit City (RIP⚰️).

Now, with web applications people use telemetry services to monitor users and track what they are doing, like Hotjar. You can set up A/B testing and see what users prefer, and you can do it at scale with real users in realtime.

Here is a better question: "How do you collect feedback from users and make design decisions?"

A proposed new set of questions:

Do you have a CI process in place?
Can you do one-click deploys?
How do you track issues?
How do you monitor you application for errors in production?
What development methodology do you follow?
Do programmers have quiet working conditions?
How do you test code before you deploy to prod?
Do new candidates write code during their interview?
How do you collect feedback from users, and make design decisions?

Yeah, I know, originally you could simply say "YES" or "NO" to all of these so it was an easy metric to measure. Now, you get to judge if something is a "YES", but it's still pretty easy.

If you ask "What development methodology do you follow?", and the answer is "We Don't" - well then they fail that question!

I think it's better that some of these are open ended. You can ask them in an interview and sound thoughtful. 🤔

By the way I originally posted this blog here, which is the blog for a side project I am working on called Alcamine. Basically it is going to be a system where you get a special email you can use to sign up to job sites and we will score and filter all of the junk recruiter email coming into it!

Message Queues And Kafka Explained in Plain English

Aaron Decker — Sun, 03 Nov 2019 16:54:29 +0000

Want to understand why kafka is gaining so much traction and hiring managers are looking for people with this skill?

Well, I wrote this article to help illuminate kafka a little bit, but I also explain message queues in general first to build up the foundation to explain Kafka.

What is a message queue

The purpose of a message queue is to help reliably deliver communications (or messages). If you google "what is a message queue" you will get an answer like:

Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time.

But I think you can explain this even more simply. You can think of a message queue like a PO box. The mailman might deliver a message there any time, and can keep putting them there until you go collect them. They can build up or be retrieved immediately.

In this example the mailman is the "Publisher" or "Producer" and when you go get mail you are the "Subscriber" or "Consumer".

Here is a diagram of this system:

Why use a message queue?

Well, there are a lot of reasons but basically the answer is that real world systems are a lot larger and more complicated than a simple single consumer, single producer postal system.

You might have many consumers of the same message, you might have to deal with fault tolerance (what if something breaks while processing a message?) or you might want to be able to track when messages are being delivered.

Here is a diagram of what things might actually look like inside of a social media application that would allow you to upload photos. A user uploads a photo and it is saved to a database, in addition to a message queue. Multiple consumers use this notification so that they know a user has uploaded a new photo, but ultimately it will show up in the "notifications" of your friends.

What is Kafka

So with the basics of the "what" and "why" of message queues out of the way, now what is Kafka?

The chief difference with kafka is storage, it saves data using a commit log. Kafka stores the messages that you send to it in Topics. Consumers can "replay" these messages if they wish. Normally in message queues, the messages are removed after subscribers have confirmed their receipt.

Another thing different about kafka is that the topics are ordered (by date they were added). Not all message queues guarantee this.

Individual Kafka servers that store messages are called "Brokers". Brokers are typically used in a cluster, which means many servers are linked together to handle lots of data and traffic. Topics may be further broken down in "Partitions" which are divided across brokers.

Kafka easily lets you divide up the work of publishing and consuming messages across a cluster of brokers. This is what it looks like:

Why is Kafka so big now?

Kafka was originally developed at LinkedIn to handle large quantities of traffic and provide a platform for handling real-time data feeds.

Kafka is designed to store data in what could be thought of as a transactional nature. Groups of consumers keep track of where they are while reading a topic so multiple consumers can read lots of the data from the same topic while breaking up the work between them. If you wish, can read any existing topic starting from the beginning to get all of the messages that were sent.

Things to talk about when it comes to Kafka

In terms of evaluation of somebody's experience with Kafka, there are a couple of things you could ask about.

How many transactions per second did your system handle?
How did you decide how to size your cluster?
Why did you decide to go with Kafka over something simpler?
You can ask things about the number of topics, partitions, consumer groups, etc.
What challenges did you encounter implementing kafka in your system?

Generally asking "why" questions is a great way really understand if a person had decision making power, or if they really understood why they were doing something. But asking more specific questions about scale and challenges faced in implementation can be useful as well.

Summary

Message queues are a common architecture that might be encountered on the backend of many types of applications. Almost every significant application or company building software will have a message queue somewhere in their infrastructure once they get to a certain size.

Kafka is being adopted in many large organizations because of the ability to store data messages indefinitely and deal with high amounts of traffic. There are a lot of other features of Kafka that I didn't touch on (such as the stream processing system) but these are the basics and should help you understand a little bit about why people are using it and what it is for.

Note: I originally published this on the ITeach Recruiters blog here which is where I am building courses for recruiters, but I thought this article was general enough that new developers just getting into these concepts would be interested.