DEV Community: Luke Glazebrook

5 Top Tips For Crushing Programming Interviews

Luke Glazebrook — Wed, 02 Dec 2020 14:51:38 +0000

🐦 Would you rather view this content in Tweet-sized bites? Check out my Programming Interview Tips Thread.

Technical interviews are typically the final and most challenging stage of most developer hiring processes. You don't know what to expect - who is going to interview you? What is the challenge? How much time are you going to have?

So, with all of these unknowns, how can you give yourself the best chance of impressing?

Here are my top five tips for crushing the technical interview!

💬 Verbalise

Whatever you're thinking, the questions you're asking yourself - speak them out loud. This will give the interviewer an insight into your thought process and showcase the steps you're taking to solve the problem.

⚙️ Form Follows Function

Your main objective in a programming interview should always to be to complete the task or get as close to completion as you can. Because of this, you shouldn't let your inner perfectionist hamper your progress by worrying about trivial details.

You can always re-visit these minor details if you find yourself with excess time at the end of the interview.

🔭 Clarify Before Starting

If you don't feel confident you know what is being asked of you, you're setting yourself up for confusion and frustration.

This unneeded anxiety can be avoided by ensuring you have a good understanding of the challenge before you start writing/typing.

👨‍💻 Be Personable

Given the nerves and pressure of being in an interview scenario, this can be tough. But always try and approach the exercise as you would when pair programming with a friend or colleague.

This can be a great time to show your personality and give the interviewer an example of what it would be like to work with you in the future.

📝 Pseudo Code Is Your Friend

If you get stuck on a specific part of the challenge then implement your existing idea in pseudo-code and move on. You can always come back to it later and, this way, you can unblock yourself to continue the rest of the challenge.

This approach is also effective because it affords you additional time to think about alternative approaches to the tough problem in the background.

Best of luck!

🐦 Follow me on Twitter @LukeHGlazebrook

5 Tips for Getting Started with Open Source Development

Luke Glazebrook — Thu, 31 Oct 2019 16:39:36 +0000

Contributing to open source can be an enjoyable and fulfilling way to spend your time. However, if you've not contributed before it can be daunting - in this article I am going to cover some things that did help or would have helped me get over that initial hurdle.

Start small.

You probably already have an idea in mind about what project(s) you would like to contribute to. If not, think about what libraries, frameworks, applications, etc you use frequently and excite you.

One problem I had before I started contributing properly to open source was I was only really keeping an eye on the issues for huge projects I was interested in such as React.

Whilst it is possible to jump straight in on a large project I would not personally recommend it. At the time of writing, React has 654 open issues, 234 open pull requests and 1,341 contributors. Contributing to such a large project early doors could prove to be an overwhelming experience.

Instead, find a smaller scale project that you find interesting so you can get your feet off the ground.

For me, because I do a lot of work with React and have an interest in accessible technology, I decided to contribute to Reach UI. At the time of writing, Reach UI currently has 46 open issues and 11 open pull requests, so enough issues/pull requests to get involved, but not so many you feel overwhelmed by it.

Whatever project you choose, a great starting point is to check out whether they have any labels set up for people who are new to the project. Typically the label is called something along the lines of 'good first issue' or 'beginner friendly'.

Contributing is more than just code.

There are a whole host of ways you can contribute to projects.

You can:

Contribute code by fixing a bug or adding a requested feature.
Improve documentation by fixing mistakes, increasing clarity and providing examples.
Help by reporting issues you've experienced.
Provide an additional set of eyes on pull requests by leaving a review.
Increase the project's test coverage.
Help maintain or provide TypeScript types.
Many more!

As you can see from the above, there are a lot of ways to get involved in a project and every contribution you can make is valuable. Don't worry about opening up a small pull request with a few documentation adjustments for example, maintainers are usually very grateful and the readers of that documentation will be too!

Follow contribution guidelines.

Most open source libraries contain a CONTRIBUTING.md file in their repository. This file outlines how to go about contributing, things to take into consideration and, occasionally, rules to follow.

It is always worth your time to take a look through this documentation in advance and familiarise yourself with it.

It's best to be in the know from the very beginning.

Follow good contribution etiquette.

Open source work is, by its nature, highly collaborative and, as such, it's important to follow good etiquette and be as helpful as possible.

A lot of projects include a CODE_OF_CONDUCT.md file which is always a good place to start. Familiarise yourself with this before making any changes. If the project you want to contribute to doesn't have one then just follow the age-old rule: treat others how you would want to be treated yourself.

As well as following any code of conduct you should also take the time required to fill in any issue or pull request templates set up by the maintainer(s) of the project. Your issue or pull request is likely to be addressed sooner if you provide all of the information requested.

Always be on the lookout.

Since I enjoy contributing to open source, I am always on the lookout for things to fix or changes to make. For example, if you're looking at a new library and notice that the documentation is missing an important example or contains a spelling/grammar mistake - go in and fix it, the maintainer will appreciate it!

Similarly, as you continue to use various frameworks and libraries in your projects - if you spot any improvements that could be made or issues that arise then go and report/fix them.

Conclusion.

Contributing to open source is a very rewarding experience once you get over that initial hurdle of not know where to get started. Hopefully this article has given you some thought points and actionable steps to take.

Have any tips or ideas that I've missed out? I would love to hear them.

Consistent commits using Commitlint

Luke Glazebrook — Tue, 30 Apr 2019 17:25:31 +0000

The hardest part of version control is representing the history of your project in a way that is meaningful and easy to digest for future readers.

