Icon Spring-It-On: The Game Developer's Spring-Roll-Call

 

Icon Interviewing Advice from the Other Side of the Table

 

Icon Saguaro

 

Icon Learned Motion Matching

 

Icon Why Can't I Reproduce Their Results?

 

Icon Latinendian vs Arabendian

 

Icon Machine Learning, Kolmogorov Complexity, and Squishy Bunnies

 

Icon Subspace Neural Physics: Fast Data-Driven Interactive Simulation

 

Icon Software for Rent

 

Icon Naraleian Caterpillars

 

Icon The Scientific Method is a Virus

 

Icon Local Minima, Saddle Points, and Plateaus

 

Icon Robust Solving of Optical Motion Capture Data by Denoising

 

Icon Simple Concurrency in Python

 

Icon The Software Thief

 

Icon ASCII : A Love Letter

 

Icon My Neural Network isn't working! What should I do?

 

Icon Phase-Functioned Neural Networks for Character Control

 

Icon 17 Line Markov Chain

 

Icon 14 Character Random Number Generator

 

Icon Simple Two Joint IK

 

Icon Generating Icons with Pixel Sorting

 

Icon Neural Network Ambient Occlusion

 

Icon Three Short Stories about the East Coast Main Line

 

Icon The New Alphabet

 

Icon "The Color Munifni Exists"

 

Icon A Deep Learning Framework For Character Motion Synthesis and Editing

 

Icon The Halting Problem and The Moral Arbitrator

 

Icon The Witness

 

Icon Four Seasons Crisp Omelette

 

Icon At the Bottom of the Elevator

 

Icon Tracing Functions in Python

 

Icon Still Things and Moving Things

 

Icon water.cpp

 

Icon Making Poetry in Piet

 

Icon Learning Motion Manifolds with Convolutional Autoencoders

 

Icon Learning an Inverse Rig Mapping for Character Animation

 

Icon Infinity Doesn't Exist

 

Icon Polyconf

 

Icon Raleigh

 

Icon The Skagerrak

 

Icon Printing a Stack Trace with MinGW

 

Icon The Border Pines

 

Icon You could have invented Parser Combinators

 

Icon Ready for the Fight

 

Icon Earthbound

 

Icon Turing Drawings

 

Icon Lost Child Announcement

 

Icon Shelter

 

Icon Data Science, how hard can it be?

 

Icon Denki Furo

 

Icon In Defence of the Unitype

 

Icon Maya Velocity Node

 

Icon Sandy Denny

 

Icon What type of Machine is the C Preprocessor?

 

Icon Which AI is more human?

 

Icon Gone Home

 

Icon Thoughts on Japan

 

Icon Can Computers Think?

 

Icon Counting Sheep & Infinity

 

Icon How Nature Builds Computers

 

Icon Painkillers

 

Icon Correct Box Sphere Intersection

 

Icon Avoiding Shader Conditionals

 

Icon Writing Portable OpenGL

 

Icon The Only Cable Car in Ireland

 

Icon Is the C Preprocessor Turing Complete?

 

Icon The aesthetics of code

 

Icon Issues with SDL on iOS and Android

 

Icon How I learned to stop worrying and love statistics

 

Icon PyMark

 

Icon AutoC Tools

 

Icon Scripting xNormal with Python

 

Icon Six Myths About Ray Tracing

 

Icon The Web Giants Will Fall

 

Icon PyAutoC

 

Icon The Pirate Song

 

Icon Dear Esther

 

Icon Unsharp Anti Aliasing

 

Icon The First Boy

 

Icon Parallel programming isn't hard, optimisation is.

 

Icon Skyrim

 

Icon Recognizing a language is solving a problem

 

Icon Could an animal learn to program?

 

Icon RAGE

 

Icon Pure Depth SSAO

 

Icon Synchronized in Python

 

Icon 3d Printing

 

Icon Real Time Graphics is Virtual Reality

 

Icon Painting Style Renderer

 

Icon A very hard problem

 

Icon Indie Development vs Modding

 

Icon Corange

 

Icon 3ds Max PLY Exporter

 

Icon A Case for the Technical Artist

 

Icon Enums

 

Icon Scorpions have won evolution

 

Icon Dirt and Ashes

 

