DEV Community: Valerio Francescangeli

Exploring Technical Tests in the Software Industry

Valerio Francescangeli — Sun, 22 Oct 2023 09:45:21 +0000

Technical tests are a staple of the tech industry interview process; they are used to assess the candidate’s communication, knowledge and problem-solving skills. This article will delve into the most commonly used ones.

Take Home Assignment

This type renounces on interaction and communication skills, which will have to be measured in a follow-up session, to allow for a longer time allowance to solve a problem. The advantage of this style is the ability to create a more complex set of requirements, allowing the candidate to choose where to focus their time and solve only part of them. If your company has an API third parties can use, consider using it in your tech test to create a test that will showcase your company’s tech offering. It will give you an edge in creating a personalised tech test, allowing the candidate to get comfortable with the domain. You can use it to ask them questions about your documentation, what they liked about it and the API itself, and see how they have integrated it into their software design.

Snippets-Based

This test required the candidate to analyse a piece of code and provide an answer on what it does, what’s wrong with it or what could be improved. It can be done both live or via a website or even email.

Asynchronous

It is generally used to see where each person focuses on when describing problems and possible solutions to the provided snippet. The candidate can be asked to improve, refactor, explain the code to a junior developer or conduct a pull request style review.

Live

It allows you to check their immediate response and thought process and how they arrive at their conclusion. It is the least realistic of the two since no one writes code like this. Developers rely on tests and IDEs with advanced debuggers to avoid keeping the entire program in the brain since it is, at best, a faulty version of what the computer already knows how to do.

Algorithm-Based

These types of problems are the most divisive. They are a time-effective way of checking a candidate’s communication and thought process, but they can be conducted while focussing on the wrong aspects. Please don’t treat them like a 100% guaranteed test of data structure and algorithm knowledge; use them to set a common ground that will allow you to test a candidate. Give the candidate time to prepare and tell them which structures will be used and which won’t to let them brush up and gain confidence. Have a set of problems that you will use repeatedly, and pick problems that can be solved without specific rules not applicable to other similar problems of the same type.

Pair Programming

This is the most open-ended one. Any problem can be solved in a pair programming setting. The emphasis here is all on communication and collaboration. For this test, define a few problems that respect the following characteristics:

1. Find a problem that is quick to grasp

The core of the problem should be simple and allow for multiple ways to implement a solution. This is because you want to facilitate a discussion on the pros and cons and ask the candidate to elaborate on a possible plan of action.

2. That can be extended

Especially in a pairing session, getting quick victories will do wonders for the candidate’s morale. Ensuring that the test is divided into multiple steps is useful for progressively adding complexity to a project and giving multiple stop points during the interview. Not all the steps must be completed; they are there to give an idea of what the full project will do and see how each developer will use that information while writing their solution.

3. That doesn’t require too much specific domain knowledge

It is hard to create a solution while understanding new concepts. If there is specific information that you want them to use, explain it well and be ready to facilitate their understanding and comprehension of it.

Questions about programming languages and frameworks/libraries

This type expects the candidate to answer specific topics, usually regarding a tech stack used by the company. When creating your list of questions, consider how easily a candidate could find the answer in a typical work environment. A good question should provide a starting point for an in-depth discussion about when, why and how to use that tech stack, framework or software design. Allow the candidate to explain it and ask follow-up questions by asking them to provide analogies and past examples of when they’ve implemented it, if applicable. Don’t waste their time by asking trick questions or a framework’s specific inner implementations; they are easily searchable online and won’t allow you to discover the candidate’s strengths and passion.

Conclusion

All these approaches are helpful to judge a software engineer’s skill set; decide which road you want to take, if focused more on technical solutions or more communication, and see which one will help you get a more exhaustive answer in your interviews.

On hiring software engineers

Valerio Francescangeli — Sun, 22 Oct 2023 09:44:17 +0000

In the past few years, the tech industry has seen a significant shift in hiring practices, with many companies attempting to replicate the FAANG method without fully understanding the context or requirements. This has led to a complicated and inefficient hiring process that often wastes both the company's and the candidates' time.

This blog post will discuss how to create a healthy hiring process.

Creating a customised hiring process

Each company has different requirements for their tech team. Don’t blindly follow what another big company does for their hiring strategy since the difference in culture and preparation could lead to many false-negatives.

Establish a talent/engineering communication channel

Create a communication channel between the talent and engineering team to align on who your company is looking for. Especially at the start, review the CV together (if possible, remove any personal information about the candidate) and discuss keywords, technologies and experiences to structure what type of profile you’re looking for.
A shared document with ideas and suggestions is a great starting point.

Create an interview plan

Ensure that the questions asked are part of a plan to get all the information needed to pick an ideal candidate. Each interview step should have a clear goal and a set of questions to get your desired answers. Not all candidates will respond well to a one size fit-all question; a more open-ended or direct approach could make a difference between a candidate feeling stressed and one that will behave like they are already part of the team.

Align hiring with company values

