JohnoTheCoder, Author at Johno the Coder

How to attack technical tests like a boss

Posted on 7th March 2019 | by JohnoTheCoder | Leave a Comment

I’ve been asked about technical tests more times than I can count, so I thought I would write this article. I feel qualified to do so as I have participated in literally dozens of technical tests throughout my career, and I’ve tested numerous candidates.

So, if you want to know how to attack a technical test as a candidate, this article might help you. Alternatively if you’re looking for how to technical test your candidates, because you’re new to the process, this is also for you!

The ultimate, one way ticket, to unlimited job offers, by bossing your technical tests – listen closely, it’ll blow your mind…

Brace yourselves, this one will change your career and your outlook on life. Nobody will have ever given you such accurate advice, and never will again…

You can’t. The only way to nail technical tests and technical interviews are to actually be exactly as skilled, or maybe more skilled, than your CV implied.

It is absolutely acceptable to not be an expert in everything, in fact, nobody is. That’s why the phrase “Jack of all trades” is completed (in part) by “…master of none”, however the full version being “, is oftentimes better than master of one”.

The point here is understand where you’re at. If you’re an absolute master at a single technology, or someone with a breadth of knowledge across multiple fields, without “mastery”, that’s fine. Being honest about your knowledge and expertise is what you should do, only that way can employers and agents match you correctly.

I’m confident in my ability. How are they going to test me?

This is the specific part I’ve been asked about on several occasions. That fear of the unknown, how are they going to gauge my skill. In all my experience, there are 5 main ways to test a candidate’s technical knowledge, experience, exposure and expertise.

These all have difference advantages, and disadvantages, and all come with different twists; largely based on the (technical) hiring managers, but I will cover them all here.

Many companies will do multiple of the below; or may offer many of testing. To summarise here; the main types of test are

The low level technical question
The whiteboard test
The code test
The high level chat
The takeaway specification

The low level technical question

This is best used when trying to understand that the candidate understands what they are doing, and the technologies they are using. This might include something like

What is the difference between “==” and “===” in PHP?
PHP Developer role, about 5 or 6 years ago

What would the following code do? [insert code sample]
Various developer roles from 2011 onwards

These kinds of questions are where you can unearth true understanding vs conceptual understanding, and depth of experience vs dabbling.

When interviewing low to mid level candidates these kind of questions are perfect to gauge where the candidate sits in terms of exposure, and consequent salary.

Preparation tips: Make sure you know the languages you’re going to be tested on (probably the ones you said you know), and think of as much obscure syntax as you can think you’ve used; especially the bits of that language you hate. For me, in PHP, that’s ternary operators. Not sure why, it’s entirely subjective, and I’m not a fan.

I’ve been on the receiving end of this test probably a dozen times, if not more, particularly in the first 4 years or so of my career.

The Whiteboard Test

The infamous whiteboard test, or a problem solving technical test. This is usually some kind of broad problem provided, with you expected to design and/or explain how you would approach solving the problem.

Usually used in more heavyweight to senior/lead type roles, these questions are handy for understanding the candidate’s ability to solve problems or design solutions rather than their ability to write code.

Show me how you would implement a modular, tenanted system which could allow for bespoke modules, as well as those which were to be redistributed
Technical test for a lead developer role, about 2.5 years ago

There is a stock table. This is a transactional table, so no updates or deletes, only inserts. Stock is moved from one shelf to the other by movements in this table. Design the solution which would tell you how much stock is available at any given time
Technical test for a lead developer role, about 2.5 years ago

Preparation Tip: Think about the problems you’ve solved in the past. You may well have done this several times in the past. Consider the approaches you took, the problems you faced, and understand how that will likely be relevant in this interview. Then prepare how you would articulate those problem solving approaches. Being able to relay your given scenario to your real world experience is always good.

I‘ve been on the receiving end of this one maybe 3 times, mostly when I was sitting between 3 and 5 years experience.

Write some code (on site)

These ones are horrible, usually for 2 simple reasons – you’re given notepad rather than an IDE, and generally speaking Google is forbidden. Which is crazy considering we all know Google is your friend.

I’ve found a couple of variations on this one, and oftentimes this test is in conjunction with either the whiteboard test, the low level test (especially if the task is to find problems or fix bugs).

