If you hadn't guessed I struggled a bit with the title of the issue this week! Anyway, we have been hiring again at work which means I have been conducting a lot of technical interviews this week.
The number of times I have been interviewer greatly outnumbers the amount times I have been interviewee. I have lost count of the number of technical interviews I have conducted over the years, but I imagine it must be approaching at least 30 if not more.
Compare that to the 4 technical interviews I have had for jobs I have applied for, and you can see I am definitely more comfortable being on the other side of the table.
I think this ratio of being interviewer to interviewee is quite common for senior engineers, especially if you have worked at growing companies.
It might also explain why some technical interviews are more stressful than others. The interviewer has forgotten what it is like to be the interviewee and how much ability you can really demonstrate while under stress.
I still acutely remember all the technical interviews I have done and how stressed I was during them. There is one common characteristic however between the job offers I accepted and the ones I turned down (or failed the interview for) and that is how I felt during the interview.
For the ones I accepted, I actually enjoyed the interview process and liked the people who were interviewing me.
I think interviewers can forget that they are also being interviewed by the candidate and if you come across as rude, overly harsh or condescending then it may represent what it would be like working with you.
I always try to be the interviewer that I would have liked to have if I was interviewing for this job.
Which brings me on to the technical interview process itself and which interviewing techniques particularly annoy me. If you are ever in the position of designing an interview process, take note.
Live coding exercise #
Programming is predominately a solo endeavour and to be honest that is one of the reasons I like it so much. I do my best work when I am by myself and I have the necessary room to think. Not all software developers are like this, but I think it is true for many us.
This is why getting someone to program anything with an audience is an unrealistic exercise. It is rare beyond pair programming that you will ever need to program with an audience. If programming while your boss is looking over your shoulder is going to be expected, then I am not going to want the job anyway.
When asked to do a live coding exercise, I am pretty sure my ability reduces to 10% of what it would be normally. That is before you take into account the stress I am already under being in an interview environment.
It is no wonder that many programmers do poorly on these coding exercises.
LeetCode #
I have only ever done a few LeetCode exercises or something equivalent. None of these exercises have ever been any use in real life programming.
Unless you are working for Google or Facebook, where possibly you might need to come up with new algorithms for solving problems, it is unlikely that they are that realistic.
An interview is supposed to test your ability to do the job that you are applying for not your ability to complete LeetCode exercises.
Similar to the above, if I am asked to code while under a ridiculous time limit, I am going to assume that you set ridiculous deadlines in your projects as well, and I should avoid the company at all costs.
Syntax related questions #
I am fine with technical questions asking how you would solve a problem or explaining how something works.
However, when these questions are syntax related it is a big no from me. I am not going to be programming in Notepad, and even if I was, the compiler will still tell me exactly what is wrong with the code.
I generally switch between a number of different programming and markup languages during my work day (C#, TypeScript, JavaScript, SQL, Terraform). If I don't know the syntax for something I will just look it up.
Take-Home Coding Projects #
I am on the fence with this one. I have used these technical coding exercises before in the interview process, and they do have some merit, but they also have a lot of drawbacks as well.
They take up a huge amount of time for the candidate. I remember spending whole weekends putting together projects for jobs I applied to. If you apply for several jobs at once then it can be impossible to get them all done.
The other issue is you can't be 100% sure that it is in fact the candidates work. If you have been doing the same exercise for a while there will be solutions by others on GitHub they could copy. Now with all the AI tools available to us, most of it could just be generated.
Any project that you can finish over a weekend probably isn't going to go into enough depth to really showcase a candidates abilities. It can be good for junior developers but for mid-level to senior developers you can gain a lot more about their experience by talking to them than you can from a mini project.
Good techniques #
So with all of the above off the table, what do I recommend for technical interviews?
- Technical questions — Pick technical questions around how you would solve a problem or how something works without the candidate having to remember particular function names or syntax. I particularly like to base these around their own experience they have talked about if I can.
- Code review exercise — Writing code in an interview is stressful but looking at another piece of code isn't quite so bad. You can tell a lot about a candidate's knowledge by what they pick out looking at another piece of code. Plus this is actually something they will need to do on the job too.
- System design exercise — This is usually for mid to senior candidates, but it is good to see how they would put together a system. They might not have practical experience of building a system from scratch, but they should at least have some knowledge about how it should work. This typically covers things like APIs, queues, databases and various scaling techniques. It is more of a conversation and gives the candidate chance to show what they know.
- Problem solving questions — A controversial choice I know. I would only ask these to junior developers that have very little to no programming experience that you are looking to train. Programming is about solving problems, so you need some way of evaluating this. I still remember the ones I was asked for my first programming job. They were quite fun and didn't have concrete answers, but it was more about the thought processes involved.
❤️ Picks of the Week #
📝 Article — A personal website is a bit like a quilt — I like a good analogy, and it is true that every personal website is unique and allows the creator to express themselves.
📝 Article — A New Era of Writing Code — LLMs are a huge time saver for software developers. I do find myself using them more for solving errors or writing boilerplate code. I wouldn't use it to create a whole project, you still need to understand what is being generated, but it can save time. For example, if you need to write an interface for an API you can give it the JSON and ask it to create the interface for you.
📝 Article — What I tell people new to on-call — I am not a fan of on-call, but it is necessary for software that is running 24/7. It is generally palatable if you have a large enough team to have a good rota and anyone on call gets paid overtime.
🛠️ Tool — OpenFreeMap — A free way to display maps on your website, and it is open source so you can host it yourself too.
💻 Code — Winamp Legacy player source code — I used Winamp a lot in my teenage years to listen to music. You can't do much with this code given the licensing, but it is interesting to see how it is built.
📝 Article — Google Cache is fully dead — Yet another product that Google is doing a rug pull on. I am not sure if I will ever trust a Google product to stay around. I also discovered this week that Google is also removing the whiteboard from Google Meet. I only discovered this after my team was able to successfully use it once. Thanks Google!
📝 Article — Metric-Less Success — “When you were born, you cried and the world rejoiced. Live your life so that when you die, the world cries, and you rejoice.” There is some good advice in this article. Success is generally measured by how much money you make, however no one is going to mourn your passing based on your bank balance.
💥 Comic — Late Cenozoic — This made me laugh. I always like a good XKCD.
🎧 Podcast — When and how to start coding with kids — To be honest I haven't listened to this yet but putting it here so I remember to. Neither of my children have shown an interest in coding, but there are probably better ways to teach it.
📝 Article — Why I still blog after 15 years — I can relate to this a lot. My blog is only 9 years old, but I can see me keeping this up even when I am not working in tech any more. This newsletter is as much for me than it is for anyone else.
📱 Gadgets — Orion, our first true augmented reality glasses — I can see Augmented Reality being the future. Being able to watch films or work on a massive screen, view additional information about the world around you. With AR, we could actually use holograms like Tony Stark does in the Iron Man films. Having said that, I wouldn't buy anything like this from Facebook.
🛠️ Tool — PostgreSQL 17 — I have been using Postgres a lot recently, and I have been really impressed with it. It seems to only be getting better. If I need a relational database then Postgres is usually my go to.
📝 Article — Hacking Kia: Remotely controlling cars with just a license plate — I am glad this is fixed, but it is pretty shocking. I preferred it when cars were mostly mechanical not another gadget that can go wrong.
💭 Thought — Wealth = Have / Need — This is so true. Lifestyle creep is real. If you manage to keep your wants and needs in check as your salary increases you can live very comfortably and not need to worry about money.
👨💻 Latest from me #
If you are reading this on the Sunday it comes out (29/09) then it is in fact my birthday today! One more revolution around the Sun.
If you want to make me smile today, feel free to reply to this email saying something nice, wishing me happy birthday or sharing something funny.
💬 Quote of the Week #
While I understand the inclination to say yes to any additional income, you must keep the big picture in mind: time is the most valuable commodity on the planet, and you have just as much of it as the wealthiest people alive. Value it accordingly. Never waste it away.
From Someday Is Today by Matthew Dicks.
Top comments (0)