Author Archive

How do hiring managers research development candidates?

There are myriad techniques and simple tools to research candidates for development roles. When it comes to hiring and building a great team, there’s no single correct process — naturally, hiring managers each have their own personal preferences and methods. In this post, I’ll define and walk through my personal process for researching candidates for development roles within the LLI team.

How I read a CV

The CV screening process is where I begin reviewing a candidate’s application. Let’s dive into some of the more common items that I’m on the lookout for within a CV. 

When laying eyes on a CV for the first time, I consider a candidate’s experience and list of technologies to be critical parts of the document. In addition to a link to their GitHub (or another similar platform), not much else heavily impacts my first glance at a CV. 

1. Hard skills (and honesty about them)

I speak for many development hiring managers when I say that work experience comes first on my list of priorities. While education and other personal interests are valid information to be included in one’s CV, they don’t contribute anywhere as much to my ultimate feeling and decision about a candidate compared to their experience. 

When analysing hard skills, I scan for any apparent irregularities in a CV. For example, if I have a candidate claiming to know 12 technologies but who has only been in the job market for two years and has held three jobs during that time, there’s clearly some math that doesn’t add up. In cases like this, it’s important to me that I follow up with the candidate about his or her experience in detail during an in-depth interview with them.

It’s also important to me that I dive deep into the projects listed on a candidate’s CV, and if possible, I verify the candidate’s engagement in the project. I once interviewed someone who said that he had been responsible for the entire front end development of a project. However, during the course of asking him a series of questions related to frontend development, it became clear that they were actually one of many developers on the project in question (and unfortunately, in this case, the candidate wasn’t capable of doing the entire thing by himself).

In a nutshell, I want to make sure that people are honest — self-confidence definitely has its place (more on that below), but it’s not helpful for candidates nor hiring managers when work experience is exaggerated.

2. Consistency with other platforms

Hiring managers should always compare the contents of a candidate’s CV with their LinkedIn and/or XING profile. In case of any discrepancies, make a note to ask the candidate about them during the following interview. However, if the discrepancies are significant, they may be grounds for turning down a candidate straight away — to me, all candidates putting a genuine effort into the hiring process are capable of creating an accurate and up-to-date CV. 

3. GitHub profile

I always look development candidates up on GitHub. Just as in the comparison with LinkedIn/XING, check if what GitHub says is in line with the candidate’s CV (and again, take note of any discrepancies). I also check their contributions to open source projects and how many projects they own on the site. (It’s important that they own these projects rather than have forks of someone else’s projects — having no owned projects is never a good sign.) 

Within owned projects on GitHub, I investigate:

  • The project timeline
  • The number of commits they made (and how frequently they made them)
  • The nature of commits (minor problems or serious stuff?) 

Remember that, for NDA/GDPR-related reasons, some projects on GitHub can be hidden. Even so, you can usually see the number and frequency of commits that a candidate has on the site across all sorts of different projects, even if they belong to private or hidden organisations. 

4. Digital footprint

When Googling a candidate, what else shows up? Have they been involved in some valuable extracurricular work or side projects? Opportunities such as coding education initiatives, local meetups or technical volunteering are great experiences to be on the lookout for.

Let’s talk softer skills 

Beyond the CV, it’s important for hiring managers to see each candidate for the unique individual that they are. As hiring managers are searching for someone who will ultimately become an invaluable member of their team, assessing a candidate’s soft skills is another key portion of the hiring process.

Here are a few soft skills that I find to be indicative of a candidate’s fit for a development role:

1. Commitment

When I think of professional commitment, I like to reference a developer I know who went from having 10 years of experience and a PhD in chemistry — yet no formal education in tech — to becoming one of the best developers I’ve had the pleasure of working with. Although she had no previous experience in a tech role, she turned out to be very committed and demonstrated a lot of effort towards achieving her goal of becoming a coder. 

There are plenty of questions that can be raised during an interview to assess a candidate’s commitment to a role. Their style of communication and critical thinking are key soft skills that arise while a candidate responds to these questions.

2. Self-confidence

As mentioned above, self-confidence can have both pros and cons. In the best case scenario, candidates advertise the best and truest version of themselves and their skillset; in the worst case, skills and experience become “over-advertised”. 

