I was recently working on some data access/repository code and came across a nice generic repository implemetation for working with EntityFrameworks DataContexts. But when I ran our build through SonarQube, it got itself quite bent out of shape about the following recommendation.

Use the overloading mechanism instead of the optional parameters.

Hmm... Why doesn't SonarQube like optional parameters. They've been a feature of C# since v4.0 and are extremely useful. Consider the following interface.
In the first version, there's a single method definition that allows the consumer pick and choose what variety of parameters to pass.

In the second verion, you need 8 different method overloads to achieve the same.

So why is SonarQube recommending that latter over the former. Well there's a few reasons that may not be obvious. These methods are going to be public facing. They are the surface of your API and will be exposed to the world outside your DLL. In my case, my C# Service's were calling the repository in a different DLL. But not all consumers support Optional Parameters. Java and C++ do not have an equivalent concept available to them. Another reason is that these defaults do not "live" in your DLL per say, but get baked into the call site of the DLL that references them at compile time. So a change in the default values requires the caller application to be recompiled and redeployed rather than just an update of your API library.

Hence why the .NET Frameworks BCL libs all favour Method Overloading over Optional Parameters. But in my case this is internal project code, part of an application stack that gets deployed as a whole.

There's a benefit to brevity in my code and I'd prefer the implementation to be more concise since I having full control of both the API and Caller as well as the deployment process. So Optional Parameters it is.

If on the other hand you're writing public API libs for publishing to nuget or you operate in an environment where partial deployments of libraries and components occur, go with Method Overloading.


After what seems to a year of solid hiring, we're finally coming up for air with a full team. We've had new people join us at pretty much every level in the company from Intern to Senior, across Design, Development, QA & Project Management. And we've seen a pretty significant number of candidates. One thing I've noticed is how oftern candidates will do something silly or ill-considered despite an otherwise good application which damaged their chance.

So, rather than providing yet another list of things you should do to get hired, here instead is a list of things you should avoid doing in order to not screw up your chances.

Do not send me a CV more than 3 pages long

It's not that I don't care. I just do not have time to read a half page of prose on a role you held 6 years ago in the middle of your 9 page CV. I have 60 other resumés to read. Your CV should have at most 2 pages of content appropriately summarised in lists and short paragraphs. Particularly for more senior candidates, who as a function of time, have more career experience to talk about, you need to be capable of summarising your skills and experience as concisely as possible.

Don't ignore the question you were asked / Don't ramble.

I have asked you something very specific. I would like you to answer that question.

  • If you're not sure or don't know the answer, that's fine, we'll work around it or move on
  • If you would like to subsequently segue the conversation into a related topic, great, but answer the question first
  • If you didn't understand the question, ask me to clarify

But don't just go rambling off. And especially don't do it a second time, if I give you the benefit of the doubt and bring you back on topic. If you continue to ramble off then I'm going to assume you have poor communication skills.

Don't submit a broken code test

Do not just knock out a code test, hit RUN in your IDE, think "seems to work on my machine" and then throw it over the fence. I have received tests where:

  • Code doesn't compile
  • Tests don't run
  • Packages don't restore
  • Libraries are missing
  • Or it only runs if you have the latest pre-alpha dev build of some unreleased framework installed on your PC

If you are submitting a code test you need to make sure that the person you send it to can run it. When you're finished I would suggest you do the following check list.

  • Do a clean checkout from your repo and make sure it restores all packages & compiles
  • Compile it from the command line to make sure there are no IDE dependencies or extensions needed
  • Run your unit tests from the command line to make sure they pass
  • Write some deployment/release notes that explain how to compile, install and run your code

Don't come unprepared?

If you've gotten to a face to face interview then you've already passed a CV Screen, Phone Interview and Code Test. So don't trip at the last hurdle by coming to an interview with the intention of winging it.

Bring a copy of your CV with you and know whats in it. If you've put something in your CV, expect me to grill you on it. If I feel like you're bullshitting me, I am going to call you out on it, grill you harder, and tell you it shouldn't be in your CV.

Be capable of explaining what your current/previous roles and projects are in a simple and concise way. If you have worked in an industry that I am unfamiliar with, then you need to be able to get your explanations across to me without having to educate me on industry subject matter. Assume you may have to take an "ELI5" approach.

Review the basics. Yes I know you are a 10-year senior developer and you can write code day-in-day-out. But I still expect you to be able to talk to me about the basics. What are Solid Principles? What is encapsulation? What is polymorphism? Can you name some software design patterns that aren't the Factory or Singleton patterns? Have you reviewed any architectural patterns? etc.


Don't be complacent about getting a new job. Yes, the supply and demand nature of our industry may have tilted things in favour of the candidate of late, but that doesn't mean that good companies will lower the quality bar when they're under pressure. If you want a good job in a good company, then you have to assume that they will have good standards which requires an effort from you, the candidate, to land the role you want.