Icon Lazy Python

 

Icon Subdivision Modelling

 

Icon The Owl

 

Icon Mouse Traps

 

Icon Updated Art Reel

 

Icon Tech Reel

 

Icon Graphics Aren't the Enemy

 

Icon On Being A Games Artist

 

Icon The Bluebird

 

Icon Everything2

 

Icon Duck Engine

 

Icon Boarding Preview

 

Icon Sailing Preview

 

Icon Exodus Village Flyover

 

Icon Art Reel

 

Icon LOL I DREW THIS DRAGON

 

Icon One Cat Just Leads To Another

Interviewing Advice from the Other Side of the Table

Created on Dec. 12, 2020, 12:02 p.m.

When you're a student or fresh graduate interviewing can be a mysterious experience. Even if you feel confident presenting yourself and your work, both the process and the result can seem to appear somewhat arbitrary.

In fact, there can be a vast array of reasons why you may or may not receive an offer - and many of them will not even have anything to do with you on a personal level. Things such as the timing of projects, the structure of teams, internal or governmental policy, budget, legal and visa issues can all compound in fuzzy ways along with your CV and interview performance to make an application sink or swim.

So I think it's fair to say that the single binary bit of yes / no information you receive after an interview is pretty much close to useless if you really want to identify what may have gone wrong, how you might improve, or what could potentially tip the balance of decisions in the future.

In the last few years I've spent many hours on the other side of the interviewing table. I've been an interviewer in probably hundreds of interviews and from that I'm convinced that, if you want to improve, the trick is not to focus on how you present yourself, and your own answers to the questions, but instead to focus on the process as a whole.

Because as an interviewer you can't help but notice that many of the bad things candidates do seem to stem from a misunderstanding of what the interview process means to the other person.

So next time you have an interview, try to imagine yourself on the other side of the table too, because you might discover a lot by trying to view the whole thing from a different viewpoint. But until then, here are some of my own tips from my time on the other side of the table:


Be Concise

When applying for jobs it isn't uncommon to take the whole day off for an interview. Having the whole day means you don't have to feel any additional pressure about timing - there is just one time you have to be available and just one thing you need to prepare for. In fact, when I was applying for jobs I wouldn't even bother to check how long the interview was planned to last - what did it matter? I was available the whole day.

But when playing the role of interviewer things could not be more different. I am often booked for the interview right in the middle of the work day, surrounded by other things to do and think about. Not only is my mind engaged on something totally different the hour before the interview, but it may need to switch to something else right away afterwards. During the interview I am always acutely aware of time ticking by, and the fact that an hour or two is really not a lot of time in which to assess a candidate.

So, as an interviewee, when you're deep into a passionate twenty minute long monologue about the childhood experience that inspired you to be a programmer, or the tiny technical details of that project on your CV from years ago that has nothing to do with the job you've applied for, you should probably be asking yourself "is this a good use of my time?" - because I can assure you that is exactly the thought that will be going through the head of your interviewer.


Be Clear

As an interviewer, I may not be an expert in the specific area which you have the most experience. If you're a researcher or work in a very specialized field then this is even more unlikely.

Saying that - given the fact I'm interviewing you in the first place - out of everyone in the company - I'm still probably the person with the expertise that most closely resembles yours, and the person with the best chance of understanding your work. If you can't explain your work clearly to me, in a way which I can easily understand, what luck are you going to have with the hundreds of other non-experts in the company which, if you were hired, you would inevitably have to communicate, present to, and collaborate with?

If your interviewers can't understand your work you need to practice presenting and explaining it to people with a full range of expertise from complete lay-people to experts. Not only is this a skill which will always come in handy for the future - but thinking of new ways to explain your work may even help you come up with your own new insights into it.

When it comes to presenting your work, your interviewers may feel like a kind of final boss - but in reality they're the boss on level one - and if you can't succeed there, you're probably not ready for level two.


Read the Room

When interviewing for jobs it isn't unusual to deal with weird time zones. Even if you're applying for a job locally, international offices can mean getting up early or staying up late. There is, however, a very important time zone which often gets overlooked and forgotten - the time zone between 9 and 5.

