Lessons learned from my Flutterwave technical assessment result.

Lessons learned from my Flutterwave technical assessment result.

Simple errors in nodejs

·

3 min read

I was invited to write a technical assessment for the Backend(Nodejs) role at Flutterwave on January 27th. This task was to be submitted on the 30th of January, meaning I had three days to complete the task.

I was very ill at the time and wasn't able to put much time into working on the task. A few weeks later, I got my results, which include a detailed result of the actual and expected response of the API.

Out of 20 tests, my API was able to pass 13 meaning it failed 7 and giving me a 65% pass percentage. While going through the tests, I was able to point out two major errors that made the 7 tests fail.

Error one.

The arrangement of the middleware I used on the route.

I had to create two middlewares to help with most of the functionality of the test. The first is the request validator I created to validate the body of the response and the second is a type checker which validates the data type of the request body. In a hurry to submit my task, I didn't pay close attention to the arrangement of the middleware on the route and placed the typechecker before the requestvalidator which had a major effect on the test results. An example is the test below:

Test: Rule is required | ❌
===============
{
  "Test Data": {
    "data": "abc"
  },
  "API Response": {
    "message": "rule should be an object.",
    "status": "error",
    "data": null
  },
  "HTTP Status Code": 400,
  "Request Duration": "1.315 secs",
  "Failed Tests": [
    "message should be 'rule is required.' got 'rule should be an object.' instead"
  ]
}

Solution

I switched the arrangements of the middleware on the route.

// Before 
router.post("/", [ typeValidator, RequestValidator], RuleValidation);

// After
router.post("/", [RequestValidator, typeValidator], RuleValidation);

Error Two.

Checking for non-existence.

While creating my request validator, I had to check for the non-existence of the values in the request body, which I did making use of the not operator(!)

e.g

if(!value){
     return 'value is required'
}

This approach didn't work for a particular value that is expected to be of varying data types including type number. Below is the test and response my API gave:

Test: Array (nested field) - Successful validation | ❌
===============
{
  "Test Data": {
    "rule": {
      "field": "0.age",
      "condition": "gte",
      "condition_value": 0
    },
    "data": [
      {
        "age": 0,
        "ohlms": 45
      },
      2,
      5,
      90
    ]
  },
  "API Response": {
    "message": "rule.condition_value is required.",
    "status": "error",
    "data": null
  },
  "HTTP Status Code": 400,
  "Request Duration": "1.318 secs",
  "Failed Tests": [
    "data is expected to be an object"
  ]
}

The condition_value which currently has a value of zero (0) when passed through the not operator condition will return false as zero evaluates to false.

0 = false

Solution

Instead of using the not operator, I changed the approach by making use of null and undefined.

e.g

// Before

if(!value) {
     return 'value is required'
}

// After

if(value === null || value === undefined) {
     return 'value is required'
}

Acknowledgement

I want to say a big thank you to the Flutterwave team for this technical assessment and the quick and detailed feedback, especially to Mr. Ayodeji Akanji, Senior Engineer ‑ Back End at Flutterwave, I am very grateful for your quick response sir.

Conclusion

Making simple errors are very possible when writing a timed task, hence we have to be cautious not to make these mistakes.

The result from Flutterwave.

My code on Glitch (Includes the task in the readme file and the solution)=>


I would love to know what you think in the comment section below.