During my career I was asked to help in the recruitment process as technical expert. It's not my main task (I'm a dev after all) but what better way to judge a dev than to use another dev? I've done this more and less 50 times so far so I'd like to share my tips about it. I hope to help you prepare better for a technical interview and to be more confident in your abilities. Bear in mind that is my point of view: different people lead to different interviews even if corporations try to standardize them.
Also note that I'm referring to the interviewer as a "he" instead of "she" because I'm a man: for this reason it comes more naturally to me. It does not imply the interviewer must be a male. Gender is irrelevant here.
Rule 1: Do not bulls**t
When facing a technical interviewer ask first what kind of work he does. If he's someone who actively work on technology you must assume he knows the answer of the question he's asking. At the very least he has the answer written somewhere.
If you try random guesses you might get lucky and let him think you know the subject. But chances are of failing miserably, especially if the answer if more complex than a "yes or no". In that case you will lose all your credibility in a instant. Nobody wants to work with a guy who sells false information. Do you want to base your work on a random assumption? If it's wrong you may end up losing weeks of work. Personally if I smell you guessing, even if the guess is right, I will poke you with more details. And catch your lie sooner or later.
So if you do not know the answer state it clearly. From then you can start speculating, maybe even reasoning with the interviewer. It makes you sincere and allows you to express your reasoning skills.
On a personal side, I like people able to admit being wrong and not being omniscient. It makes them excellent working partners.
Rule 2: Explain your resume
Your CV can be "inflated" for HR purposes. I can understand that. But when asked by a professional if you really are a master of a technology do not lie. This is similar to the do not bullshit rule above. I will most likely figure out if you are not a master. For example, do not state you are a blockchain guru if you do not know what a Merkle tree is. I will ask you that and see through your lie. Just say something like "I know I've written guru but I meant from the end-user perspective, not a dev one". It puts things in context. I might still ask you if you know what consensus means. But I definitely will not ask you about Merkle trees.
This is true even for "basic" knowledge. Basic knowledge is even easier to verify. But more on that in the next section.
Rule 3: Know the basics
I have told you to clearly state if you do not know something. But you must know the basics. Applying to a technical position without knowing the basics of the trade is inexcusable.
For example, if you are applying for a DBA role you must know what and index is. I do not care if you know the syntax used to create one. I need you to know what indexes are and why they are useful. This is true regardless of the seniority of the role.
Other examples, taken from my experience:
- If you pretend to be a C programmer you must know the distinction between stack and heap.
- If you pretend to be a SQL Server dev you must know what
INNER JOINandLEFT JOINare. - If you pretend to be a C# programmer you must know what a static method is.
- If you pretend to be a Rust programmer you must know what mutability is.
You got the gist. The syntax, the details are useless. You can always look them up using your search engine. But if you do not know what you are talking about you do not even know what to find.
Bottom line: if you are clueless of a tech better to say so from the start. There is no shame in it. But do not expect to be hired for a senior C# developer position if you struggle explaining what inheritance is.
Rule 0: Be yourself
This is not technical but I think it's worth mentioning. Be yourself. Truly. The technical interviewer does not care if you are funny or smiling or whatever. He cares about what you know and what you can do. If you spend energy trying to appear different than you are you are wasting resources. Wasting resources is bad, even if it's your brain and not a memory bank.
You are a smartass? I don't care. You are introvert? I don't care. You are a minority? I don't care. You come from another planet and are allergic to kryptonite? I do not care. I am here to judge you from a technical standpoint only. If you say something very, very wrong (for example: "the best GC is the one used by C") no amount of smiles and posturing can change my mind.
On a personal note I have worked with many different people. Competence goes beyond everything. I prefer to work with someone skilled with gdb even if he's an asshole than a very cool, smart but useless guy. Of course I'm terrible at debugging so I might be biased on that :).
Rule 4: Ask questions
When working on a project you can ask questions. Maybe something is not clear. Maybe you think a different approach can be more productive. The point is, when working interaction is the key. So I expect you to ask questions during the interview. For example I might ask you to sketch a tree. You can ask "what for"? It gives you context. It's a reasonable question. Of course you can go on and sketch a binary tree. It's fine. But in reality nobody creates a binary tree for no reason.
If I answer your question with: "the tree is used to speed up lookup searches" you might reply: "why don't we use an hash set instead?"
This is just an example but it gives an incredible amount of information to the interviewer: you know what trees are, what hashsets are and when they are useful. That's a lot of information in few sentences. And in our trade information density is a plus!
Rule 5: Prepare samples of your work
Nothing speaks better to a dev than code. So please bring some code with you. Even if you are completely green nowadays people expect to see your GitHub profile. And no, blindly forking cool projects does not count. You have to have built something. It can be a simple math lib or a utility program.
It shows two things:
- You have done something. We dev know that it's really difficult to create something working. The idea is not enough. You have to fight every line to get it working. You have to read the documentation. You have to build a test case. You have to debug. And every step will be hard. But you did even if the result are 20 lines of code. SLOC is meaningless in this context.
- You know the basics (source control, ssh, etc...).
Please do not rant about an hypothetical project. I do not care if you are planning to create a cool Raspberry Pi project. I care if you have done it.
Also do not give me a boring university project: a program that implements merge sort is "meh". If you are out of ideas, automation is a good start. Do you find yourself sorting you photos manually every time? Build a script to do that. It's way more informative that the nth useless, academic project.
Final rule: Be proud
It has been mentioned somewhere in dev.to too (I can't find the post right now, sorry). Please, please, be proud of what you do. You can only code in BASIC? Be proud of it. You do not know how to CUDA? Don't be intimidated. In the mind of the technical interviewer being able to do something means you can learn. But if you say: "I know a little bit of BASIC, but not well and I haven't done anything with it" you are downplaying your skills and your love for software development. The latter, to a dev, a guy who spends its life in coding, is a showstopper.
What do you think? If you have questions don't hesitate to ask.
Happy coding,
Francesco Cogno
Top comments (0)