This particular style of testing can be adapted for any level of developer, and will help to gauge skill and speed, as well as experience (especially if the task is one an experience developer will have solved many times over).

Write a PHP function, in as few lines of possible, to give the entire contents of a specified directory, in infinite depth
Technical test for a developer role, about 5 years ago

Write a PHP function, which will give me the nth number in the Fibonacci sequence
Technical test for a developer role, about 4 years ago

Preparation Tip: There isn’t one for this really, except be as good as you said you are, and get hands on with code as many times as possible before your interview. There are plenty of coding challenges online that can help prepare for this.

In the early part of my career (up to about 4/5 years in) I had this one nearly every interview, so probably half a dozen times or more.

The High Level Chat

More often found in heavyweight, senior, and lead type roles. The high level chat is a great way to understand someone’s expertise and breadth of understanding.

High level chats are fluid ways to have a conversation with a candidate and understand how they solve problems, how they decide what technologies to use, and how well they know their stuff. The interesting part, for interviewer and candidate, of this is the ability to derail the conversation to follow new lines of technical enquiry; which can be very revealing for someone’s true level of skill and experience.

What is your experience with caching mechanisms?
Technical test for PHP Developer role, about a month ago

What do you know about Automation?
Technical test for Senior PHP developer role, about a month ago

These conversations are usually based on questions, which may be based on the company’s tech stack, or your cited experience in your CV.

Preparation Tip: Revisit your CV and reflect on all the projects you’ve said you did. Research the tech stack of your new employer, they’re going to be interested in this stuff specifically.

Since I was about 5 years in, this has become the most common. Almost every process includes it.

The Takeaway Specification

Usually delivered by the agent (if there is one), here is a specification – often delivered via GitHub readme and a repository to be forked. The specification could be anything, but your job will be to hit that specification, usually within a rough timeframe or for a specified time.

The specification can be anything from “deliver a small system to do this” or “here are some details, build X integration with Y system”. It might be 2 hours of work, it might be 4 hours.

Deliver a web page which has a form, that captures X data, and submits it to Y third party endpoint.
Technical test for a PHP Developer role, about 3 years ago

Deliver a versioned API which handles video files
Technical test for a Senior PHP Developer role, about a month ago

Preparation tip: This one really holds the candidate to account to be able to deliver autonomously, like they no doubt said they could. You can’t really prepare for this other than being as capable as you say you are. If you do something maybe a bit controversial, leave a code comment or something to explain what you’re doing, annotating the readme is also fine. Be prepared to go above and beyond.

5 top tips!

So, time for my general advice in preparation for technical tests.

Use the agent. They want to get you placed (it’s how agencies earn their commission) and will want to help you, they may have insight, so ask for it
Be as skilled as your CV suggests, being a mid-weight dev is acceptable, trying to blag a lead’s job when you don’t meet their requirements, is not
Be prepared, if you think your weakness may be obscure syntax or functionality, learn it. If you have loads of experience, spend some time revising your CV, and thinking about projects.
Be genuine and sincere, if you don’t know something, tell them, make note, learn it later. If you’re passionate, let them see it. If you’re experiences, talk about it. Proud of a project? Sing from the rooftops!
Understand the trends in the industry, that’s what people will want to test you on. When IE8 vs Chrome was the major thing, I got asked about it constantly. When Laravel first started booming, that was the major thing people asked me about. Automation is now all the rage, understand it and be ahead of the trend

Simple open source package for Laravel RESTful APIs

Posted on 16th February 2019 | by JohnoTheCoder | Leave a Comment

Hi everyone

In my last post about creating simple search and filtering for Laravel I said I was considering creating a package to encapsulate this functionality.

Well, I got this done a few weeks ago and have now released it onto Composer (Packagist) as kya/laravel-rest

You can find the repository on GitHub here, and the documentation is in the Wiki.

There is space on there for issues and things, of course. So if you have any feature requests do let me know, the current release is v0.1.

I know it’s going to be useful for me, as I’ve used it a couple of times already; I hope it proves to be of some use for you, too.

Speak to you all soon, JTC

Model Search and Filtering in Laravel

Posted on 6th January 2019 | by JohnoTheCoder | 2 Comments