Use company values to shape your hiring strategy, which questions to ask and which answers to give when questioned by the interviewee. Find examples where the company kept true to its word and where it lacked and use them to provide an honest overview of the company. The candidate will appreciate this, allowing them to know if they will fit right in without second thoughts.

Focus on understanding

Anyone who hasn’t conducted many hiring interviews, or is at their first company, won’t have an easy time interpreting answers and experiences from someone with another background. There are too many ways to solve the same problem to assume there is a preferred way across all contexts. Discuss the proposed engineering problem with the other engineers, inside and outside the company, to better understand which tradeoffs are the most common and which parts are not clear.

Hiring needs training and preparation

Shadowing a more experienced interviewer is essential to learn how to improve how to ask and answer questions and align on who is the right fit for the company.

What to do and avoid

Don’t ask to implement something the team hasn’t solved only because a book used it as an example. The problem needs to be well understood to recognise a different but valid solution.
Create domain-related problems that every interviewer is comfortable with and assess that they are almost doable within the interview allowed time.
If you plan to conduct a pair-programming session, don’t act like a silent observer, only there to pick up on mistakes, but work with the candidate. It’s ok not to come up with all the correct answers if the reasoning and questions are spot on.
Avoid the technical nit-picky questions that could be checked with a 2 minutes search. What you ask and chat about during the interview should help determine whether working with the candidate will be pleasant.

How to make it efficient

When hiring for any position, define the role’s competencies and create a list of essential and nice to have. Each candidate will have a different mix of them. Ask them to dig deeper into a topic that they like by asking them to explain it in a simple way to judge both their knowledge and communication.

If there is a take-home tech test step in your review process, consider having two people review it, taking notes separately and comparing them afterwards. This will reduce bias towards specific implementations and methodologies.

To ensure review consistency across interviews, create a competency matrix for tech and people skills. Define what you would like to see, why you made this decision, and explain what to expect from each role junior, mid, senior, etc.

Unless you are hiring for a contractor’s role, particular importance has to be given to the ability and will to learn. The tech industry is a fast-moving one, and, albeit the core of what makes good software architecture doesn’t change often, the ways the same approach can be executed will.

Feedback

Sharing feedback after each stage of the interview shows respect and the ability to elaborate on what has been discussed with the interviewee. Take particular care in writing thoughts and observations.

Use these notes to:

Provide helpful feedback that will allow the interviewee better understand their strengths and weaknesses.
Share and discuss how different people answer the same questions and see if anything can be improved.

The feedback should focus on explaining what you liked and didn’t like about the session. Focus on explaining what was hard to understand or not enough of and make sure there is a path for improvement. The interviewee should consider the process helpful and positive, no matter the outcome.

It will take time to hone down the irregularities in your hiring process, but regular catch-ups will quickly normalise it to be more fair and consistent.

Conclusion

Hiring is crucial for every company. I hope this article helped shed some light on how to approach the hiring process efficiently and in a way that shares the company’s culture.

The goal is to hire the right people and leave a good impression regardless of the result.

GraphQL: Publish the Schema of Your Company, Not Your Api

Valerio Francescangeli — Sun, 22 Oct 2023 09:41:41 +0000

GraphQL is an interesting technology that promises better developer and user experience, but its usefulness can be misinterpreted as an overall better technology than what came before it.

To best utilise it, a specific organisation approach must be used. GraphQL works best when the whole organisation shares the same domain conventions. Domain Driven Design shines in a GraphQL environment, but it requires a lot of effort to change a company’s mentality and embrace it.

In this article, I’ll describe how GraphQL differs from a more common REST API approach and how to ensure a successful coexistence or migration.

HTTP REST API

The default way to build a service is over the internet. All languages and libraries understand it well, and its division into different verbs provides solutions for safe, idempotent and cacheable requests.

Let’s take a library API as an example. To add a new book or to publish a new review of a book, a REST API would look like this:

Method	Endpoint	Description
`POST`	“/books”	Create a new book
`POST`	“/books/:id/reviews”	Create a new review

This is fine in a typical CRUD style API, but a GraphQL one can instead leverage the business’ domain naming:

type Mutation {
  publishBook({book info})
  publishReview({review info})
}

Differences between REST and GraphQL

Your schema is your API

This is a significant shift from the way your endpoint will expose data. To ensure a well-structured schema, start from the business problems and produce a cohesive shared understanding of the business. Domain Driven Design is what allows an organisation to create one and use it to define what your schema should look like.

Start by defining your domain events. What events happen in your business that are definable as a step forward? Create as many as you need. Once done, organise them in a timeline and group them by context. Each context will enable consistent use of the same words across all events, even when the same word means something different in a different context.

Some events will require business rules, and those rules will require data from internal or external sources. Define those rules and where the data is coming from. This will result in an action that will generate the new domain event.

This system will help define what structure your schema will have:

Internal resources are GraphQL Queries
External resources live outside of the schema and must be merged, together with the business rules, in the business layer logic
Actions are GraphQL Mutations, ready to be exposed on the schema

