Whiteboard or Pre-Interview Technical Challenge

Whiteboard coding is a popular and common way of assessing a candidates technical ability during an interview. They serve as a talking point to understand a candidates eligibility for the role, how smart they are, their technical and theoretical background and how they tackle problems. To quote Joel Spolsky:

…writing some code on the whiteboard, my real goal here is to have a conversation about it.

As I mentioned in my Basic Tips, interviews are a conversation between an business and a candidate that goes two ways. However, are companies not hiring candidates based on if they cannot get solutions correct? Do candidates get nervous and flunk interviews at the sign of a pen and dry eraser, even if they could be fantastic for the role?

If a candidate doesn’t know a “trivia question” programming problem, then perhaps they just haven’t encountered the problem before and won’t know the answer without the help of an online search. Smart candidates will give it a go and can intelligently talk about how they would tackle the solution, even their solution has bugs. The bugs can be discussed, but would this normally have happened? What about those who have just seen or revised the problem before and can talk about it?

So why then do I opt for a pre-interview technical challenge with Granify?

My thinking is that I want to give candidates a challenge they can spend as much or as little time on as they see fit before our scheduled interview date. Unless the candidate completely bombs or doesn’t put any effort into the technical challenge, we’re likely to interview them. It’s a talking point that I can code review individually, and then with the candidate during the interview.

It opens questions around any bugs founds, technical choices to reveal their insight into technologies used and why, things they would do differently, did they do any testing (and why), how they would make it easier to maintain in the future, coding style and design and more. Through them explaining their code to me as I ask potentially dumb questions of “how does that work?”, I get to see how they could fit as a mentor and collaborate with our technical and non-technical employees.

I feel that the pre-interview technical challenge serves a few purposes over the whiteboard interview:

  • Weeds out those who cannot even tackle the problem before bringing them into the office
  • Presents a non-trivial, real-life, interesting problem that passionate programmers will excel at. Those without the passion or effort have shown it through their technical submissions.
  • Being non-trivial and real-world, the answer cannot be Googled in one or two searches to find a complete answer (although some parts could, and that’s okay as long as the candidate can talk about it and show understanding).
  • Enables questions that revolve around the life of a developer, beyond just writing some code to solve a problem.
  • Allows code reviewing and questioning motivations without the stress of asking a problem to be solved on the spot.

One down side is that individually it takes much more time. With a whiteboard coding problem I can ask in the interview and get an answer right there and then. With a pre-interview challenge, they candidate must go away and write a solution and then the interviewer spends time reviewing the code before the interview.

Counter to this,having code to talk about from the get go in the interview and bringing out the good from the bad programmers before they walk into the building saves time in the long run for Interview planning and finding the right people.

Tell me your thoughts. Does your company prefer whiteboard, technical challenges or something else? I can’t say my preference is the best or perfect but I strive to find better ways to hire better candidates.



Interview Tips: Basics

I’m in the process of interviewing new software developers for the company I work for, and while we interview for a range of Junior to Senior developers, these tips may help any level of experience. The tips are not solely for developer or technical roles.

A lot of what I’ll say here isn’t ground-breaking. It’s the basics. The really, really basics. I’ve noticed that a number of candidates do not have these down yet, so here’s a few items I feel might help you if you’re in the position of being unsure how to go into an interview.
In brief, these suggestions can be broken down to:

  1. Prepare
  2. Positivity
  3. Plan
  4. Listen
  5. Extra steps


If you have an in-person interview, be prepared to show the best side of yourself. Set out what you’ll wear beforehand, find out where the building is, go in earlier than the appointed time, get a good nights sleep and double check there’s nothing in your teeth before showing off your pearly whites on introductions. Good first impressions make a huge difference to how your interview will go.

For remote interviews this is much the same. It still helps to dress and look your best (even if they can’t see all of you). Similar to finding the building and getting there ahead of time, I cannot stress enough how important it is to be aware of the method you will be using to have the interview. Test conference call links in advance, log into any software early or keep your phone beside you.


