Issue 11 - Finding Fit with a Potential Team, Testing APIs from the CLI, and Finding a New Home for the Newsletter.

Hi friends.

In this issue, you'll find some questions you can ask your potential teammates to see what the team culture is like so you can make a better decision when interviewing. You'll also explore a new tool for interacting with APIs from the command line interface that I'm really excited about. Finally, this newsletter is going to move to a new home, so please read on to learn about that.

Assessing the Team During an Interview

Interviewing for a job is a two-way street. You're looking for a company that will pay you for your skills and experience, so it's natural for you to spend most of your time selling potential employers on your skills and experience. But remember that interviewing is a two-way street, and if you're going to spend a minimum of 40 hours per week with this team, you need to know what you're getting yourself into. The company itself might be great, but you want to make sure there's alignment with the team and how you want to spend your time. Plus, the team and its manager have the most significant impact on your day-to-day happiness.

You can ask questions during your interview to help you understand how the team works. However, I wouldn't ask the recruiter or the hiring manager these questions; I'd wait until you have an opportunity to speak with a potential peer.

Here is my list of questions:

How quickly can I get my development environment up and running?

This question gives insight into the team's tooling and documentation. Does the team use containers for local development? Cloud-based IDEs? Or do you have to install pieces by hand by following documentation? How up-to-date is that documentation? Can you do this yourself, or does someone need to help you?

How does the team handle bugs and feature requests?

Software is going to have bugs, and people are going to want new features. You'll want to understand what the process looks like. Does the team use a ticket system or JIRA? Are there a lot of requests and bug reports? How does the team prioritize each of these, and how do they decide how the work is split up?

How does the team make significant technical decisions?

You're looking for the balance between speed and process here, as well as alignment with the business. Is there a single person who makes all the decisions? Is there a group? Are the decisions documented somewhere? What does that collaboration and communication look like? How do the organization and business impact the decisions?

How does the team review each other's work?

Getting feedback on your work is critical to improving in your role, but it can also be a harrowing experience. You'll want to understand how and when your work gets reviewed. Is the process formal or informal? Are there code walkthroughs or just drive-by comments on PRs? Is it done in the open or in private? Does everyone provide feedback, or is it just a select few people?

How does the team tackle technical debt?

Sacrifices will be made to ship software on time. Not all technical debt is bad, but you'll want to know how serious the team is about paying some of it down. Is there time set aside to pay the tech debt down, or does it pile up in a backlog or a series of unaddressed TODO comments throughout the repository? Is there support from the organization to pay down some of the technical debt, or is it up to each team to do so?

What does the deployment process look like?

Once you've written some code, how do you get it out the door? Do you have the ability to deploy to production or only to staging? Is the process fully automated? Partially automated? Or are you manually transferring files to a server? And if you have the power to deploy it, how do you roll back bad deploys?

You probably won't be able to get every one of those questions in during your interview process, so you'll want to think about the ones that matter the most to you or see if you can come up with questions of your own that combine some of the topics.

Ultimately, you're trying to assess how the team operates and makes decisions. You're looking for a good fit for yourself. You might not be happy if you're the kind of person who doesn't like a lot of structure, but the team does. You'll want to know that before you sign the offer letter.

Hurling Requests at APIs

I use the curl program in my work almost daily.

I use it to test websites:

curl https://google.com

I use it to review request headers:

curl -I https://google.com

I even use it to download files:

curl http://example.com --output my.file

Or shove the content of a web page into a file:

curl https://bphogan.com/template.html > index.html

But for more advanced cases, I often get tripped up. For example, to use curl to send JSON to an API with a POST request, you'd have a command like this:

curl -X POST https://example.org/api/tests \
   -H 'Content-Type: application/json' \
   -d' {"id": "456", "evaluate": "true"}'

The -X flag sets the method, the -H flag sets headers, and the `-d' flag lets you specify the data you're going to send.

I wrote the book Small, Sharp Software Tools, which has a section on curl with more detailed examples, and I find myself relying on it often as a reference. I also have a section on HTTPie in the book, which is an alternative with a little more friendly interface.

But recently, I found Hurl, which I think is a fantastic way to work with more advanced cases.

With Hurl, you create text files describing the request you want to send. Then you run the file with the hurl command. This lets you create test cases you can replay later.

Here's an example of a hurl file that makes the same POST request you saw previously:

POST https://example.org/api/tests
{
    "id": "456",
    "evaluate": true
}

Assuming the file is called test.hurl, you execute it by passing the filename to the hurl command:

hurl test.hurl

However, Hurl's real value becomes apparent when you use templates for your data. Instead of hard-coding the values into the text file, you can use placeholders:

PUT https://example.org/api/hits
Content-Type: application/json
```
{
    "id": "",
    "evaluate": 
}
```

Then when you run the file, you pass the values you need:

hurl \
  --variable id_string=456 \
  --variable eval_bool=true \
  test.hurl

Now you can test multiple values quickly.

Speaking of testing, you can use Hurl to test your API's responses.

You can test the response time of a request:

GET https://sample.org/helloworld
​
HTTP/* *
[Asserts]
duration < 1000   # Check that response time is less than one second

You can check that a request redirects to the right place, which is great when you have to move content pages around:

GET https://example.org
​
HTTP/1.1 302
[Asserts]
header "Location" contains "www.example.net"

You can even use assertions to ensure the response that comes back from a request is the one you're looking for. Here's an example that checks the HTML response using multiple XPath queries:

GET https://example.org
​
HTTP/1.1 200
Content-Type: text/html; charset=UTF-8
​
[Asserts]
xpath "string(/html/head/title)" contains "Example" # Check title
xpath "count(//p)" == 2  # Check the number of p
xpath "//p" count == 2  # Similar assert for p
xpath "boolean(count(//h2))" == false  # Check there is no h2  
xpath "//h2" not exists  # Similar assert for h2
xpath "string(//div[1])" matches /Hello.*/

I've enjoyed using this to test a system I'm working on. While I don't see it replacing cURL for simple things like downloading files and checking my external IP address, I'm definitely using it for these advanced cases. The best thing about Hurl is that it uses cURL under the hood. Hurl is written in Rust and uses libcurl to make the requests, so I'm confident it will work as expected.

I hope you'll look at this tool if you're working with APIs.

Moving to a New Platform

After almost a year of publishing this newsletter, I've decided that my current platform isn't a good fit for what I'm trying to do here. My goal was to develop and publish my newsletter quickly, and this platform looked like a good fit. Lots of people I respected used it when I started.

But I've learned a lot about the product and the company behind it this year, and I've decided it's time for this newsletter to find a new home. I'm looking at a few options for the new year. Some of these options will give me much more control over the publishing process and the content, which I'm very excited about.

The December issue will be the last one on the current platform, which will give me enough time to get everything set up at the new home. I should be able to move everything over automatically, but I'll send out a separate message to every subscriber to ensure a smooth transition.

I appreciate everyone for subscribing, and I hope this move won't be disruptive.

Parting Thoughts

Here are a couple things to consider before the next issue hits your inbox:

1. What questions will you ask your potential teammates when you interview for your next technical role? Were there any here that particularly stood out as one that would help you make a better decision?

2. Take a look at the Hurl samples documentation to see what other features Hurl offers. Which one do you find the most compelling?

Thanks as always for reading. I'm on Mastodon now as well as Twitter, and I'd love to hear from you about this newsletter.

-bph

I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.