~Eoin C

A few weeks back the Azure Dublin user group hosted some of the Microsoft and Xamarins team in Dublin for a half day conference. While the Microsoft & Xamarin teams were there to cover some introductory sessions on using Xamarin, they also invited some industry partners to talk about some other technical topics. I presented a quick 15 minute intro on how to use the Azure Notification Hubs platform for sending push notifications to the various platform specific notification services for each of the major mobile platforms.

Azure Notification Hubs is the Microsoft Azure scaled-out infrastructure for doing multi-platform push-notifications. It provides you with a single single hosted platform which you can configure to relay your push notifications to all the major platform specific push notification services.

Currently, Azure Notification Hubs supports sending notifications to

  • Windows Notification Service (WNS) for Windows Phone & Universal Apps on Windows 8 and Window 10
  • The legacy Microsoft Push Notification Service (MPNS) for older Windows Phone 8 apps
  • Apple Push Notification Service (APNS) for Apple Devices such as IPhones and Macs running iOS and OSX
  • Firebase Cloud Messaging (FCM) and Google Cloud Messaging (GCM) for Android devices & chrome apps
  • Baidu Cloud Push for Android in China
  • Amazon Device Messaging (ADM) for Amazon Kindles

Setup can be a little tricky for the respective platforms. In order to configure Google for example, you'll need to login to the Google Developer Console and enable the FireBase/Google Cloud Messaging API, recording your API Key. You'll also need to configure a project under the IAM & Admin Sections and take note of your Project Number which will be used in your source code

Apple's Push Notification Service on the other hand requires that you generate a CSR which is uploaded to the Apple Developer site. That will allow you to create a Certificate which is in turn uploaded to the Azure Notification Hub configuration.

Once you've configured the various platform notification services in Azure, you can start pushing notifications out to various subsets of your user base. Notification Hub clients support connecting with Tag configurations. This allows you to dynamically tag your client base by device, demographic, specific user or some other categorisation and then targets those subsets of users

You'll find some demo code to get you started in our demo repository of Source Code on Github and a copy of the presentation slides from the demostration below

~Eoin C

Xamarin & Azure Notification Hubs from Eoin Campbell

It's no secret that hiring software developers is hard. Plenty of people more qualified than I have written on the subject over the years on just how hard. In Dublin, Ireland especially, the supply and demand economics of the problem are particularly difficult. Dublin is a major IT Hub in Europe, and host to the EMEA Headquarters for some of the largest IT companies (Google, Microsoft, Facebook) in the world. We've got insurance companies, banks and other financial institutions all HQ'd here as well. The demand for good IT staff is significant. And the supply side of the equation is further complicated by the presence of recruitment agencies. When a potential candidate is ready to move job, they are faced with a choice. Do all their own job search leg work? Or send their CV out to a small handful of recruitment agencies and let the interview invites roll in?

So where does that leave a relatively small IT company? Well in a far from ideal position, where hiring is a significant undertaking both in terms of time and money. Below is some background information on how I've conducted interview processes in my last few roles, and some some anecdotal numbers on how that process has been working out recently.

The Process

Our hiring process isn't unique. We try to establish as quickly as possible whether a candidate is suitable for a role without wasting any of their time or ours.

  1. CV Filtering - Are they an appropriate match on paper for the role
  2. Phone/Skype Interview - Keep this brief, 30 minutes, enough to briefly discuss experience, existing role, reasons for moving on, technical experience and some relevant technical questions based on the role their applying for
  3. Code Test - We send candidates a test to complete in their own time. Proposed as a typical user story with requirements, acceptance criteria and DoD. This is a chance for the candidate to show off. Try to deliver a code test that can be given from everyone from graduate to senior developers. While a grad might solve the problem, we expect more from a candidate based on their seniority. Solution architecture, separation of concerns, use of design patterns, decoupled design, use of dependency injection/IOC, code quality, unit testing, integration testing, database migration strategy etc
  4. Face-to-Face Interview - The candidate meets with our team, usually a mixture of management and technical staff for a more involved conversation around experience, previous roles and technical questions

Our Rules

About 10 years ago, I was in my first team lead/people management role where hiring technical staff was part of my remit. I read "Smart & Gets Things Done" by Joel Spolsky. It's a brilliant concise little booklet on how to hire developers and all this time later there's a few things that still stand out for me.

  1. We don't hire maybes - We're a small company. We have a diverse portfolio of software projects for a number of clients across a range of industry verticals. The large majority of our business is bespoke solution development and as a result, the train up time on our projects tends not to be spent on the technology but on the domain knowledge & business problems. We simply cannot afford to hire the wrong people.
  2. We need all rounders - I dislike the term full-stack developers. Like it's some novelty. At the risk of sounding like the dishevelled old man shouting "back in my day...", developers used to be full-stack by default, at the very least, they had some hands on experience across all the layers of a solution. This is no longer the case with a lot of candidates we see; developers and engineers who have been siloed into roles where they only worked on one small sub-system, or one specific layer of the solution. This is compounded further when looking for seniors; we add skills like business analysis, hands on experience doing DevOps, CI & production releases, and experience in customer facing roles and it really can feel like we're looking for Unicorns.
  3. We don't compromise on #1 and #2 when other pressures are present - It's all well and good having rules and principles in our process. So long as they don't get thrown out the window when they don't suit. Circumstances will dictate from time to time that we need to ramp up in resourcing to facilitate a project. This can be tough if the client wants to start tomorrow, and we have a potential 6-8 week lead time to hire.

