Latest Ramblings

I love testing. I’ve always been a big fan of testing, but in the last 5 years, I’ve seen a lot of really terrible tests written. Today I’m going to explain to you the levels of testing I believe are most useful.

Where testing has gone off the rails

Testing started out great. Test Driven Development (TDD) slowly became the king especially with “Red, Green, Refactor” as its slogan. TDD has fallen off the rails. It’s far too close to the code to be of any help.

Far too often the test cases are too narrow and too specific to how the code was written. The concern with testing for far too long has been “how many lines of code are covered” or “the test suite is not consistent on the testing servers.”

There are levels of testing. While TDD is great for unit tests, I think unit tests have extremely low value in application design and should be used minimally I know this goes against common thought in our industry, but since our time is limited and valuable we want to use the best tools for the job.

There are 5 levels of testing worth doing

Penetration testing

Yes, this is the most important test you could conduct on your system. Developers don’t write automated tests for this nearly enough. This needs to change.

Performance testing

This helps us know how our application will handle under load and spot issues like N+1 query issues.

Unit level tests for complex logic

I think unit tests are great when dealing with input that has to be regexed, transformed, or computed. The question I ask is: “In reading this code, how complex or complicated is the logic?” If I can understand it in about a minute or two, it’s not worth testing.

UI tests

Did the page draw? Do the buttons work? Does it look okay in IE? Chrome? Firefox? iPhone? Android? Cool. When the UI consumes an API, I tend to mock those out and simulate use cases, errors etc… I try not to use a real API -just mocks.

Contract testing

This is what we’re talking about today. Basically, we test in a similar fashion as “black box” testing with some BDD similarities.

Rules for Contract testing

Rule 1: Tests are loosely coupled with implementation

Coupling in software leads to inflexibility which leads to unhappy builds and test suites. When writing and building software, I think of what are the things this software I’m writing is going to be doing. What is the point?

That should leave you with a few possible outcomes:

I’m building a system script for some purpose

I’m building an API that others will consume

I’m building a UI that someone will use

Contract testing is best applied to 2 and 3 - when there is some finite outcome.

Rule 2: Tests are purely functional

Contract testing is functional testing. It’s purely black box. For example, this could be helpful in implementing a Tax Rate API. You supply $6.17 in sales for groceries and in Denver, Colorado the city sales tax is 0% for food. Therefore the total price is $6.17. In Boulder, though, the sales tax is 6% so you have to account for each situation:

The input price

The location

The expected outcome

Unless tax rates change for a given location, the expected outcome should be consistent regardless of the technology. There are no side effects.

More generally, contract testing is focusing on outcome versus implementation.

Rule 3: Testing that is platform or technology agnostic

This is derived from rule 2. The technology of the testing mechanism is platform independent. Your tests aren’t necessarily written in the application’s language. They’re implemented separately. The advantage of this when it comes to API testing is that when your tests are separate, the code base can change without breaking the tests.

When the code base changes, the tests don’t have to unless there is a rule that the tests didn’t account for. This style of testing can be likened to black box testing.

This approach is really helpful when building Microservices. The idea is that you are testing “I send in x,y,z data” and I should get the same response every time. The code can change. In fact, as long as you implement the correct format, structure, and return a consistent response based on input, you can change everything. The database, the tech can go from Ruby to Elixir or Node. It can be deployed to Google Compute instead of Amazon. Everything can change.

Why contract testing?

I think it can be summarized nicely.

Testing the contracts:

Allows true flexibility in design of the software

Creates consistency

Ensures that your code can change while your tests are fixed

Prevents bugs from creeping into your software through refactoring or other redesign efforts

Saves time from having to write large, complex test suites that break every other build

How do I do contract testing?

This is where it gets harder. This is not as common in the industry as TDD, so there are fewer tools available. The way I approach this is a bit interesting:

Every API has a schema

