Sometimes it would be nice if stuff just worked as advertised!
Arch and Antergos were no good for .Net Core development. I was trying to find an option from the supported list of distributions. I should mention that I am creating VirtualBox installations.
The first obvious choice was Ubuntu which still uses Unity by default. Sorry, but try as I might I just can not get on with Unity as a desktop. After installing Ubuntu Gnome (one of the many great community editions) I was set. And then it broke. No real information it would just show a dialog about a “system crash” and the option to report it. Which I did, several times to no avail. Life’s too short …
So then I downloaded Fedora and installed it and then wondered at the tiny square window on my screen. Full Screen did not work out the box. Tldr; you have to add the kernel headers matching your kernel. Then and only then you will be able to install the VirtualBox Guest Additions. At this point, I rebooted looking forward cracking on only to find I could no longer log into the machine. Every time I entered the credentials the screen would return to the user selection screen of GDM. Life is getting shorter …
Based on Fedora I ruled out RHEL and CentOS as I couldn’t face more disappointment at this stage. So that left openSUSE which I haven’t played with since about 2005! Yet, I did remember that they had created a rolling version called Tumbleweed. So I installed it and after a 10-minute installation sat back and basked in the green glow coming from my screen. Finally, I have a working Linux VM and I followed the online instructions to get .Net installed. I cloned my repo and ran dotnet restore and dotnet run and boom. It broke! openSUSE Tumbleweed does not work for .Net Core due to library conflicts. It should work on the non-rolling version of oepnSUSE if you believe some stories. You will only find this out after a lot of Googling and reading of issue tickets in Github.
So losing the will to live I tried a final time with Ubuntu. Installed it and set up .Net, cloned my repo and a dotnet restore and a dotnet run later and I was up and running. I installed Gnome as Unity was worse than I remember it (RIP Unity anyway). I have spent the last couple of days working with it. It is about as good as working with .Net Core on Linux as I previously described before Arch broke the environment.
This really isn’t a name and shame post of non-Arch Linux distros at all. It is however, showing that a number of the beginner friendly distro’s do not work straight out of the box. Using VirtualBox is one way people first play with Linux and try it out. This stuff should be considered during the testing phases. In talking to a number of other developers they have also suffered the same issues in getting .Net Core to work on anything that Ubuntu on Linux. That’s fine but it should be better advertised. The .Net team need to find a way to better support the fast moving package infrastructure of Linux as well if .Net on Linux is to succeed.
This is the second in a mini-series of posts. In the
previous one, I outlined some thoughts on recruiters from a hiring perspective. This one covers some observation’s from reading lots of candidate CV’s. (I do mean lot’s as well!)
Tip 1 - Quality
“Good developers can write well.” I have read that countless times and always wonder where that comes from. I am constantly surprised by the lack of spell checking and grammar in most of the CV’s I receive. There are a lot of tools out there that can help you prepare your prose. Hemingway app and Grammarly are two that I recommend for most.
I see a number of CV’s that have obviously been copied and pasted onto a recruiter’s template. These recruiter versions always look awful. They obviously do not take any time in ensuring formatting is copied as well. If you are using a recruiter then find out if that is something they will do. If they do, then ask to proofread the recruiter version. It is your career they could hamper with the terrible presentation.
Tip 2 - Quantity
A lot of the CV’s I receive are just too long. I mean, 5 pages long for someone with a 4-year career history. Let’s be honest and say that if I am hiring you I am interested in the most recent roles that you have had. If you worked in a burger restaurant when you were 18 and you are now on you eighth job, it should be referenced and no more.
Your Cv shouldn’t be more than 1 page of career history per 10 years of work with a page for education and personal information.
Tip 3 - No lists
When reading about your previous roles I want to know what you did and how you achieved it. That does not mean you should list every technology stack and acronym out there. It also means that if you tell me that you use Node, I do not need NPM listed as a skill as well. That is implied especially when you go on to describe the amazing products you built with Node. (Replace Node for any stack with peripheral elements such as package managers).
Tip 4 - Be adaptive
You do not need just on CV. You should try and adapt it to the roles that you are applying to. Look at the skills they want. Change the content of your CV to highlight your matching skills and experience.
Tip 5 - Be creative
A CV does not get you a job. Believe it or not your CV only gets you the opportunity to apply for a job. On a desk full of print outs what will make yours stand out? When reading CV after CV what will make me think back to yours over my dinner? Given that we are talking about developers I am shocked there are not some great quirky ways to present a CV.
Tip 6 - Order
The order of your CV is important. Technical experience needs to start on the first page. In fact, the text relating to your current role should not overflow from the first page. Education should go at the end.
Tip 7 - Personal statements & hobbies
Personal statements are pointless. I know that will induce meltdowns in some people but they are of no use to anyone and are just a waste of space on your CV. I read a CV once for a developer that sold him in a glowing light. Four months into his employment, he threw an air conditioning unit at a developer. All because that developer had accidentally unplugged his second monitor. Now I guarantee his CV doesn’t have a Personal Statement outlining the fact that he is bat shit crazy. Personal statements are pointless. If you must have one make it short so there is more room for your real skills and experience.
This also applies to what you do outside of work. If you do something of note that leads to an achievement then mention it in passing at the end. If you “like going for walks, watching films and playing the Xbox” then don’t include this in your CV. To be honest I will not select or reject you on what you do on your own time.
Tip 8 - Include portfolios
Last but not least share your git repo’s or your side project details. Nothing makes selecting candidates easier than being able to look at the code they have developed. The earlier in the process that is the better chance you will have. It doesn’t matter if your home projects are in Elixir but you are applying for a Java role.
Obviously, do not share repo details for an employer’s code base. I have seen this and not only is it not cool but I will let the employer know for legal reasons.
Conclusion
So there are some thoughts about CV’s. I look forward to an improvement in those that I receive in the future.
So I have recently gone through a surprise recruitment round for a Full Stack Web Developer. It was surprising as I was not expecting to be hiring a new developer to replace my new developer less than 3 months in. There you go, no one ever said managing a team was easy.
In the next couple of posts, I want to lay out some observations about the recruiting process. They will cover recruiters and will contain some useful information for prospective candidates.
Recruiters
This post will focus on recruiters, how to tell the better ones from not so good ones and tips on dealing with them. This is all from a hiring perspective.
Let’s get one thing straight, recruiters have targets. It’s become nothing more than a sales job for the vast majority and they could be selling anything. In fact, some should be selling anything other than the candidates’ career.
Tip 1 - Don’t use recruiters
To start with I want to contradict the subject of this post and suggest that you do not even use a recruiter. There are two better approaches; use your network and do it yourself.
If you can hire out of your network with someone that you have worked with before you are winning. You know the developer, you wouldn’t ask them to apply if you didn’t want to work with them again. You would have seen how they operate and the quality of their code. This is by far the easiest route. It also save’s you recruitment fees which you can offer as an onboarding incentive.
If you have no one in your network you would want to hire then you can do the work of a recruiter yourself. There are many great job sites and discussion boards to advertise on. Over the years I have had great results advertising on Hacker News “Who Is Hiring”. There are also many remote working and general purpose IT recruitment sites available.
The negative of using these sites is the amount of time it will take to build a good candidate pool. It requires a manual effort on your part to advertise and liaise with candidates. It also costs in the majority of cases and you have no idea on the return for your money until the end of the process.
Tip 2 - Get recommendations
Do your research. All IT recruiters have great looking websites and are good at marketing. Is it hype or is it backed up with a good reputation?
If this is the first time you are hiring developers or technical staff then reach out to your network. Ask mentors to get recommended recruiter names. Once you have asked a few people you will notice a group of repeating names. These are the recruiters you want to approach first.
Tip 3 - Be clear on you requirements
This may sound odd but you should write down exactly what you want from the recruiter. This involves not only the job description but also the terms you are willing to work to.
Terms vary from recruiter to recruiter. I will not agree to pay more that 16% of first year salary the first time I hire through a recruiter. They will tell you that they will need to get that OK’d by their CFO but I have never had one not agree. I usually get payment terms and rebate terms based on my probation period length as well. This is usually a lot different to their 4-week terms. A recruiter that wants to build a long-term relationship with you will have no issue with any of this.
As far as the job spec goes you need to be clear and firm about the expected skills and experience that you want. They will send people that have different skills and experience and tell you that they would be a good fit. You know what you are looking for both technically and personally. Being bullied into making a hire will not allow your team to succeed.
Tip 4 - Make them work for their money
This sounds harsh but even on the lower terms I outline above the recruiter will make about £8,000 on your hire. Make them supply a good candidate pool. Size and variation within your requirements is sensible. Make them arrange interviews. Make them chase references. Make them do their job.
Conclusion
I do not want to make it sound like I do not like recruiters. I do like some. I like ones that show that they are building communities of developers. I like ones that help developers expand their networks. I like ones that call up every so often to build a long-term relationship with the company and you. That look to hear about the growth of the company and what they can do to help that.
As in with many things not all recruiters are equal.
If you have worked as a developer long enough to be beyond a junior then you should recognise both of the above. They relate to the ongoing care required to maintain a code base. They outline an expected behaviour of good developers. If you read the above links and Google the topics you will be a better developer creating better code.
While implementing a small change in a project today I opted to reuse an existing API for the task at hand. It provided a simple chunk of business logic with a simple method signature.
publicentitygetEntityUsing(tenderId,supplierId);
I coded up my change, fired up my local development environment and watched as a YSoD appeared on my screen. OK, I didn’t pass the right values. Nope, in checking the values I was passing the expected tenderId and the supplierId. 15 minutes later, once I had opened the code that provided the API I found the issue. A Linq query was using the supplierId parameter against the SupplierCompany entities. (The SupplierCompany entity has it’s own Id field.)
_repo.Get<SupplierCompany>(sc=>sc.Id=supplierId);
I trawled back through the commit history. I found that the changed occurred in a refactoring of this service class. The change was correct but the parameter had never been renamed.
This is frustrating and showed the mentality of the original development team. The developer refactoring the code didn’t show any care about the change he was making. The team’s review process was lacking or non-existing. When the developer and their team don’t care enough to review changes then small issues will creep in. Adherence to coding standards will be flouted and as time goes on the small issue build into bigger ones.
As Uncle Bob says “… it’s more than that. Caring for our own code is one thing. Caring for the team’s code is quite another. Teams help each other and clean up after each other. They follow the Boy Scout rule because it’s good for everyone, not just good for themselves.”
So over the last week, a new version of libopenssl-1.0-compat hit Arch’s Aur repo’s and for some, it caused a world of pain. Imagine the horror at Spotify not working!
The image above shows the error message I am referring to. The issue was caused due to an unknown PGP key. Actually, as I will come to in a moment it was two unknown PGP keys.
To understand how the PGP signing works in Arch this article by Allan Mcrae is essential reading. If read it actually gives the answer to the issues. As some people skim read things I will highlight the solution:
If you want to allow the installation of package files from a non-official repository, you need to either disable signature verification (don’t do that…), or trust the packagers signing key. To do this you first need to verify their key ID, which should be well publicized. Then you import it into the pacman keyring using “pacman-key –recv-key ” and signify that you trust the key by locally signing it with your pamcan root key by running “pacman-key --lsign “.</em>
pacman will output the name of the package for which the key is unknown. This allows you to check the value of the validpgpkeys array in the packages pkgbuild file. By following the steps above and replacing <KEYID> with the values in the validpgpkeys array you will authenticate the key. Retrying to install or upgrade the package will now work.
In the case of the libopenssl-1.0-compat library the key for that package was invalid and the key for curl 7.54.0-2 was also invalid. The snippet below fixes both issues:
Welcome to my site and blog. You can find out about me and read my thoughts on code and technology, start-ups and building things.