In a similar vein to the aforementioned points, self-confidence can be observed and understood during a candidate’s interview. I usually prove or disprove any points of curiosity that I can already see in their CV by further digging into them using targeted questions.

Technology is the key to one’s skill set

To get the most accurate picture of a candidate’s technical skills and seniority level, watch out for their list of known technologies — and take special note of any trivial technologies. While this needs to be considered on a case by case basis, you can consider a candidate to be over-advertising skills if they include third-party services in their skillset (such as Appsignal or Sentry). The reason for such a philosophy is simple: Most of these services can be implemented in a matter of minutes and they are the expertise of a service provider, not the candidate. 

On the contrary, if you see a plain and simplistic list yet a candidate has worked for quite some time in different jobs, it’s possible that a lack of self-confidence or “under advertising” may be causing this seemingly contradictory presentation. If this appears to be the case, it’s very important to ask the candidate to verbally expand upon any points that need further explanation.

3. Passion

Simply put, we want to get people who care and who are constantly willing to learn. In my experience, the best demonstrations of this are one’s side projects and secondary experience (as mentioned earlier on in the post). These activities are often a developer’s greatest way to describe and demonstrate their passion.

In addition to being passionate about technology, a candidate must carry a willingness to try and learn new things. This is a telltale sign that they are curious and that they want to grow.

Building an entire web app with Phoenix LiveView

At the start of this year, I had the pleasure and opportunity of building an entire application using Phoenix LiveView. I did so without writing any JavaScript code (if we can exclude initialising date pickers on some inputs!).

Please note that in this post, I’ll be describing my personal experiences and chosen approaches while using Phoenix LiveView. This isn’t a step-by-step tutorial on how to create a web app in LiveView, and each person who uses the program for similar tasks will undoubtedly take an individual approach to how they work.

This was an exciting task for me, as it was my first contact with LiveView. As I familiarised myself with the new paradigm, I found the app building process to be refreshing, as it presented me with a completely different approach to building certain features.

Not only was this an exciting and pleasant task — building an app in Phoenix LiveView was also surprisingly fast. This is largely because LiveView made it easy to build new features, and coding doesn’t require switching the context between building the backend in Elixir and frontend in JavaScript. Using LiveView, I could simply focus on building the web app as a whole without any differentiation between frontend and backend.

How I approached the project

Developers typically think about the flow of communication between client and server taking the form of a mail-like conversation. That is, each request comes with a response containing the most information that we are allowed to send and that could be important for a specific page. This means that, in practical terms, we’re preloading a lot of data. (This is otherwise known as a stateless web approach.)

The ‘search’ function is bound to every input inside the form ‘change’ event

In LiveView, the communication exchange is more like a dynamic conversation. The client and server are conversing through the WebSocket, dynamically changing the state of a page. Because of this, I didn’t need to think of GET requests, what to preload, and what should be fetched from the server. Instead, I would simply create a function inside the ‘#{page}Live (i.e. ‘Projects.IndexLive’) module and bind the function to the specific element in the browser. In other words, I would be changing the value in a search input placed in a projects index to filter the projects card, keeping only ones that match the search. Thus, the entire connection between my browser and the server is stateful.

Live modules in place of controllers

Generally, I like controllers, especially when they’re well maintained and slim. But I came to like LiveView’s modules a lot more. So how did I efficiently manage them in this case? Inside the “live” folder (for LiveView modules), I created a folder for each resource that I need, just as I would create the controllers for these resources.

Then, inside these folders, I created files for every template that I wanted to use. For example:

  • ‘index_live.ex’
  • ‘show_live.ex’
  • ‘new_live.ex’

Okay, but what about non-GET actions? I simply treated them as events and handled them inside these modules too. So, the ‘create’ action is handled in ‘new_live.ex’ and the ‘update’ action will be handled in ‘edit_live.ex’. This allowed me to nicely encapsulate and compartmentalise the functionality. 

A basic live module for the project index with search functionality

What if my module grows and goes from pretty, clean, and slim to “big and messy” code? I’ve encountered this issue, since my web app had some pretty conditional parts that weren’t the right fit for the context modules. Fortunately, creating the helper module and calling functions from it helped address this issue.