Hi guys, as I have written this functionality a few times at this point, and I have been asked how to do it a couple of times, too. That is Laravel searching and filtering, I am going to develop a simple composer package which I can use to allow users to search and filter Laravel (Eloquent) Models using PHP traits which can be used on Laravel controllers.

Assumptions

I am going to work on the assumption that you are comfortable with basics.

I shall also assume you’re fairly comfortable with the Illuminate HTTP Request object, a Controller, and Eloquent Model.

Concept

So the first thing we want to tackle, as a concept, is that the best way, in my experience, is to start with a query, and then modify it as required. This allows us to optionally do almost anything, but equally allows us to do nothing, and simply return an unfiltered set if we want to.

This point would be true outside of Eloquent too, even if working with vanilla SQL.

Starting Off

To start with you want something like this within your Controller.

public function index(Request $request)
{
    // Of course you can change this if you don't want to select everything
    $query = YourModel::select('*');
}

Now we have the $query object which we can work with as and where we want to.

Filtering Records

Excluding deleted/is deleted, as we’ll cover that later on.

Let’s say you now want to filter results on author_id just to keep things simple.

if(!empty($request->author)){
    $query->where('author_id', '=', $request->author);
}

Of course take into account everything here, you may need to do sanitisation or validation or anything else in there.

Multiple Filters, Save Lines

If you have many fields on which you wish to do this I usually find something like this is better

$fields = ['author_id', 'category_id'];
foreach($fields as $field){
    if(!empty($request->$field)){
        $query->where($field, '=', $request->$field);
    }
}

That example assumes the exposure of your field names, you could always use an associative array so you could do “author” maps to “author_id” and so on, if you were so inclined.

Fluffy Search

Now you might want to do a fluffy search, taking the assumption of posts with content and an author name, and a category name (stored within the model) you could do something like this

if(!empty($request->search)){
  $searchFields = ['title','content','author_name','category_name'];
  $query->where(function($query) use($request, $searchFields){
    $searchWildcard = '%' . $request->search . '%';
    foreach($searchFields as $field){
      $query->orWhere($field, 'LIKE', $searchWildcard);
    }
  })
}

Handling Trash

You probably want something which allows you to see soft deleted models, if you’re using them. I do something like this

if($request->trash == true){
    // Retrieve soft deleted models only, you can only do this if you're using soft deletion on this model
    $query->onlyTrashed();
}

Ordering and Limiting

Now to handle ordering and pagination – which Eloquent beautifully does for us, all we need to do is let the user modify it if they want to.

// Set the query ordering
$query->order($request->orderBy ?? 'updated_at', $request->order ?? 'DESC');

$perPage = $request->per_page ?? 25;

// It is a good idea to make sure we cap this
if($perPage > $maximumPerPage){
    $perPage = $maximumPerPage;
}

// Final part - get the results
$results = $query->paginate($perPage);

// You will now need to do something with your results, and return some kind of Response - this could be a JSON response or adding the results to the data returned to the view, depending on your context

There’s an assumption here that our default order is updated at, last updated first, and that if not specified, we want to return 25 pages.

Of course you can store this information wherever you want.

In Summary, and Further Reading

Rather than creating a really complicated set of rules to handle all the things you may need from your API calls, start with a query, and then optionally modify that query.

An introduction to Checksums

Posted on 29th December 2018 | by JohnoTheCoder | Leave a Comment

Hi everyone

This is a quick introduction into checksums, and practically how to use them, at the request of someone through the Ask Johno section of the blog.

I know what a checksum is, but I’m not sure how to implement or use one (in PHP) to achieve what I need.
Anonymous Asker

They go on to explain what they are trying to achieve, which is essentially to verify a file hasn’t changed (in this case it’s the HTTP document sent by an API) before doing something.

Firstly, a checksum is a very small data snippet (datum) which represents something larger.

In my experience there are 2 main reasons to use one, these are;

To verify a change in something larger
To verify that a piece of data matches from that which was sent by its originator (checksum on an API payload)

I will very briefly cover both of these with PHP examples.

Note; I am using MD5 for simplicity, but depending on your requirements this likely won’t be the best option for your use case.

Edit: Please see Further Reading at the bottom of this article for more information about hashing

Using a Checksum to Detect Changes

Now I don’t know what we’ve got, but whatever it is; we are going to need a string representation, 2 main ways of getting this:

$stringRepresentation = serialize($myThingToCheck);