It can be XML or Json. I prefer Json schema as most developers in the last 5 years can read it far easier to XML. It defines the keys, the acceptable parameters, and the associated validations as well as if the field is required. This can be helpful for generating mock test data. There is a really good tool for generating these types of files: [RAML] (https://raml.org/)

Using the schema, I can generate mocks. Also, I publish a dynamically created schema from the API. From this I can write a test that says:

Does my stored schema match the one the API is returning?

If it doesn’t match, that could lead to interesting and unexpected bugs for the consumers of our APIs.

Every API endpoint has at least one related test

Each API needs a bunch of different tests for each endpoint. You need testing for things like authorization keys, headers, client-side errors, server-side errors and the list go on and on in terms of the error checking you need to be doing.

More importantly, you need to test each possible scenario. If you’re writing an API that takes zip codes and returns the sales tax for that area, you need to account for oddball zip codes (such as those that end with 9 or start with 0) Fun fact: 00501 is the zip code for Holtsville, New York. Test the bounds, the ranges, and the edge cases. By doing this at the API level, you’re not tied to how the code was written to get there but instead to the outcomes.

Almost any testing suite can do API calls. In Javascript, I’ve been liking Jest quite a lot. There are also things like RSpec with Ruby (You don’t need Rails).

In a future post, I’ll give you a demo of how this all works so you can see and poke at living examples.

Am I off the rails or do you agree with this article? I post these things to Reddit and Hacker News, so if you have something to say please say it over there. I’d love to hear from you.

Most meetings suck. The person running them doesn’t actually run the meeting. They’re collections of random people unfocused, collectively wasting time for little or no purpose. How do we make meetings more effective and not waste time?

Well, today’s lesson comes from my friend a therapist turned software engineer; Casey. Casey can be a goofy guy, but he’s really, super-duper serious about meetings and not wasting time. I’ll teach you the format he taught me to make meetings wildly effective.

Every raft needs a river guide

You’re on this raft called a meeting, everyone is riding along, but your river guide is clueless. He doesn’t know the water flows downstream or that the river ends in the giant waterfall that is Joe rambling for the next hour. You have an in-experienced river guide.

What is a meeting river guide you ask. A river guide is there to guide you past obstacles and send you hurtling into success. Think of a river guide as a moderator. This person defines the agenda, runs the meeting and ensures everyone’s voice is heard.

Every meeting has an agenda or purpose

Why are you meeting? Why am I sitting here staring at your head and watching to your lips move? There has to be a purpose to the meeting, the river guide sets the tone for the meeting and the agenda.

Recently we had a developer’s forum meeting to discuss our UI library, I was the river guide. People had proposed topics for the meeting on Slack the days before and I moderated the discussion.

I started by defining the agenda in a common format:

Who’s our note taker? I ask up front, first ask for commitment from one person to type and post notes to Slack. If nobody volunteers, I pick somebody at random. Once we have our note taker assigned, I tell them to start typing!

I’ll read off the proposed list of topics to discuss then I’ll write them on the white board.

Once they’re written up, I’ll go item by item, asking how much time does the person that proposed the topic want to talk about this item. Typically its 5 to 10 minutes.

We add up the numbers and make sure we have enough time to cover everything before the meeting time is up. If not, we cut topics aggressively.

The river guide steers clear of obstacles

When you’re floating down the river, you want to watch out for rocks, logs and waterfalls. If the river guide is experienced, they’ll know the spots to watch out for.

In meetings, it’s much tougher to combat the unwanted rocks and land mines even if you’re experienced. In our meetings, the river guide employs a few tactics to prevent issues from popping up.

Time boxing each topic. With an agreed time box, the river guide watches the clock or runs a timer. If we need more time, we agree that we need x more time to chat and we might not finish our list.

If the discussion can’t be wrapped up quickly within or shortly after exceeding the window we gave it, we will often table the discussion for the next meeting unless it’s urgent to solved TODAY.

The river guide asks team members who have been quiet to ensure that no voices are missing. Some people are really shy and don’t like to share, being a gentle river guide can coax those people out of their shells. While others are in silent agreement or disagreement.

The river guide often will as for a vote if a decision is to be made. Some guides like consensus, I’ll take a majority unless it’s very close, such as if there’s only 1 or 2 people making the difference.

The river guide doesn’t let Bob, Joe or Johnny dominate the conversation. The guide asks people for opinions and insight. If Johnny is dominating the conversation, then he tries to get other people talking and get their input.

Who is the river guide?

The river guide can be a developer, project manager or any person really. They have a simple job: set the agenda, set time boxes and push people who abuse the time boxes. In our community forums developers sign up for a 3 week commitment to run the meetings and contribute.

What tips and tricks have you found to make your meetings more effective?

I love retrospectives. They give the team a chance to reflect, to learn, and to really bond. Our retrospectives are the highlight of my sprint. I love doing them. Our format is quite different than you would expect from a typical scrum retro.

The Environment

We don’t buy a couple of cases of beer and moan about our company/ team/boss in the conference room for an hour. We don’t even whine or complain. We set the environment to be intimate and to allow people to bond. We go out, far away from the office. We always do our retro at a restaurant or bar. The company doesn’t buy; we all “go Dutch.”

The great thing about doing it away from the office is that your teammates let down their guards, so they’re more social and human. People order food and talk sports. It becomes so much more friendly and less “work” like.

Our rule is that retro doesn’t officially start until after everyone has gotten their drinks, which gives us plenty of time to banter and hang out.

The Format

Typically, a retro is “whine about this, complain about that.” I’ve seen that format in so many companies. It’s pretty old and annoying - not to mention it’s not effective.

Roles in the meeting

We have the host - the person in charge of herding the cats to the restaurant and picking the place. This person kicks things off and explains how the process works

The note taker - this person takes notes on what the team offers as feedback.

The attender - this person gives feedback to 5 focus areas (see below) and can be either of the first two listed.

One notable person that is NOT in the meeting is the manager. This person never attends any of our meetings EVER.

We have each person write down things for 7 minutes - related to the 5 focus areas. When the timer is up, someone will volunteer to go first and we’ll go around the room “round robin” style with each person giving their feedback to the 5 areas. We will talk about their reasoning and logic, take notes, and decide on action items.

The 5 focus areas

“Bob is a fun person to pair with and has been receptive to my feedback.”

What do we want to stop doing?

For example, a few retro’s ago we had someone give the feedback that during meetings with the team we often talk over each other and it’s really difficult when you’re trying to explain a new idea.
Other times it has been “Please stop showing up 15 minutes late to our stand up.”

What do we want to start doing?

Start contributing to UI Kit.

Start writing E2E tests.

Start using Slack.

These are all great examples of starting actions.

What do we want to continue doing?

Continue collaborating.

Continue pairing.

Working with the design team to refactor the UI so it’s consistent.

Feedback to management

We use this to address specific blockers, such as:

Nobody has access to install yarn packages locally.

The firewall blocks access to stack overflow.

We don’t have clear requirements.

The Result

Our retro has been totally refactored. It has helped the team to bond and come together. We fight less, talk more, and we have a team that works really well together. Our meetings are more focused on actionable items than feelings.

While feelings are important, having structure like this allows people to move past being angry or sad to focus on the heart of the issue. That’s what this format is designed to focus on: the why behind the problems or improvements.

Today, I just finished the book, So Good They Can’t Ignore You by Cal Newport. I listened through Audible and I have to say it’s extremely remarkable in terms of how it affects my career thoughts.

Following your passion is terrible advice

Following your passion is terrible advice, Cal argues. It’s because the passion hypothesis pronounces the view that the ‘perfect’, ‘dream’ job exists. That to achieve dream work you must start with an existing passion and discover your true calling.

He argues instead that to find dream work, you need to first discover what you’re good at then build “career capital”. This is capital you can use to “cash in” value to trade for things that give you true career happiness.

Career capital

Career capital is the knowledge capital and human capital we build up over our career. He uses a few different examples of how we build career capital.

How you can build Career Capital:

Education and background. It’s the deliberate effort to become proficient at something.

It’s most useful when the skills being acquired are unique and rare.

Deliberate practice in areas of effort that will stretch yourself.

Work Hard: doing deliberate hard work to become the best in your company, team or organization.

Develop tangible skills that translate to real-world value.

Minimize the time you spend on things that won’t help you improve.

Be patient.

Leveraging career capital to have true workplace happiness

To gain workplace happiness we cash in our career capital to gain important things such as freedom, autonomy, and interesting work. One key point Cal makes is that when you seek to gain autonomy, which greatly benefits yourself is when you’re most at risk of getting strong resistance from peers or employers.

How I’m going to use So Good They Can’t Ignore You to hijack my career

Marketing – He mentioned in the book that Seth Godin wrote Purple Cow. He talked about a Ruby programmer that used to book to rocket his development career by marketing his AI that produces dance music. This leads me to think about John Sonmez and the Simple Programmer’s message to create a marketing plan for yourself. My approach to marketing is first to study people like Seth and John then adopt a plan to market myself by working on something unique.

Open Source – Cal also talked about open source developers getting noticed for their valuable contributions to the community. I’m going to seek out a project I can leverage my existing talent to contribute.

Hard Work – I’m going to work harder at my job. Start using pomodoros to force me into forced concentration to get things done, faster, better, and smarter.

Deliberate practice – As apart of my habits, every day I’m going to adopt 1 hour of focused time to learn things that hurt and make me grow. A few key areas of DP that I’m interested in developing are:

Functional UI programming. Getting really good with function client-side programming and understanding a completely different approach to what I am used to.

Reactive UI programming. I program in React but this goes beyond react and I’m nervous to learn more.

CS topics, specifically algorithms, trees, sorting and searching. All that CS type stuff I rely on the library to do for me.

Elixir. The future of the back end! I need to understand and know how to work with Elixir as it’s being heavily used by the Ruby community.

Being Stretched – Lastly, I’m going to speak at a Meet up once a quarter on topics covered here on my blog. I’m also going to commit to attending a meet up once a month.

Books on my in-progress or to read list

Currently I’m reading a book called “Celebration of Discipline”. It’s a book on your relationship with God, I’m working on a few things using that book.

Clean Architecture by Uncle Bob. Talks a lot about building systems, currently reading.

For my big rewrite project I’m working on, I decided it was time to start referencing modules by an alias instead of a relative or absolute path. It has a bunch of different modules, from the Redux store to an API service that almost every component or action consumed in some way. Figuring out the file path to the store or other common services was a chore.

The goal was an ES6 statement as follows:

importstorefrom'app-store';importAPIServicefrom'api-service';

This is how we got there.

Dependencies

We are using an ejected version of the create react app. This is running the latest version of React and Webpack. We’re also using jest for testing and eslint for linting.

Configure your webpack environments

The first step to adding a module is to figure out the absolute path of the module you want, then configure webpack.config.prod.js and webpack.config.dev.js. You may also need to add to other .environments.

Under the module.exports, there is a parent key - “resolve” - that contains a child object called “alias.” In our version of the react app, it came bundled with the following:

'react-native':'react-native-web',

Add a key value pair for the module you want to reference; in our case, it was the store.

'app-store':path.resolve(__dirname,'../src/store'),

Package.json

In your package json file, you will need to map the module you need so the jest scripts can find things.

Add a key under the parent “jest” called “moduleNameMapper” if it doesn’t exist, like you did above. This is ours:

"app-store":"<rootDir>/src/store.js",

Eslint config

In your eslintrc.json file. under the parent “rules,” there probably is a child: “import/no-unresolved.” If not, add one as an array collection. Then, add the rule to ignore erroring on unresolved “app-store” which ESlint cannot statically find.

This is what ours looks like:

"import/no-unresolved":["error",{"ignore":["app-store"],}],

Once you have all of that, the module should run with tests passing. Then, you can run the command yarn start This should not raise any issues with the linter running or starting the server.

Today we’re going to look at Redux. Redux is a popular tool to use with React. We’re going to explore the topic and talk about why you should consider using it.

What is Redux?

Redux is all about state (data) management. It takes the place of doing a traditional MVC approach where data is stored in instances of models and replaces that data storage with a global storage location. Typically stored on Window or top. The data can be stored in local storage or in a cookie.

Why Redux?

MVC is great, but for storing data it can be very difficult to reason about the freshness of data, how data mutates, or who has access to that data. Redux simplifies all of the complexity around state management by having 1 standard way of interacting with the state: A reducer.

Model of Redux

Redux at its core is a pub/sub model. Purely event driven. A component gets its state from the Redux Store. The component takes an action, like clicking a button which triggers an action to fetch data. The action gets data from the API, then notifies the system it’s done. Once that occurs, Redux check’s it’s list of reducers to see if there is something built to handle that action response. If there is a reducer to handle that response: it handles it then possibly modifies state.

The state change (if there is one) triggers Redux to update all relevant connected components, which will force a redraw in most cases, thus refreshing the screen.

What’s a reducer?

When a reducer is invoked, through dispatch, it receives a message stating what event is occurring, what the new proposed state could be and the current application state.

The reducer is a standard API for mutating the state of the Redux store. The code is pretty simple, it looks at the incoming action type, the proposed data and the current data then makes a decision about what to store.

You can see in this example when the event we’re getting passed in is to set a notification, we take the current information; text and type and pass that to be stored into Redux. Otherwise, we default to returning what is already there.

Testing this is so super easy. It’s a pure function.

it('testing the set notification case',()=>{constactionData={text:'Hello World!',type:'SET_NOTIFICATION',kind:'success'};constreducerValue=myReducer({},actionData);expect(reducerValue.text).toEqual(actionData.text);expect(reducerValue.type).toEqual(actionData.kind);});

What’s an action?

An action is invoked by a component /module/class. Basically, it handles the interaction between the API and reducer. There are two basic types of actions:

An action that notifies of an event. Eg, I need to set an error message or force a sign out.

An action that calls an API then passes the reply to the reducer to update state.

Actions can be pure functions, but they could also call out to an API service.

There are many styles of writing actions, but I always write mine in the style of being called in Context thus having Dispatch provided. There are other ways of doing it but this wraps the action and trigger together, which I like a lot. Axois is a 3rd party library I use to make API calls.

Dispatch, Store, and Connect?

Store

Let’s start with Store. The store is where all your state is stored. It has a restricted API, but you can change the “state” or “data” when you use a reducer.

Dispatch

Dispatch is something like pub/sub; it’s the messaging queue. It’s the mechanism that you let Redux know something is happening. Oh, I’m getting data! Oh, I got an error! It’s part of the Redux API. It’s the pipeline in which things like reducers are called.

Connect

Connect is the method of binding React components to the Store. Basically, you use something like:

This basically takes the state of the key ‘notification’ from Redux and shoves the data into the component. Possibly forcing a redraw (if it changes the props or state).

Can I access the state without connect?

Yes, you can. You can read the state, but you cannot modify the data without a Reducer or javascript hacking. The read-only way is to directly query the store:

store.getState();// returns the full store as a JSON object

Wrap up

This wraps up the quick and dirty explanation of Redux as how I currently understand it. If you have any feedback, please find me on twitter, @coffeeski or send me an email prodevmentor (at) gmail.com. Thank you for reading!

It’s a new year and many of us will soon set then forget our new year’s resolutions. One of the challenges I have personally is to maintain a grateful and content attitude. In this field we get to experience some of the best perks of the modern life: the internet, building cool stuff, working for cool companies, and cool rewards like big paychecks.

In the next few posts, we plan to look at how we can foster a culture of happiness in our organizations and most importantly in ourselves.

Happiness starts in your head

No matter your situation, there is something positive about your life. Starting with the most obvious, you’re reading this on an electronic device connected to the Internet. It might sound silly, but when work or life gets hard, I start with the basics:

I have a job that pays on time

I get to buy a latte/americano every day from the coffee shop across the street

I get to use a MacBook to do my job

The goal is to document 3-4 unique items that I can be grateful for and appreciate. The mindset shift can short-circuit negative thinking and lead to quickly generating a list of 10 or more items that you’re really freaking happy about.

Gratitude changes your attitude

Within almost any part of every day, there is something you can be grateful for. Being grateful helps you change your perspective and realize that in spite of the daily problems or challenges we all face, there are many things we can be happy about.

I find that when I journal about the moments in my life that bring me joy, such as getting coffee with a friend at work or eating food at that new restaurant in town, my focus changes and my mood brightens. My interactions with other people improve and it’s easier to interact. Even Oprah (ref 1) recommends keeping a daily gratitude journal.

Gratitude is most effective as a regular habit

I find that gratefulness has the most positive outcome on my life when it’s a daily habit. I make this habit happen every day at work. I have a recurring reminder scheduled and I fill out an Excel Spreadsheet with my four items, each with the same date and a short description.

This format helps me think about at least four happy things per day. If I’ve had a great day and want to add more, adding more rows in Excel is extremely easy. Keeping a regular journal like this helps me keep everything in perspective.

Gratitude should also be external

Gratitude should foster a happier attitude and outlook on life. Its impact on your health and well being is wonderfully helpful to you. Imagine the impact your better attitude could have on other people. How could you express gratitude towards other people?

Ideas:

Write thank you notes to specific people or team members you appreciate

Add a recognition section to your retrospectives

Publicly thank people at your stand up

Privately thank people by taking them to coffee and/or lunch

How have you embedded gratitude into your daily routine?
How do you feel when you express or receive gratitude at work?

Your manager has asked you to review a stack of resumes and pick a couple candidates that you think are worthy of an interview. What do you do? How do you decide? When you get to interview people, what are the approaches you can take to do it effectively?

I’ve interviewed over 100 people for various software engineering roles, and I’ve probably been to about 100 interviews myself as a Senior Software Engineer. I’ve seen what works and what doesn’t. Interviewing can be a daunting process since you want to be sure to distill down to the right candidate, but these tips can help you find the perfect fit for your company.

The basics

To effectively understand who to interview, you need to start with criteria and an understanding of what the expectation is for the new hires. Sometimes, it’s to increase all levels of skill, other times you need specialized developers who are experts in API design or Frontend Development. Gather the understanding of the role they need to take, then evaluate what skills would be needed.

For example, at my current company, I knew we needed several senior and junior front end developers. We want people with some experience, even completion of a tech boot camp, to fill our junior roles. The most important criteria for all candidates, though, was resilience: the ability to adapt to change with a good attitude.

Having a good attitude was the primary factor in whether or not a candidate progressed to the next step, because as a technology organization we are constantly changing directions and figuring out our market.

Given our criteria, who works best? From a technical perspective, we needed savvy people who could learn quickly, so out of the piles I picked the senior developers with the most diverse technology experience and the juniors with the most unique backgrounds.

The interview

This is probably the most important step. You have two goals as a interviewer: sell the candidate on the company and evaluate their skills.

Selling starts with a good story

Selling starts with a good story: why are you the right team/company/technology for the candidate? What are the pros and cons of working with you guys? Talk about your culture and share your accomplishments. Show them your rad office space, talk about the mad ping pong skills you have and how cool it is to work with you.

Most of all, talk about the why. Why are you guys making the biggest impact? What are you doing? When I interviewed at this big insurance company, my soon to be manager got me excited about helping millions of people find and get affordable health insurance. You’re making a real impact on the daily lives of the customers you serve. That’s what you need to understand and communicate.

The interview questions

There are a couple of different styles of questions that are effective for different levels of experience. Interviewing interns and junior developers can be extremely difficult. Developers from boot camps tend to have limited and specialized experiences in developing software. It’s good to ask entry level questions such as:

Tell me about Test driven development.

Talk about Agile and Scrum.

Tell me about your class projects.

How do you handle conflict?

What do you want to learn?

The questions tend to lean more toward a behavioral style of interviewing. You want to understand his or her process, learning styles, and manners of communication. For these positions, you’ll be expected to train and coach a lot more than for the more senior candidates.

When interviewing for a more senior position, focus on 3 main areas:

Personality

Working styles

Experience

Personality

You need to use some behavioral style questions. Common things are: how do you handle conflict? How do you handle disagreements? Are you confrontational? Are you passive? Asking targeted questions about projects and people while trying to let the candidate do most of the talking can reveal a lot about a candidate’s potential fit for the position.

Work Style

The next major piece you need to understand is how s/he conducts the job. Does the tooling used matter? Does s/he work best in Scrum or XP? Does s/he prefer to be solo or in a pair or a mix? These are easy questions, like:

Describe your ideal working environment.

Tell me about your favorite Agile development Methodology.

When you get a new work item, walk me through the process you use to see it all the way through.

Etc.

Experience

This is key to the position of a senior. Junior developers should know things like the command line, conceptual and be able to write some code on their own. Seniors on the other hand should be able to talk and demonstrate their:

Design and approaches they’ve used -as well as defend them with pros and cons.

Depth of technical knowledge

For understanding their technical knowledge, I prefer the machine gun approach. That is, I want to explore all topics in the related field. I often hire web developers so my machine gun belt looks like:

Explain from when you type “Key Lime pie” into Google and click search - what happens?

What I’m looking for:

Can they talk about DNS? Routing? Servers? Load balancing? Networking? HTTP? TCP/IP? How deep is their knowledge in how the internet works?

Explain how the DOM works in the browser

What I’m looking for:

Talk about DOM trees, Nodes and Leafs, how does the browser do async calls? How does it evaluate scripts, css, and tags?

Can you explain in well enough detail Node, Rails or whatever else you’ve worked with such that I can tell you actually know the technology and can communicate the benefits?

Explain how DNS works

Explain how you would create a data model of any part of an amusement park (This is very open ended, but gets them to think of a bigger system, can they connect the pieces.)

Explain how HTTP works

Explain REST

Explain the relationship between REST and HTTP

Using these and other questions, I can gauge a candidate and quickly figure out how well they know the technology stack.

What not to ask

Other things, though, like: “Do you drink? What’s your favorite scotch?” or “Do you like to ski?” tend to also be unprofessional and could get you into serious trouble with the law, especially if the interviewee thought it might be discriminatory.

What about coding challenges and white board sessions?

I think white boarding is effective for demonstrating depth of knowledge; ex UML. If you’re hiring for a code monkey, then sure, have tons of contrived challenges to discover their “knowledge” of the language.

Code is great, but it’s like written language. You can write syntactically perfect Javascript with all the forms, looks and lines but still miss the mark. Compare that to English, you need a subject, a verb and an object. Sure you can put random words together that look well, but the point is to communicate your ideas not to have perfect looking syntax.

Likewise code changes, standards change and people can change how they write code. What is much harder is to get people to express themselves clearly. I’d rather have to coach a teammate on Javascript 6 syntax then coach them on how to communicate their ideas.

Clear communication + depth of conversation = really good technical interview. The goal is to figure out what they know, how deep do they know it without getting hung up on syntax or other unneeded details. I want people who are learners, who want to grow and can share their ideas. You’re job here is probably going to go from working in one specific language to working with many within the next year, I would expect that you can learn and grow with those challenges.

Making a recommendation

In my experience, you don’t get to make a hiring decision, but you may get input. Typically I’d weigh the candidate’s personality and skills with the needs of the team. In my current role, attitude and playing nice with others is a bigger deal than technical fit. For that reason I may choose a candidate that is better suited due to their skill in interpersonal relationships than their pure technical knowledge. The question often comes down to: “Can I get lunch with this person?” or “Can this person teach the team something valuable?” It’s not just experience nor is it just personality that should drive hiring decisions. It should be a blend of both.

Hopefully you’ve gained some valuable intel to help you make your next hiring decision.

Welcome to Pro Dev Mentor! I’m Adam Bourg. I’m a software engineer with more than a decade of technical experience. I’m currently working as a team lead building the future of TV. I am passionate about building and supporting Agile teams to deliver high quality software. As I began working in the field, I noticed the lack of software engineering professional development opportunities beyond how to work with the trendiest technology.

Our mission at Pro Dev Mentor is to challenge software engineers to become effective leaders in their organizations. We do this by exploring technical and non-technical topics from a leadership perspective.

This blog is for you if want to:

Level up your career

Grow and develop better habits

Learn new skills and techniques to maximize pay, experience and responsibility

Increase your marketability

Articulate yourself better to colleagues and managers

Build secure, testable performant code in any platform

You can expect 2-3 in-depth posts every month. To get the most current information, you can sign up for our newsletter, where we will share a monthly post summary and tidbits about current best practices in the field.

You can look forward to posts about:

Mentorship series:

The look and feel of effective technical mentorship

Asking the right questions

Mentoring junior technical staff

Mentoring the organization to come up to a better process

Effective Agile Series:

Refactor the Retrospective to be more effective

Use a better pointing philosophy

We have about 30 different topics that we’re going to explore over the coming months. I hope you will stay tuned.