You see, there is something I need to admit... I am not a perfect human being - I get tired during the day - and by 4pm I am often much less energetic and positive than I was at 9am - my patience has often taken a blow, and I can assure you, I am not always enthusiastic about the prospect of doing an interview.

So yes - that means I do not always interview candidates perfectly equally and fairly.

But here is the thing: as a candidate, this bias can easily be overcome by acknowledging it and making a good first impression. Read the room - if your interview is first thing in the morning perhaps your interviewers will want to have some small talk and drink their coffee before diving into the obscure mathematics you used during your master's thesis. Equally, if it's the end of the day perhaps they will want to skip the pleasantries and get straight into the details.

Nobody is perfect and no process is completely fair - but as an interviewer, if you can acknowledge my flaws and move past them, guess what - I will be 100% more willing to do the same for yours.


Discover Why the Job Exists

When I was applying for jobs I don't think I had any real idea of what the process looked like inside the company. My only frame of reference was applying for universities, which in my head worked something like the following: the university created an ordered list of candidates, ranked by their grades, experience, and other skills - and took the top N candidates (of course I have no idea if this is the slightest bit accurate).

So when applying for jobs I suppose in the back of my head I had the same model. I figured that as long as I had good university grades, did lots of cool and impressive projects, and presented myself such that I appeared smart and intelligent, I could move my way up this imaginary list.

There was certainly one thing I never had in mind during this process: the actual job.

And that is the kind of weird thing that seems so abstract and far away when you're trawling through job postings - every job posting that exists out there exists because there is actually some kind of concrete job that needs to be done, and some person that needs to be found to do it.

The same identical job posting can exist for many different reasons. Perhaps a team is lacking some man-power and needs more people to chip in, or some product requires additional expertise, or simply that a company wants to grow so it can tackle new and different ventures.

And when I'm interviewing candidates for a job I find myself framing almost everything in terms of this very specific job that needs to be done - up to the point where I often grade a candidate's passing mark as a kind of abstract sum of how much value this candidate is going to add in terms of time saved, expertise, and new opportunities vs how much investment they might require in terms of training, ramping up, and mentoring.

As a candidate, if you can actually work out the specific reason the job posting you're applying for exists you can pitch yourself in a way that resonates with how your interviewers are likely thinking about the position.

So try to read between the lines when you're doing your research on the position. It might not be the optimal method for guaranteeing you a spot on my imaginary leader-board, but by working out why the job posting exists in the first place, you will hopefully be able to pitch yourself in a way which fits what the interviewers are looking for.


Don't Pad Your CV

The impossible thing about writing a CV as a student is that there is no reasonable way to express the largest component of your professional experience - your degree - in bullet points.

Instead I often see "BSc in Computer Science" (representing three or four years of hard work, study, toil, and growth) taking up one line and "Compsoc Union Hackathon" (representing a sleep deprived, pizza grease sweating 24 hours) taking up the next.

Given half of your professional experience summed up by one line, the temptation is always to add more - to dig into the depths of your brain for every little project and bit of work experience - every programming language, framework, and buzzword which has ever crossed in front of your eyes.

This might get you through some kind of HR clearance but it's only going to create a painful interview experience once you arrive as it increases the chances of the interviewer asking you about projects that didn't go well, you don't remember, or that you simply didn't care much about.

These random, unprepared CV items rarely go down well. If you're applying for a programming job and you feel the need to list "MS Office skills" on your CV that doesn't fill me with confidence. The same goes for random names of frameworks or unquantifiable numbers such as "developed a ML model to solve X with 95% accuracy". Not only do I have no idea if this number represents a good or bad result - it scares me that you think this proves competence. As an interviewer, asking questions about these CV items is usually pointless - the only thing it seems to do is induce sudden memory loss in candidates.

So don't add anything to your CV you're not proud of and willing to talk about in depth. Practice having conversations about your CV before you apply. Is there anything that feels awkward or out of place in the conversation? Does it tell a good narrative about who you are as a candidate?

Your CV is not just for HR. It's your main way of controlling how the interview process is structured and unfolds. Don't waste that opportunity by filling it with pointless fluff just so it looks full.


It Isn't an Exam

Anyone who has ever spent any serious time trying to pass exams probably has a natural aversion to the sight of an answer left blank. Leaving an answer blank is just always, mathematically worse than making a guess - and it doesn't matter how horrible or idiotic that guess is - it is still better than the guaranteed failure a blank answer represents.