The Numbers

The following is from a 6 week period during our most recent hiring period. We received a total of 84 applications. 73 from publicly posted job listings and 11 from a recruitment agency. A higher percentage of candidates from the agency got to phone screen.

  • Of those 84 we held phone screens with 35 candidates.
  • Of those 35 candidates, we sent out code tests to 25 of them.
  • Of the 21 code tests we received back, we went back and offered 9 candidates a follow up interview.
  • Of the 7 that accepted and attended the interview, we offered a full time position to 1 person.

That's a signal to noise ratio of slightly over 1%.

Some other observations

Offering a week to complete the code test is a double edged sword. In that time, candidates will continue looking for a role. A number of candidates we provided code tests to just disappeared into the ether after being supplied the test. Similarly, candidates that we've offered a face-to-face interview (or even job offer) are often off-the-market before we get to that point.

A large percentage of our applicants are non-EU residents. We're very happy to supply assistance to them in moving country, applying for VISA's, obtaining work permits, but that does add a significant lead time on (an additional 4-8 weeks typically) on the standard 1-month noticed period we'd expect to be waiting.

Lets assume a resume takes 10 mins to review on average (check content, reply reject/proceed, possibly setup phone screen). A phone screen takes 60 minutes including prep and post-call time (sending out code tests). Code test review and notes by several team members adds another 60 minutes. And a face to face interview including 3-4 team members is at a minimum a 4 hr commitment. By those ballparks we've invested ~100 hours (13 business days) into this one phase of hiring. That's a pretty serious time commitment and nearly doubles the cost associated with hiring when compared against the amount we have to pay out to a recruiter.

The bottom line...

...is that the IT hiring market is particularly challenging for SMEs. Finding talented developers, bringing them through the interview process and getting them in situ, is a significant undertaking. And when you get them, you better do everything you bloody well can to keep them.

After following this path for the past 3 years, we've now hit an impasse. The time and resource cost, lead time for starting and general difficulties with the hiring process for quality full time developers, is now a quantifiable impediment to our business. Without the ability to ramp up on demand, we're faced with either turning down growth-business, or increasing the workload on our existing team. Neither option is particularly palatable. We need to pivot our . Contractor rotation? Near-shoring/Out-sourcing? A change in tack is definitely required.

~Eoin C

If like me you have 2 or more, different Github accounts on the go, then accessing and committing as both on the same machine can be a challenge.
In my case, I have 2 accounts, one for work associated with my company email and a second for my own personal code.

If you'd like to be able to checkout, code and commit against different repo's across different github accounts on the same machine, then you can do so by setting up multiple ssh keys, and having hostname aliases configured in your .ssh config file.

First off all, you'll need to generate your SSH Keys. If you haven't done this already, you can use the following commands to generate your keys.

$ ssh-keygen -t rsa -C "eoin@work.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/eoin/.ssh/id_rsa): id_rsa_eoin_at_work

$ ssh-keygen -t rsa -C "eoin@home.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/eoin/.ssh/id_rsa): id_rsa_eoin_at_home

Once you've created your 2 files, you'll see 2 key pair files (the file you specified and a .pub) in your ~/.ssh directory. You can go ahead and add the respective key files each of your Github accounts. It's in the Github > Settings < SSH and GPG Keys section of your settings. You'll also need to add these files to ssh.

Next you'll want to create an ssh config file in your ~/.ssh directory. You can see mine below.

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_eoin_at_work

Host personal.github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_eoin_at_home

Here's the trick, when you execute a git clone command to clone a repo, the host in that command is not a real DNS hostname. It is the host entry specified on the first line of each section in the above files. So you can very easily change that. Now, if I want to check out work related projects from my work account, I can use.

git clone git@github.com:eoincgreenfinch/heartbeat.git

# don't forget to set your git config to use your work meta data.
git config user.name "eoincgreenfinch"
git config user.email "eoin@work.com" 

But if I want to check out code from my personal account, I can easily modify the clone URI with the following.

git clone git@personal.github.com:eoincampbell/combinatorics.git

# don't forget to set your git config to use your work meta data.
git config user.name "eoincampbell"
git config user.email "eoin@home.com" 

~Eoin Campbell