Cracking the Laravel Interview: coding assignment

What to do and what not to do when coding an interview assignment for a Laravel job position.

Entity-Relationship Model

Most projects start with database tables and eloquent models. To be able to visualize an entity-relationship model, you should have carefully read the whole assignment. Your database structure is key, and starting with an incorrect structure will add a big refactor penalty at a later stage.

Now it’s time to create your migrations and models.

Tip: php artisan make:model Post -m -f will create the Model, the migration, and a factory.

When creating migrations, ask yourself the following questions:

• Do the migrations have foreign keys?
• Are datetime fields suffixed with _at ? And are boolean fields prefixed with is_ ?
• For the nullable fields, does it make sense in terms of business logic for it to be null?
• Are timestamps included? What about soft-deletes? Or is there a valid reason not to use soft-deletes?
• Are the tables normalized? If not, should they be?
• Do unique constraints reflect the business logic? (For example, a one-to-one relationship should have a unique foreign key constraint)

And for the models:

• Are all relationships defined? Back and forth?
• Are attributes, such as booleans and dates, correctly being typecast?
• Are there any fillable attributes? Relationship foreign keys shouldn’t be fillable.

Separate concerns

Whether you’re making a CLI, REST API, or a full CRUD website, you should always know how to separate concerns.

For example, if what you need to build is a RESTful API, make sure you:

• Use REST naming conventions for paths, route names, and controllers;
• Consider using Route model bindings to make controllers more readable;
• Use single-action controllers when needed;
• Create form requests when validating the user input; and,
• Transform the JSON using API resources.

Whether you use Services to execute business logic or Actions, you should be prepared to justify your choice.

The QueryBuilder is your friend

A raw SQL query will only show to the interviewer that you are not that comfortable with Laravel’s query builder. Stay away from raw queries whenever possible.

Avoid Joins

When using Eloquent, join-clauses can add more selected properties to your model that bloat the dataset. This makes the query hard to reuse, which is why you should always use ->with() instead.

Use aggregates

If you only need to know how many rows a certain query has, don’t perform it using ->get(), use ->count() instead.

count($query->get()) // Bad
$query->count()      // Good

$query->count() > 0  // Bad
$query->exists()     // Good

Use scopes

When writing queries that map to semantic concepts, consider using scopes to wrap one or more constraints into a readable statement.

->whereVisible()

// is more readable and reusable than:

->whereNotNull('approved_at')
->whereNull('archived_at')

Aggregate relationships

When normalizing the database, you will have to make a decision: do you add an aggregated column comment_count and increment/decrement it every time a comment gets added/removed, or query the count on every request? Luckily, Laravel’s query builder allows you to easily aggregate relationships.
Showing that you care about database normalization and that you know how to easily make the queries to fetch them will prove your skills.

Collections

Developers should know the difference between foreach, map, and reduce.

You should take a look at all available collection methods, and don’t be afraid to use multiple at once, like in the below example:

// Bad
$sum = 0;

foreach($products as $product) {
    if ($product->isArchived()) {
        $sum += $product->stock;
    }
}

return $sum;

// Good

return $products
    ->filter->isArchived()
    ->sum('stock')

If you want to learn more about collections, check out Adam Wathan’s Refactoring to Collections.

Testing

Either they explicitly say it or not, you must write tests.

I personally don’t think that 100% coverage is required, but at least you should show the basics of it.

Important: remember to assert the affected data. Code coverage is not the most important metric of tests; assertions are. It shows you know the importance of tests and that you understand how code can evolve and break.

Closing notes

Be familiar with your code

Depending on the interview process, you will likely be asked to explain your code and to add more features to it as part of the live coding interview.

What every interviewer wants to see is you being comfortable with your solution. This is your code we’re talking about, you should be able to navigate through it.

Justify your decisions

Did you use the repository pattern, or did you use Eloquent’s scopes instead? Make sure you have the justifications for either choice and can explain the pros/cons.

Know the next steps

Maybe your queries are not fully optimized when delivering the assignment, but it might be handy to know the possible indices that would improve them, or to structure a cache plan to make subsequent requests faster.