This is a broad topic, but always try and be positive. It starts with a smile. Even on phone interviews, a smile can almost be heard. This extends to being positive in what you say, and not selling yourself short or coming off as too cocky.

If an interviewer asks you “What do you think you could have done better on our assessment?”, they will be looking for you to sell yourself through critical thinking and being realistic. Answering “Nothing, it was perfect” is too much, answering “It was awful and I don’t know how to fix it” is also bad.

Find ways to instead show yourself in a positive yet humble light “I feel that I could have done section B a little better if I had used technique 1 instead of technique 2, however I am happy with my choice of using technique 3 in section A because it has these advantages over technique 4”. Analytical, critical thinking, understanding of positives, negatives and willing to change previous thoughts.

I’ve had candidates out right say that in times where their ideas conflicted with others, rather than find a positive compromise between two colleagues, they “couldn’t do anything. It’s a lot easier to let the other person have it their way”, even if the other person was perhaps in the wrong. This is a negative way of selling yourself.


Go into an interview with a mental plan of questions and answers.

You will likely not know what you will be asked to do or talk about in an interview but you can plan ahead for what you would like to learn about the company, the life of the employees and whether the company will be a good fit for you.

The common interview format tends to be questions around your previous employment, understanding your experience, how you deal with situations that the company itself handles and learning about your character (soft skills).

You can somewhat plan ahead for these. Think of specific situations that you have had. Was there a time you worked under pressure? Conflicted with a co-worker? A time of success, or where you overcame a challenging problem? These are frequently used interview questions that you can plan ahead for. You may never be asked to talk about these, but if you have the situations in mind, you’ll be prepared for those questions, anything similar, or able to take parts of those experiences and use them for other questions that may be asked of you.

(I will do a follow up post on preparing and planning for technical interviews at a later time)


This might seem like a no-brainer. When you are being interviewed, listen to the interviewer. Ask them to repeat or clarify anything you don’t understand or didn’t hear. Take time to repeat any questions back to them if you need time to think. This is a strategy you will see employed by others in positions where they are asked frequent challenging questions (CEOs & politicians).

Repeating a question is a great way of giving yourself time to think of an answer and process what the question actually means in order to give specific, insightful and interesting answers. It also highlights to the interviewers that you have listened to their question and you are paying attention because you care about the interview. This is good.

Extra Steps

  • Remember an interview is a conversation, not just a series of questions fired at you. You are also learning if the company you are applying for is for you. Ask questions as you go.
  • Thank any HR members or interviewers for their time. While they may not reply, it goes a long way to be courteous and polite. Maybe this is personal preference, but if I get a follow up e-mail from a candidate with thanks and/or even highlighting some parts of the interview, I’m more likely to remember them positively.
  • Body language is important. If you slouch, cross your arms, lean back like you’re on a beach somewhere or give off any strange signals, interviewers will pick it up whether they realise it or not.
    Sit up straight, keep your hands in view without fidgeting, smile and keep your body relaxed without looking lazy. If it seems appropriate, you may mirror body language of an interviewer. This is something we often do without realising it, but it creates a human-connection between two people that shows you are attentive and in a situation you are comfortable and can handle.


Hopefully through reading these tips you’ll either have learned something new or reinforced what you knew before. Give it your best shot and good luck.
Feel free to leave a comment if you have anything additional to add or wish to discuss anything posted here.

The not-so-Scrum Scrum team

When I started with Granify, I was put into a team where there were a few responsibilities:

  • Onboard & support clients
  • Build internal tools
  • Work on smaller tasks in the larger domain

The idea was that through doing these steps, myself and 2 other recent grads, under the direction of a Software developer who had been with the company for a couple of years, would learn enough of the domain to be able to work in any area.

I quickly spotted an issue. There was no process for getting any of these items done with any priority: support was naturally “asap”, tools were “is it ready yet?” and smaller tasks got the “how’s it going?” treatment. There was a chaotic mess of task switching.

