linkedin Skip to Main Content
Just announced: We now support interviewing in spreadsheets!
Back to blog

2 Interview Questions to Assess Your Next Intermediate Backend Engineer

Interviewing

Technical interview sessions often risk becoming routine exercises rather than meaningful evaluations. This issue is particularly critical when interviewing intermediate backend software engineers, as mundane or inappropriate questions can lead to a lack of engagement and a failure to accurately assess their more advanced skill set.

For intermediate roles, the interview questions need to be carefully calibrated. They should be challenging enough to test their deeper understanding of backend systems and architectures, but not so advanced that they are better suited for senior-level engineers. The focus should be on evaluating their proficiency in key backend technologies, their ability to design more complex systems, and their problem-solving approach in more nuanced scenarios.

In this blog post, we will introduce two carefully selected coding interview questions. These questions are specifically crafted for intermediate backend software engineers, striking a balance between complexity and practicality.

By using these questions, hiring managers and interviewers can gain a deeper insight into the candidate’s technical capabilities and problem-solving methods. More importantly, these questions offer a window into the candidate’s readiness to tackle the challenges typical of an intermediate role and their capacity to grow into more advanced positions within the dynamic landscape of backend development.

✅ The questions below are written with Python and Go/Gin. However, you can easily tailor them to suit your own backend frameworks.

Question 1: Create a family tree API

Add read endpoints to an API and search through the database with Gorm.

Instructions

Part 1

This Family Tree application stores people. Each person is defined by a name, an age, and two parents. To simplify things, the name is a unique text field, there is no “first name” and “last name”.

The parents are two fields which references two other persons. The database contains only one table, which has links to itself. The two parent fields can be null.

The database is already populated with some test data; you currently have only two API endpoints to access this data:

  • /persons/ will give you all the data from the table.
  • /persons/:id (where :id is an integer) will give you the data of one person.

For example, a GET request to /persons/5 will return the following JSON:

{
    "CreatedAt": "2023-10-27T18:13:48.645234Z",
    "UpdatedAt": "2023-10-27T18:13:48.645234Z",
    "DeletedAt": null,
    "ID": 5,
    "Name": "Miles Hatsue",
    "Age": 53,
    "Parent1ID": 2,
    "Parent1": null,
    "Parent2ID": 3,
    "Parent2": null
}Code language: JSON / JSON with Comments (json)

Your first task is to modify the endpoint `/persons/:id` to make it output only the useful fields: ID, Name, Age, Parent1ID, Parent2ID.

Then, add an endpoint /orphans/, that will output the IDs list of all the persons who have their two fields, Parent1ID and Parent2ID, equal to null.

The request to /orphans/ should output this data: [1, 2, 3, 7, 9, 12, 13, 14, 15, 20, 22].

Part 2

Now, add another endpoint named /grandparents/:id, which will output the list of grandparents of a specific person. Obviously, the maximum size of this list is 4.

For example, the request /grandparents/8 (Grigor Vaughan) should output this data (order is not important):

[
    {
        "ID": 2,
        "Name": "Grozdan Hatsue",
        "Age": 78,
        "Parent1ID": null,
        "Parent2ID": null
    },
    {
        "ID": 3,
        "Name": "Diarmaid Yuuto",
        "Age": 78,
        "Parent1ID": null,
        "Parent2ID": null
    },
    {
        "ID": 1,
        "Name": "Vienna Gesine",
        "Age": 77,
        "Parent1ID": null,
        "Parent2ID": null
    },
]
Code language: JSON / JSON with Comments (json)

Part 3

Modify the base request so that we can also get the monoparentality of a person. A person is considered a monoparent if he/she has at least one child, who has one of his/her parent fields equal to null.

If the query parameter monoparental is set to 1, the request must return the monoparentality.

For example, the request /persons/20?monoparental=1 should output this data:

{
  "data": {
    "ID": 20,
    "Name": "Usha Sólja",
    "Age": 71,
    "Parent1ID": null,
    "Parent2ID": null,
    "Monoparental": true <-- additional field
  }
}Code language: JSON / JSON with Comments (json)

But the request /persons/2?monoparental=1 (Grozdan Hatsue) should output some data with Monoparental equal to false.

Part 4

Add another endpoint sisbro/:id that will return the siblings of a person.