But unfortunately this natural aversion is exactly what leads so many candidates to making a fatal mistake during the interview - guessing at an answer. Because when you take a wild guess at an answer the interviewer has no way to know if this is really just a guess, or if you are confident about your answer. And while it's easy to teach things to a new hire, if they really don't know what they don't know... chaos often follows.

Because at work, even a grade of 80% - i.e. fucking up 20% of the things you do - is really not good enough. But as long as you know what you know there will always be people to help you with the final 20% so that nothing goes wrong.

So never guess at an answer during the interview, and if you really do have to guess, always qualify it by telling your interviewers you are doing so.

It's been many years now since I was doing exams, and my aversion to blank answers over the years has faded. In fact, I'd say I've gained a somewhat proportional reaction in the opposite direction. These days there are fewer words I appreciating more than the beautiful fresh, unspoiled equivalent of a blank answer: "I don't know".


The Trivia Questions Aren't for you

Here is a question I think we've all asked ourselves at some point in our lives: what the hell is the point of those trivia-like interview questions which anyone could look up on Stack Overflow in about 10 seconds in real-life? How can they possibly reflect real-life job performance?

Well imagine my delight at having the ability to structure the interview process and remove all the stupidity associated with quizzing candidates on arbitrary and random technical knowledge.

Then, imagine my disappointment at deciding to add these back into the interviewing process. Yes I know... but before you jump on me, let me explain why...

They separate out those with deep, genuine experience: Look - we can all use Stack Overflow - but some people have looked up certain things so many times that they are chiseled into the folds of their brain. These people blast through this part of the interview in five minutes with an expression like "are these the questions you're asking? I should be interviewing you..."

They sanity check obvious frauds: Anyone can literally write anything on a CV. When someone writes "15 years experience developing multi-thread applications in C++" either I can assume the worst and take the time to properly and diligently verify this claim by asking them about their previous experiences, or I can take 15 seconds to ask what a Mutex is, how it differs to a Semaphore, and go from there...

They give a point of comparison: All the candidates I've ever interviewed have had such vastly different experiences and backgrounds that directly comparing them is simply impossible. Interviews entirely consisting of talking about previous projects are great for getting to know a candidate, but they don't actually help when it comes time to decide about making an offer. What if I like a candidate but my colleague doesn't? Discussions can get subjective very quickly. As variable and arbitrary as they seem, having a fixed set of short, objective questions you ask every candidate equally can give a much more stable point from which to launch a real discussion, do comparisons, and work through disagreements.

I know that trivia questions are stupid, frustrating, and ultimately a lottery for the candidate - but they're there to make our lives easier, not yours... I can only apologize for that...


Stand Your Ground

There is a little trick lawyers sometimes use to fluster witnesses and get them to make contradictory testimonies. The idea is simple: refuse to continue with your line of questioning until the witness agrees to something they don't really believe to be true:

Lawyer: "If you can confirm you knew you were going over the speed limit, then I'll explain how the accident occurred."

Witness: "Umm, Okay..."

Opps! While the witness most likely meant "okay" in the sense of "continue" it doesn't matter - the lawyer has just received the confirmation they wanted.

One thing that makes this trick so effective is the lawyer's position of authority. The witness may not actually feel like they have the right to tell the lawyer to stop their line of questioning. They could feel obliged to reply "okay" even if they know the first statement is false.

Often when I'm confirming my own (potentially incorrect) understanding of a candidate's work back to them, they can feel that to continue they have no choice but to confirm it, or simply that they don't have the authority to correct me on the wrong things I've said.

But unfortunately there is no faster way to derail a technical discussion than this. Just like a flustered witness, no amount of backtracking can seem to recover from these kinds of initial misunderstandings.

So always stand your ground - don't confirm anything you don't think is true - it will just come back to bite you later. You're the authority on your own work and even if the interviewers disagree with your understanding of a subject, at least they will be certain of what your understanding actually is.

An interview is about discovering the truth about a person and their experiences. But as pressured and confrontational as that can seem, there is one very important difference to a court to keep in mind during the interview: you're not on trial and everyone wants the same thing - for you to be the great candidate they are looking for.

github twitter rss