Naturally the first step was to decide to do a support rotation. Every week 1 of the 4 of us would be dedicated to support. No task switching. If more hands were needed, another could jump on temporarily. Otherwise during “support downtime”, this person was free to work on smaller tasks of their own choice, explore the domain or do self-improvement and education.

For the other 3, they would be dedicated to tools. In a small team comprised of three developers, where expectations were “Just learn, write code and do what you can”, having no process was a little difficult.

My experience and enthusiasm for agile resulted in it seeming like a great idea to implement Scrum as a process in order to work on our current tool. I knew it was going to be difficult, not be a real or full implementation and likely doomed to fail from external sources, but I wanted to try it. We got through three full 2-week Sprints before the team was disbanded to be integrated into the larger teams.

Here are my key takeaways:

  • Scrum works best when everyone buys in. Even if you have your team fired up and ready to go, listening, learning and embracing it, if you have a manager who does not buy into the idea, it is guaranteed there is going to be friction. This is especially so if they feel you are pushing for their role in leading. (This was not the software developer within the team, but an external management of a larger group and us tacked on).
    This could also be known as: “The Importance of Change Management” lesson.
  • Being a fresh developer, pseudo-scrum leader and all-round new face to the business means you get attention from those curious about what you are doing. Even if they believe the task will fail, good mentors will allow you to fail when there’s something to be learned in a space to do so.
  • Meetups like Agile Edmonton are fantastic learning resources and supportive venting grounds to better yourself, your team and get non-biased input from those with more and less experience than you. (I sometimes attend and facilitate this event every 2nd Tuesday at Startup Edmonton).
  • Humility and listening to others is key. Working with other fresh developers, we were all stumbling through our first steps with the business, working on the process and finding pain points of our setup and trying to make a good impression. Without being able to step back sometimes and say “How am I doing?” to each other, I believe we wouldn’t have been able to produce something we’re at least a little bit proud of today and become better developers working in our current teams.

The tool we made during my brief time as a pseudo-scrum enabler never got much use in the end (the nature of changes to the larger business process meant it no longer had a need). For ourselves, while we were developing it was instrumental in helping us support clients and so I still take it as an experience learned and cherished.

New Things!

After all the worrying about making mistakes on the coding tests and interviews I did, I seem to have been fairly successful!

I started my third week with Granify on Monday and so far am loving every second of it!

It’s a great company doing some awesome things with AI/Machine Learning and trying to make a difference to the world of e-commerce. If you don’t know about them, I highly recommend giving their site a read!

Since starting, funnily enough I’ve had two follow ups from previous coding challenges and job applications in the last week. It’s reassuring, and one of them was even so nice as to wish me luck, add me on LinkedIn and say to let them know if I’m ever available in the future! Super pleased.

Things are getting by very well right now. There’s always things I want to improve, and I’m working on them day by day, but it’s certainly been a good decision to come here so far. 🙂

Networking & Technical Interview

I went along to Agile Edmonton today, run by Startup Edmonton where I got to discuss agile issues people are facing, give some input from my limited experience and meet some new faces in my industry around Edmonton. It was fun! I’ll most likely be going to the next one in two weeks, regardless of the outcome of what I’m about to say.

While there, I met two guys who worked for the same company (for general reasons I won’t mention which) and got talking about what they do, the company processes, company state, future goals/5 year plan (or not!), what I’m looking for in Edmonton in a role, whether my interests matched with their development and more. It resulted in me being recommended to submit my resume and e-mail for a job interview, which is amazing.

They’re doing things I’d be really excited to get involved in. It sounds challenging, fast-paced, full of team effort & passion, new technologies for me to learn and simultaneously highly rewarding and frustrating. Before I flew over to Canada I knew that I’d like to try out for Startups, so being given the opportunity just from networking was fantastic.