LiveView routers

Normally, Phoenix routers allow you to match HTTP requests to controllers’ actions. It’s quite a similar case in LiveView, but instead of the controller action, it’s matched to the live module and is handled with the ‘mount/3 function.

The insides of a router

In the router, instead of keywords like “get” and “post”, you use “live” and point to the LiveView module. In my opinion, the result looks quite clean, especially when you’re scoping this in a way that maintains proper structure based on contexts.

HeaIntegration with custom JavaScript

As I’ve mentioned above, I didn’t need to write any custom JavaScript for my web app (aside from initialising date pickers); all of the interactions were made with LiveView. That being said, there are some ideas that I have after this experience on how to improve on it — for example, I would probably try to use Vue or Alpine for certain things, like showing modals, and other things needing immediate frontend interactions or changes in DOM. 

Client hooks

I’m currently researching this topic and it looks quite achievable, especially building this around hooks and events. To me, it’s worth it to use custom JavaScript. However, don’t reinvent the wheel if something is easily achievable with plug and play libraries, like Alpine.js.  

In general, I think it’s always best to draw a proper line between what should be done with JavaScript and what should be done with the LiveView. Whichever you choose, sticking with your decision throughout the app building process should help to ensure and maintain consistency.

Takeaways from the app building process

Through the process of building my app, I’ve gathered a few highlights from my experience using LiveView that I think could be useful for other developers seeking to try it out for themselves:

  1. Phoenix LiveView provides a way to build a dynamic and modern website without writing specific JavaScript code just for the sake of dynamicity. 
  2. As I’ve demonstrated through this post, it’s quite easy to start and become productive with LiveView if you’re already familiar with Phoenix.
  3. The benefits of building LiveView components over the separation between API and SPA is significant. Also, the joy and simplicity in which the same developer can address everything in a single language is a massive boon.
  4. Finally, it’s a nice and refreshing task to try to handle common web app challenges with LiveView.

Happy building!

Dark Mode Design Tips

The main advantage of dark themes is their increased readability in low-light environments. Dark mode reduces the luminance emitted while still maintaining proper color contrast. It improves visual ergonomics and appropriately adjusts to specific light conditions

Each of these features make it more pleasant to use technological devices in the evening or late at night. More interestingly, if your device has an OLED or AMOLED screen display, dark mode can significantly increase its battery life.

Because of its many useful benefits, dark mode has become one of the biggest trends in design, and many world-class brands like Apple, Google and Facebook have already implemented dark themes. In support of its growing popularity, we’ve put together a short guide on how to properly create dark mode designs.

Don’t go too dark

Often, the first thing that comes to mind when creating a dark version of a design is too simply change the background to basic black (000000). Although this may seem like a sensical choice, don’t do it — using a pure black background is a common mistake, as the contrast is too stark. It causes readers to squint and can lead to headaches. A very dark shade of grey is a better choice.

Dark Mode

Desaturate colors

Consider making colors less saturated. This is to maximise accessibility — saturated colors don’t pass WCAG’s standard. Highly saturated colors may also cause eye strain and optical vibrations against dark backgrounds.

Two color palletes

They must know, then, that the above-named gentleman whenever he was at leisure (which was We already know that desaturated colors work better for the dark theme. Then again, we all love vivid tones in light interfaces. Therefore, it’s wise to create complementary palettes for both themes.

Accessibility

The dark mode has specific guidelines to make the solution more accessible. The most important rule: the contrast level between the text and background should be at least 15.8:1. This solution increases the readability, even if device surfaces will be lighter.

Communicate depth

They must know, then, that the above-named gentleman whenever he was at leisure (which was As we know, shadows don’t work so well in the dark mode. A better way to communicate hierarchy in a user interface is to play with the brightness — as a surface rises in elevation, it becomes lighter in color.

…and test it!

See how your UI looks in both appearances and ensure that the themes are well constructed. For best results, you should also test dark mode at night and in low-light conditions. Once you’ve tested the functionality, you’re all set to allow users to switch from light to dark mode whenever they want!