$stringRepresentation = json_encode($myThingToCheck);

Personally, I would advise PHP’s serialize because that will work with, and instantiate objects. However, the choice is yours depending on your use case, JSON is smaller than a PHP serialization.

Now that we have a string, we need to make it small and easy to check. Something like this will work fine;

$checksum = md5($stringRepresentation);

Now to check for changes, we just need the last checksum that we stored that something happened on.

if($checksum != $oldChecksum){
    echo 'Something has changed';
}

So that covers how to use a checksum to detect changes in pieces of data, which is useful if you’re having to poll for changes.

Using a Checksum to Verify Validity

This is something I’ve noticed a couple of times, particularly when working in the financial industry, and around certain payment gateways.

It usually looks something like this; but it does change per API integration so be aware of that and follow their own documentation.

$secret = 'my_secret_api_key';

$payload = [
    'foo' => 'Bar',
    'another' => 'Thing',
    'datetime' => '2018-12-25 00:00:00'
];

$jsonPayload = json_encode($payload);

$checksum = md5($jsonPayload . $secret);

$payload['checksum'] = $checksum;

// Do the rest of your stuff here, including sending the payload etc.

One advantage of this approach is that you never expose the API key in plain text.

If you were to want to verify on the API so that you’re the provider, rather than integration, you would simply do these steps in the opposite order, so it would look something like this

// Assuming you've done everything you need, and now have the $payload array/object back

$secret = 'the_secret_youre_expecting';

$checksumProvided = $payload['checksum'];
unset($payload['checksum'];
$checksum = md5(json_encode($payload) . $secret);

if($checksum != $checksumProvided){
    // If the checksums don't match, in theory the secret key provided was incorrect
}

I think that about covers this topic, as a brief introduction to checksums, and how they’re often used in PHP.

What is a memory leak? A quick analogy

Posted on 23rd December 2018 | by JohnoTheCoder | 1 Comment

This is something that came up in conversation, some friends and I were discussing deploying code, that runs in the background, to production environments.

One of the things I raised was what can happen with daemon processes, should you have a very small inefficiency, given enough time to run (usually by the time it gets to production) it can, and will, destroy live servers.

I then realised that, at this point in the conversation, a description of what a memory leak is, had become an appropriate thing to explain.

Anybody who knows me, knows I love an analogy; so this is the analogy I gave, to give a really simple explanation as to what a memory leak is:

Every morning, you go to a fast food drive through.
You order a meal, eat it, and throw the paper bag with some leftovers into the passenger footwell.
At the end of the day, you arrive at home. You pick up the bag of rubbish, and put it into your bin. Without realising it, you drop a single french fry in the car.
In development and testing you run this same process 50 times, dropping a single french fry each time. The fries are not visible, they’re under the passenger seat, or with the momentum of the car have ended up in the back.
When you go live, the process runs more frequently, and instead of a single meal you’re buying 10 at a time.
Very quickly, those single french fries culminate in an unusable car, because you can’t fit in a Honda Civic if it has 1,000,000 festering french fries inside.
Matt “Johno the Coder” Johnson, on a cold winter morning

So there it is, a quick explanation of what a memory leak is, in an easy to understand analogy.

I’ve been asked to do walk throughs on practical implementations on daemons and a few other topics, so I am going to write those up soon.

Practically, what might it look like?

Imagine your daemon script looks something like this…

// Store the jobs that have been processed
$jobsProcessed = [];

// This is a daemon script, it needs to run, forever
while(true){

    // This is just for demonstration purposes!
    $job = getNewJob();

    // Do whatever you need to, to handle the job

    // Let's store the job we've processed
    $jobsProcessed[] = $job;

}

This all looks fairly innocent right. In testing there are probably, at tops, a few thousand test jobs. In production, when this is running forever, that very small array, can become very big. That’s the bit that could cause a server to topple.

For reference, if you do need to keep this information, store it somewhere, anywhere, else. A log file is usually a good shout (as long as you’re periodically cleaning out your log files), perhaps a database (I’d recommend a MyISAM table for this, as you’re dumping a whole load of plain text data). If you keep this information in a variable in your script, it’ll hold in memory, which is exactly where you don’t want it.

So there it is, a quick and easy analogy, with an (overly) simplified example of what it might look like.

Author: JohnoTheCoder