However, there was a technical code challenge, and I’m feeling rusty on some things and a little slow in others compared to where I normally am. I’ve been revising bits and pieces of knowledge I expect in interviews (the sorts of things I remember and utilise for design choices, but maybe forget the specifics of, even when I shouldn’t), but I still don’t feel 100% up to scratch, and this was my first technical challenge of actually writing code. That was timed. And my every reaction recorded to be played back by them.


Needless to say, I freaked out a bit.

I came up with a (maybe working..) solution, that I 100% know is inefficient, might not actually run, might not even find the solution, and was just a mess. Because I was being recorded, I was very conscious of doing ANYTHING, so sometimes I just did nothing (minutes of inactivity…) and  other times I just pottered about hacking at things, making comments, etc. In the end, I went to try and test it, realised I’d need to set up something to do that, which would leave more dead time on the recording, but I’d already sat and done nothing for a while, so just panicked and submitted without checking.


Despair. Absolute despair. Okay, maybe it’s not that bad. I gave it my best (at the time..) I know it’s bad, I know why it’s bad, and I proceeded to check the correct answer after I submitted (fool me). Once submitted it couldn’t be changed…


The second technical challenge wasn’t too bad, it’s something I can get into where I got to develop a Magic 8-Ball application in Java, JavaScript or Ruby. I selected JavaScript even though I’m more comfortable with Java because I knew I could show off a little more when it came to making something a bit more interactive with JavaScript. I considered Java with Spring MVC, but I know I’d have a hard time getting a running executable, and not be able to put it on my website as easily as with JavaScript. Likewise for Ruby, I’d need more time and practice to be sure.

This slideshow requires JavaScript.

If you want to see my result, you can view it here, the test suite is here and this is the GitHub repo. It’s rather simplistic both visually and within the code. I added some features I find interesting (using localStorage to preserve previous questions, never having the same response twice in a row, a test suite done with TDD, using canvas), but I’m not sure if it’s enough to impress the interviewers.

I could submit them now, but it’s just gone past midnight. While I want to be keen and get them seen to sooner, I also want to have a quick look over them in the morning to be sure. Additionally, I can back up my time of stopping development with GitHub commits. Whether I was fast or slow in producing this, I can’t say. Personally I think I’m slow, and have much room to improve. That’s not to say I’m bad, just I know I can do better (which is good! Room to improve is better than hitting a cap…).

If I can somehow get forgiven for the mess that was the recorded coding challenge, and show off a bit with my Magic Eight Ball application, explaining my reasoning for both, I may be in for another interview with developers and then the CEO of the company. If I pass all that, I may be offered a job, and then maybe I get to stay, or maybe they don’t find me a good fit (or me to them too!) within 3 months. Who knows.


The future is maybe bright and a little daunting, but I’ll take opportunities. This is one I’m excited for. Even if I don’t get the job, it’s been a great experience. I’ll update here whether I actually made it or not soon.

Setting up shop

Landed safely at Edmonton Intl. airport! My flight was good, and you can see below some impressive views I got from above.

Getting through the border was relatively painless, although there was a scare when the border agent had difficulties with a section of my visa acceptance and had to redo the entire thing!

Not including the day I landed, I’ve had two full days here so far.

Day 1: Unpacking and organising my room, shopping, talking with my landlord, updating friends and family with status updates, messages, emails, photos and videos.

Day 2: Familiarised myself with the public transport out of Fort Saskatchewan and into Edmonton. Got my SIN updated with my work visa, opened a bank account (and set off a international money transfer), shopped in Walmart for more essentials, lots and lots of walking! Spent some time around the centre of the city, below the river near the uni, and the northern outskirts.

Everything is so flat and green!

I haven’t been into the city centre proper yet, and I’ll leave this for a day when I don’t ache so much from yesterdays walk!

Things have worked out well so far, a lot easier than I expected in fact, and I’m excited to get on with job seeking next week. The remainder of this week is dedicated to scheduling, updating my resume and portfolio, getting into some side projects I’ve had planned but not made time for, exploring more of where I live and spending a lot of time in the sun.