Remember that your schema is an ever-evolving system. Embrace it, and don’t be afraid to change it when they improve your customers’ experience.

Common mistake when migrating from REST

Don’t simply move your CRUD verbs. GraphQL’s queries and mutations can use names that make sense to the business, not an API convention.

Consider a typical REST API:

Method	Endpoint	Description
`GET`	“books/”	Get all books
`GET`	“books/:id”	Get a book
`POST`	“books/“	Create a new book
`POST`	“books/:id/review”	Create a new review
`PATCH`	“books/:id/review”	Update a review

A common first step is to use the same style that REST adopts:

type Query {
  getAllBooks()
  getBook({id})
}

type Mutation {
  createBook({book data})
  createReview({bookID}, {review data})
  updateReview({bookID}, {review data})
}

There is no need to stick to REST verbs if it doesn’t make sense from a business perspective. It is better to use more straightforward and more effective names.
Updates are handled differently in GraphQL. Use one big input object instead of dividing it in id and body.

type Query {
  books()
  book({id})
}

type Mutation {
  // include everything in one object, {bookID} should be included inside
  createReview({review data})
  updateReview({review data})
}

Versioning

In REST, new versions are required to clarify in what shape your data will be returned, but it is an anti-pattern in GraphQL. Multiple versions mean multiple schemas, which will get out of hand quickly.
GraphQL’s way of dealing with changes is to add new fields when necessary and tag the old ones as deprecated. There is no drawback in having a lot of fields, as every client will always require only what they need.

Authorisation

There are no particular differences here, but if the plan is to keep both REST and GraphQL endpoint, it is better to move the authorisation logic down into the business layer to consolidate the checks in a single place and allow each endpoint to only care about passing down the correct data.

Query Complexity

The freedom allowed by GraphQL is a double-edged sword. Clients can optimise their queries for their use case, but what they need and ask at once might be onerous on your infrastructure. Load-testing your client’s use cases to verify how many records and how much nesting to allow must be considered when exposing your GraphQL endpoint to the public.

Rate limiting

Rate limiting an API can also be challenging. Consider how each part of your schema respond to an increase of queries and implement a business logic to prevent abuse.

Caching

Contrary to REST, caching in GraphQL doesn’t have a well-defined set of rules, with each client managing its cache. If one or more services rely heavily on caching to be functional, think twice before moving them to GraphQL, as it is a delicate matter even when using best practices.

Client Side Caching

Client side cache, with clients like Apollo, relies on cache deduplication and normalisation to optimise the fetching and re-fetching of data. This system works similarly to an SQL database, leveraging the knowledge of the graph architecture and the information about the query to know what to load and what to skip.

Let’s assume this query:

query GetAllBooks {
  books {
    id
    title
  }
}

That returns this data:

{
  books: [
    {<book1>},
    {<book2>},
    {<book3>},
    {<...>},
  ]
}

By default, the normalisation process will split the data to allow it to be individually cached:

{
  id: 1,
  __typename: "Book",
  title: "Book1",
}

Apollo Client will use the __typename and id to create a unique pair that will use to cache it on the client, in a quick-access data structure, like this:

{
  "Book:1": { id: 1, title: "Book1" },
  "Book:<n>": { id: <n>, title: <title> },
}

Notes on client side caching

It’s important to have a unique identifier; without it, Apollo Client won’t be able to keep track of changes to the object
The library creates an array that references the normalised data to keep the correct ordering in place.

Server Side Caching

Apollo Server supports server side caching. It can be applied to a type or a specific field by proving a maxAge value, which describes the number of seconds the cache will be considered valid.

These are the allowed properties to control the cache:

Name	Description
`maxAge`	Number of seconds the resource will be cached for. Default to 0.
`scope`	Can be PUBLIC or PRIVATE. Use PRIVATE to make a response as specific to a single user Default is PUBLIC.
`inheritMaxAge`	If set to true, it will inherit the maxAge value of its parent. Make sure not to provide maxAge if you plan to use inheritMaxAge.

It is used by using a directive called @cacheControl. The previous query for books could be cached for one day by having a type Book with this value:

type Book @cacheControl(maxAge 86400) {
  id: String!
  title: String!
}

The caveat is that the query as a whole will be valid based on the field with the lowest maxAge value.

type Review {
  id: String!
  book: Book!
}

A few caching rules

Having maxAge set to 0 by default means nothing is cached out of the box. It is easier to start without cache and add it where needed, avoiding unexpected behaviours by caching too early.
If any field inside a query has a smaller maxAge value, the whole result will have that cache value associated with it.
If any field inside a query is set to PRIVATE, the whole response will be marked as PRIVATE.

Here, I’ve discussed statically set cache. Note that there is a way to set the cache dynamically. This is only a small introduction to a deep topic.

Conclusion

This article barely scratched what GraphQL can do for an organisation. The simplicity given by being able to organise and find data in the same way it is talked about from the business is a benefit that enables a more cohesive discussion between engineering and product, and it should not be considered an extra but instead seen as the core of it.