Authoring commit messages is as much an art as it is a science. The thought and time that goes into ensuring code quality and standards are upheld should also be put into version control standards. You should be able to read back through the commit log and have a good idea of what has changed over time.

If you cannot derive any meaning from your version control log then the history itself is meaningless.

When working on JavaScript/TypeScript code you often have a linter working alongside you to nudge you in the right direction. Following linting rules doesn't in any way ensure you're writing good quality, readable, bug-free code but it does definitely help you think about these things and nudge you in the right direction as you're working away.

What if you could employ the same concept of linting code but for git history?

The good news is, you can. Introducing commitlint, a simple way to enforce some standards across your VCS history.

But wait, what does this actually look like? What is an example of a commit that would pass the recommended ruleset?

One of the core concepts behind commitlint is adding "types" to your commmit messages. Your next question is probably, what does that look like?

docs: add contributing.md file
test: ensure hamburger menu is hidden on mobile
style: make Header component yellow by default

In the above cases, docs, test and style are the "types". They're present to give you a little bit more information about what is contained in the PR but in a consistent way.

If you want to see a list of all of the available "types" then check out the commitlint Github page.

Some other niceties you can enforce using commitlint are things like whether the subject can be empty, whether it should have a full stop at the end of the line, what case the subject should be in, etc.

It is worth mentioning that, just like code linting, commit linting alone isn't a silver bullet. It is not the only thing you need to give you and your team nice, readable, history. You could still have plenty of commits that follow the standards perfectly and look like this:

feat: add big feature
style: improve styling
docs: explain more stuff

However, like we mentioned earlier - having a linter is a great way to nudge yourself (and your colleagues) in the right direction and invoke more thought about how we should write our project history.

So far I've worked with commitlint in some personal projects and a couple of OSS projects and I've really enjoyed it. I would recommend checking it out if you're interested in adding some consistency to your history.

Thanks for reading! If you have any questions about anything I've spoken about in this article then feel free to tweet me @LukeHGlazebrook

Gatsby + Linaria = 💜

Luke Glazebrook — Wed, 13 Mar 2019 23:41:27 +0000

I recently went through the process of re-building my personal blog/site. My old site contained a couple more pages (“home” and “contact”) but I didn’t really feel like they added much to the experience. They were very content-light and, in the end, added unneeded complexity to the site.

That old site was built in Gatsby and I have had a good experience with all
three versions of Gatsby released to this point so it seemed like the obvious choice.

I also stuck with the same CSS-in-JS library that I was using on my old website, emotion. Again, it seemed like a fairly straightforward
choice since I didn’t have any issues with it last time and emotion is a
library that I have used a multitude of times during my work since then.

Now, you may be wondering where linaria fits into this because, at this point, it will seem like all was going well. That’s true, it was going well - I had pretty much finished my site and was looking through my Github when I rediscovered linaria after hearing about it on Twitter some weeks ago. My only issue with emotion at this time was I was experiencing some small (and not overly noticeable) performance issues when loading new pages on the dark theme. The web page, only for a few frames, would render in the light mode until it had time to parse the styles. Whilst this wasn't a huge deal the perfectionist in me wasn't pleased and had to do something about it.

I had been meaning to try linaria in a project and, because the API for styled React components is very similar to that of emotion, I decided to give it a shot. Getting linaria installed and set up in a Gatsby project is fairly straightforward thanks to gatsby-plugin-linaria so I created a new branch and cracked on with the refactor.

In my case the setup wasn’t quite as straightforward as it could be based on a compatibility issue with gatsby-plugin-typescript. The maintainer of gatsby-plugin-linaria (as of writing) is trying to find a solution to the problem.

One thing that really appealed to me about linaria is the fact that all of the styles are processed at build-time rather than runtime. This makes a lot of sense when you put that build-time style generation alongside Gatsby’s brilliant built-in SSR (server side rendering). Why parse your styles at runtime when you can extract them during build?

So, how difficult was it to migrate?

I expected the migration to be easy because of the almost identical API but it turned out to be even easier than I expected. In the majority of cases on my new site the migration looked a little bit like this (I'm not joking!):

import styled from '@emotion/styled'; // Delete this line
import { styled } from 'linaria/react'; // Add this line

I will add a little disclaimer here to say that your mileage may vary but, in my case, the vast majority of components didn’t require any changes going from emotion to linaria.

There currently aren’t any codemods available to automate this switch but
there is an open Github issue discussing the possibility of creating some in the future.

Can’t you achieve build time extraction with Emotion or Styled Components?

This is something you used to be able to do in both styled-components and emotion but the teams behind both libraries have expressed that they would like to move away from static extraction and stop supporting it in their libraries. In the threads I can find on Github/Reddit the advice from them is “Use Linaria” 😁

After reading discussion and documentation online it seems the teams behind both libraries would like to move away from static extraction. extractStatic from emotion has been deprecated with version 10 and there is no aim of supporting it in styled components.

The advice from the teams behind both of these very popular libraries seems to be to just use linaria if you want static extraction! 😁

Conclusion

Overall, I am very pleased that I decided to give linaria a shot. The project was really straightforward to get started with and the migration was even more seamless than I expected.

I think if you’re going to create a static site using Gatsby and you like
CSS-in-JS then it could be the perfect solution for you.

If you would like to ask me any questions about anything I’ve spoken about in this article than feel free to DM me or Tweet at me: @LukeHGlazebrook

Also if you would like to see linaria in action then check out my website @ https://glazebrook.dev