IT Job Interviews – Technical

For quite some time now I am attending interviews for various IT-related roles. From junior and middle developer to senior, architect, lead and manager roles. On both sides of the table. It's surprising, how differentiated is the level of such talks.

This is last of two articles, in which I take a closer look at IT job interviews. Read the first one, IT Job Interviews – Human Resources.

Second leg is the technical interview. Since I was (and I am, and probably will be) on the both sides of the table, I will split this in two – one for the interviewee and one for interviewer.

The interviewee

Beginning of such interview most of the time depends on the person that interviews you. I rarely meet with "straight to the point" approach, mostly you will get a few minutes to tell something about yourself.

Introduce yourself, explain your role in the company and in the project you are recruiting for. Describe your technology stack. Mention the good parts, describe the things that you're proud of. You wrote some stuff that you're satisfied with? Talk about it, even if it's just an animation for some icons or a small loader (this is actually how I did land a job once, I showed my CodePen with a lot of animations that I've spend time on). If you have, show (or describe) the code you do outside your job.

Next part will probably be the technical questions. I won't list them, as there are many great collections already. My favorites are:

• Front-end Job Interview Questions
• Front End Interview Handbook
• React Interview Questions & Answers
• Top 10 algorithms in Interview Questions (not front-end related, but great for general programming questions)

Please note that there is no the list. Your interviewer may have their own set of questions and abstract and practical problems that you'll have to solve. Nevertheless, it's always good to refresh some basics.

When answering a question, remember to be precise and thorough. Vague answers suggest that you don't know the answer or don't understand it and just citing. Sometimes (this depends on how the talk goes in general) when answering a question, you can digress. Mention a similar problem you faced or another solution. I've never met a person who'd be angry at that, but you never know. But in my opinion, the reward is worth the risk.

Another part may be whiteboard test (or a coding exercise). This is very controversial thing, because its results aren't really that trustworthy. Why? You are being interviewed by someone that can decide your fate in this company. This is stressful! This makes you feel uncomfortable! This is not the environment for careful planning and solving complex problems or puzzles.

But, if this is a requirement, all you can do is approach it. Try your best to be cool and think slowly. Remember that not only the solution counts, but also the road to it. If you need to use Google, state it. You don't have to remember everything. Years go programmers had piles of books near then, now we have the Internet.

Final stage will probably be some small talk, perhaps you'll get a summary or some feedback. If not, ask when you can expect something from the company. Depends on their inner workings, this may be couple of days or weeks.

The interviewer

Despite the popular belief, this part is also hard, but on another level. The most important thing is to be patient and kind to the person you talk with. I know this is obvious, but I find it to be forgotten or neglected too often.

First things first. Introduce yourself, explain your role in the company and in the project you are recruiting for. Describe your technology stack. Mention the good parts, describe the things that you're proud of. You have a great backend team that writes blazing fast soft? Say it. You use Storybook for your components, and Jest for testing, and Redux for state management? Tell about it. But also note the bad parts. You have only junior QA that manually tests everything? Sorry, but please state this. Your test coverage is below 30%? Too bad, say it nevertheless. Make sure you are telling the truth.

Next thing is the actual interview. It is a good thing to start this part with some softer questions:

• Can you tell me about your current tasks?
• What technology you are using?
• What have you learned recently? Does it come in handy?
• Any side projects you'd like to tell about, or share?

And then, slowly, go to more technical aspects. I rarely have prepared list of questions, most of the time I just have a card with areas I want to inquire about. I also like to go from easy to hard ones, making sure to skip parts where I see the interviewee doesn't feel good. For example:

How do you make a button that, after clicking, will log "Hello" to console?

This will tell me whether this person knows about event listeners. Then I can ask

How to remove this listener?

Or, if she or he used an anonymous function, I can ask why. And so on, until we go to event bubbling, propagation etc. Make sure you won't stay in one section for too long. Asking too many questions will make the interviewee tired and less focused. I'd say ten, twelve questions are more than enough.

Now, should you conduct the whiteboard test, don't you?

Please, don't. Really. I took countless whiteboard tests and quite often I failed. I was nervous, stressed and forgot that arrays are referential type. I forgot the reduce syntax. I had to give myself two minutes to spell my name. Okay, the last one is exaggerated, but still, you get the point. Like I said in the first part of this text, this is not the good environment to test one's skills.

If you really need to see how this person codes and you don't have samples from them, give homework. Nothing too big, couple of files. Be vague about tech. This will give the interviewee the space to show off and to do things hers or his way. And you'll get a real sample of the code, rather than a ticked-off checklist.

After the technical discussion, ask whether the person you talked with have some questions. Any doubts, anything not clear? Make sure you answer everything. This is important, don't show your interviewee that you're late bored and don't want to talk anymore. You want someone curious, someone that will ask that one question everyone else forgot.

This concludes my thoughts on interviews for a developer positions. Please share your experiences, thoughts and views on this (in my opinion not covered enough) matter!