Yesterday I was in my house by the seaside of Wales with my best friend/partner throughout university, celebrating our past, present and future.

Today I said goodbye to her, wishing her luck in the future, thanking her for everything and wishing her the best. It’s potentially one of the hardest goodbyes I’ve had to do.

In just over a week I’ll be flying to Canada, looking for software engineering roles to continue my career and settling into a new city (for anywhere up to 2yrs!).

I’ve said “good luck, thank you and see you again” to friends a lot recently. The nature of graduating, it seems. We’ll keep in touch, support and motivate one another, but it’s still sad. I’m sure I’ll see some again, but transitioning from the end of University and saying farewell to my home, family and friends to a new city with unknowns is hard.

What is challenging is not what is wrong though. I can’t say I’m making the right decision, leaving everything and seeing a greener field, but what I’m going to feels full of excitement, new opportunities and hopefully a glowing future. It’s what I feel I have to do. Not doing it may leave me with always wondering “what if”. If it goes well, fantastic, if not, then at least I gave it a shot, no matter how difficult it feels right now. Here’s to making it work and succeeding!

To all my friends throughout Uni, I’ve probably said it to you already, but thank you for the years of support, debating, rivalry and fun. I wish you nothing but the best for your future. Keep in touch, and feel free to drop by any time. You’ve got this.

Portfolio Website updated

Just finished doing round one of an update on my portofio webpage. jameseuesden.co.uk

This was mainly updating the text and what project I have on showcase. There’s a few more things I’d like to do:

  • Improve the way work is showcased
  • Host this blog on my own web host rather than here on the uni file server
  • Change the design of this blog
  • Update the content once I have graduated to reflect that I am no longer a student
  • Redo the design (maybe)

I’m thinking about going back over some of my older projects (those showcased and some of those that aren’t) and making short blog posts about some of the more interesting aspects of their design and/or implementation. It will be nice to go over my previous work and reflect on my time at Uni, what I’ve learned, how I have improved and highlight some of the really cool stuff I got the opportunity to work on.

Combined species testing

I made some artificial files based on real data. Some files are super mixed together, other files are straight cuts.
So, an example of a very naive test file, just for the sake of interest, was when I combined two species of bacteria together at around 50% of one of their contigs. The GC Content chart then looked something like this:


Kinda out there!
Was this what I expected? Well, I did expect that there would be a noticable shift like that, but the weird thing is how the standard deviation acts. I think this is just my lack of understanding, but looking at that chart you can SEE where the huge difference lies, but since the mean is just across the middle, the standard deviation threshold only gets a bit mad when things are a fair bit above/below the mean.
This tells me that it’d be good to have another measure, to look for dramatic shifts in GC Content percentage like this. I’m not sure I have the time to do this right now though, so I’m jotting it down here as note of something to do if I get more time after the bulk of my documentation/as something I’d do as a future task.

Processing a huge file

I went to NCBI and found a large file. A file I thought my application might struggle with. It took time, but it processed! I imagine if this application were to actually be used, it should be hosted somewhere with a large amount of memory to be able to get through these sequences. Anyway, look, here’s some screenshots of what happened.

The contig itself is from: https://www.ncbi.nlm.nih.gov/Traces/wgs/?val=JOVY01

In particular, Campylobacter coli strain CVM N287 N287_contig_8, which is 207270 characters long.
I’m still working on ‘Superframe’, but you can see how most of the GC Content percentage regions that were outside of the mean threshold are all within the ORF Locations, which is exactly what I hoped to see.

hugefileprocessedfullsequence1 hugefileprocessedfullsequence2
hugefileprocessedfullsequence3 hugefileprocessedfullsequence4

The next step is to find another few contigs, smaller in size for time sake, run them individually to see that their GC content % regions match with their ORF Locations, and then start mixing them up together where I know there should be differences in the GC Content % and see if I can view this after processing the mixed contig data.