This endpoint accepts two optional query parameters:

  • type:
    • When undefined or set to null, will output the persons whose two parents are the same as the requested person.
    • When set to half, will output the persons with only one parent that is the same as the requested person.
  • age:
    • When set to older, will output only the siblings whose age is strictly higher than the age of the requested person.
    • When defined to younger, will output only the younger siblings.
    • When undefined, will output all the siblings without any filtering on the age.

For example, the request /sisbro/5?age=older should output this data:

{
    "ID": 4,
    "Name": "Apolena Hatsue",
    "Age": 55,
    "Parent1ID": 2,
    "Parent2ID": 3
}Code language: JSON / JSON with Comments (json)

Part 5

There is one big inconsistency in the test data. Something that can not happen in real life. Can you find it? Would you be able to add an endpoint that would return all these sorts of inconsistencies?

Evaluation criteria

1. Which files is the candidate editing, and which are they leaving alone? Are they able to comprehend boilerplate code versus code that needs to be enhanced or fixed?

The candidate may take a quick look at the boilerplate code, just to be sure they corresponds to the standards, but should not spend much time on them.

2. How are they implementing the data processes? The particularity of this exercise is there is only one table (Person), but some parts requires to search data step by step.

An expert candidate should try to build a single database query, containing some joins inside the table Person. A single query optimizes database calls, and execution time. It gets harder and harder to complete the exercise parts with single queries, which may help you evaluate to what extent the candidate is an expert.

3. A knowledgeable candidate should ask the interviewer what is supposed to be done in case of errors: should we output a detailed message? a specific HTTP error code? some examples of expected values?

4. One of the existing function in the code was created only for debugging purpose. The function is a bit dangerous and should not exist in a production context as it may impact performance or lead to data leaks.

A careful candidate should express some concerns about this function, and should remove it or modify it to output paginated data.

Question 2: Sort dates with different format and timezones

There are three lists containing dates with different format (dd/mm/yy, etc) and timezones. Convert everything to UTC, merge in a global list, and sort.

Instructions

In the starter code, you have three lists containing couples of two fields: an identifier and a string defining a date.

The date formats and timezones depend on which list they are in:

  •  In the list “facebooom_events”, the timezone is “UTC”, the format is dd/mm/yy HH:MM AM/PM.
  •  In the list “tastewine_events”, the timezone is “Europe/Paris”, the format is dd/mm/yyyy HH:MM
  •  In the list “vwyz_events”, the timezone is “America/Los_Angeles”, the format is m/d/yyyy HH:MM:SS

You have to merge this data and output a list whose each element is a tuple of three sub-elements:

  •  the string “facebooom”, “tastewine” or “vwyz”, defining the input list
  •  the identifier
  •  a string containing the date, converted to the timezone “UTC”, with the format ISO 8601: yyyy-mm-dd HH:MM:SS

As an example, the first four elements of the output list would be:

    ('facebooom', 4834, '2023-10-27 10:11:00')
    ('tastewine', 4828, '2023-10-27 11:01:00')
    ('tastewine', 3687, '2023-10-28 03:45:00')
    ('vwyz', 730298095, '2023-10-28 09:08:29')Code language: JavaScript (javascript)

The output list must be sorted chronologically.

The timezone “Europe/Paris” is 1 hour ahead of UTC, or 2. It depends on the period in the year (summer time or standard time). The timezone “America/Los_Angeles” is 7 hours behind UTC, or 8. But the transition between summer time and standard time is not made on the same day as “Europe/Paris.”

It’s rather complicated. You should not code these timezone conversions by yourself, but instead use a library of your choice.

All the dates in the input lists are valid and not ambiguous (they are not at the end of daylight saving time). So, you don’t have to handle any exceptions or particular use case.

Evaluation criteria

1. How well does the candidate know their libraries? Data parsing is labor-intensive, and has often already been solved by others in the form of libraries. If the candidate is converting the timezones with their own homemade code then it may show a lack of knowledge about the language they’re using. In this instance, it may be beneficial to remind them that they can use Google or other search applications to find libraries they can use for this task.

2. How does the candidate deal with handling exceptions? The statement explicitly says that the input data is safe and are not ambiguous regarding daylight savings time, so the candidate does not have to handle any exceptions. However, it’s worth asking them how they’d handle exceptions if the input data was not safe.

Some parts of this blog post were written with the assistance of ChatGPT.