19 Tips for Engineering Candidates
The following assumes you’re a professional and actually interested in the specific job you’re interviewing for.
The common advice to maximize your chances landing a job focuses on preparing the technical aspect, such as algorithms, system design, live coding, etc. But this is not the full story, there are things before and after.
The current market of the end of 2021 is an “employee market”, and many feel they have the upper hand, and they can have it their way as companies are desperate for engineers. The real recent examples below demonstrate this attitude.
There is no private jet and a red carpet waiting just for you.
I’d like you to think of the recruiter’s and the hiring manager’s perspective.
Most importantly: employers prefer to have a hole than to have the wrong person fill it.
Application phase
Fill all information
We all know we need to upload our résumé. Often there are additional fields, that applicants choose to leave empty, thus, reducing their chances over other candidates who gave the required information.
Things like expected salary, start date, visa status, etc. You gain nothing by not filling them. Your salary expectation for example, is usually used to see if there is a rough match with the employer’s salary band for the position. What’s the point of hiding it, interviewing and wasting time if there is no match at all there?
This may be used for the eventual offer (not always, some evaluate based on the performance demonstrated during the interview process only), so give a range that makes sense.
Research how it’s done where you’re applying
It is now a global market. If applying for a relocation position, do not use the way of doing things on your city or country, but rather check how it’s done where you’re applying.
If you’re used to stating the expected salary in monthly terms and using your local currency, research the employer’s way — it may be yearly and in the currency of their headquarters.
Résumé format and information — for example: if you’re used to state the education chronologically ascending, then the work experience ascending, and supply your passport number, could be that the employer is expecting the opposite — descending work experience and then descending education without passport number.
Prove that you do your homework and adapt to needs.
After applying
Do not be rude
Being rude to the recruiter or the interviewers will usually lead to a quick rejection. Things like “I only talk to tech people”, or “I am willing to grant you 30 minutes on date X only” are perceived as unprofessional and patronizing.
Rudeness can be demonstrated also in technical interviews, e.g. “this is a weird question”.
Do not be late
Be ready a few minutes before the interview and start on time. Being late is a very negative signal, and even more so without an apology.
Be responsive
Reply to emails or messages on recruiting platforms in a timely manner, don’t make the employer chase you. If need more time, or not interested anymore, just communicate it.
Show up
Showing up to interviews sounds like a very basic thing to expect. Nonetheless, I have recently witnessed a lot of cases, where candidates didn’t show up or communicate about it, and after being asked about it by a recruiter, (when they actually replied) they totally ignore not showing up, not apologizing, and demanding a new time slot.
This demonstrated low work ethics, bad judgment and unprofessionalism.
Behave
Interviewers capture notes about all the demonstrated behavior.
“Why so serious?” — smile (perceived as a common signal for cooperation), be polite (good judgment and human skills), open the camera in remote interviews.
Remote setup
The following might be challenging and sounds very privileged. My point is — maybe your interviewer is privileged. Make an effort to adapt to them.
- Do not interview in a loud café. This makes the whole experience much harder and negative, and shows bad judgment
- Find a location with stable and fast enough internet connection
- In case of other roommates, family members and children that can make noise — some interviewers find it hard to be thoughtful about it — try to find a quieter room and ask them to be quiet during the interview
- Have good lighting — do not have a strong light from behind, because you’ll be seen only as a silhouette
- Show your whole face, it’s less effective to see only your neck or nose
- Have an adequate microphone. Not being able to hear well might affect the interview
- Have pen and paper ready, take quick notes for yourself
Be prepared with answers for common questions
You know that with very high probability, you’d be asked to introduce yourself, talk about a past project, tell what you’re looking for, and several more. Why not practice and convey the message you want to convey?
“Why you want to work for us” — relocating from your country is not a reason, you could be relocating or working for another company in another country. Answer the question (e.g. the domain, culture, people you know there, impressive tech blog, do-good, specific technology, etc.)
Not knowing anything about the company is a red flag. Asking in the interview “so what do you actually do?” shows zero preparation.
And generally, have good reasoning for transitions or anything else, like moving jobs, moving countries, studying… to show that you think things through.
Home challenge
- Read the instructions and follow them. It shows that you can understand and execute on requirements. For example: how to submit, fulfilling the actual requirements, deadline, assumptions, etc.
- Do not overengineer. This is not the place to impress with things unneeded. Treat it as if you were at work, unless stated otherwise, and keep it simple
- Supply a readme, with assumptions, trade-offs, how to run the tests, how to run the program, etc. — it demonstrated communication skills
- Verify correctness — I’ve often seen well structured challenges that simply don’t fulfil the instructions, which demonstrates low attention to detail.
- Error handling — don’t supply the happy path only
- Automated tests — supply as if you were at work (unit tests, integration, error cases)
- Use good practices when makes sense, like design patterns, SOLID principles, etc. It’s not only about correctness. The idea is to forecast how you’d write code on the job
- Choose the most appropriate tools (database or in memory, web framework, libraries) and any explain in the readme why you chose them
- Do not include empty files, dead code, unused libraries
- Naming and coding conventions (a.k.a clean code) — consistency, meaningful names (variables, methods, classes)
Theoretical knowledge
Look up frequent questions for your area of expertise, e.g. data structures, architectural components, infrastructure. When not knowing, better to say it than to say you know but cannot explain.
Level of details
Make sure you answer with the level of details you’ve been asked about — not too high and not too detailed or irrelevant.
For example, when asked to mention what kind of steps a CI/CD pipeline can potentially have:
Too high: “it deploys”
Too detailed: “when Lisa the engineer merges, it pulls the code via git version 2 within three seconds with a designated user and downloads to a unix machine running on ubuntu…”
Irrelevant: “I’ve been asked to write a yaml so other developers can deploy”
Right level: “pull code, lint, install packages, build, unit tests, integration tests, security scans, create image, upload, deploy”
Generally start more high level if in doubt, and label or count. For example “I had 3 main responsibilities: people, tech and processes”. Then dive deeper, and usually the interviewer will ask more specific questions.
Clear communications
Hopefully you have adequate language skills required for the job. This is the first step, and on top of it, need to not talk too fast or too slow, so your counterpart can understand.
Try to avoid repeating yourself or giving vague answers.
Do not cheat
Having someone in the room telling you the answers, or reading answers from the internet is much more obvious than you think.
Do not stall time
Some candidates think that they would benefit from stalling time (by “thinking”, talking very slowly, overtalk), because they will be asked less questions. The opposite is true — the interviewer wants to hear as many answers as possible, and let you shine.
Do not try to take over the interview
Another notorious technique is to sneakily bombard the interviewer with questions, usually done after giving a short or vague answer.
For example, after being asked about the ideal culture for the candidate, they might respond by asking about the culture at the company.
Again, the interviewer wants to hear as many answers as possible, and let you shine.
Prepare your own questions
In most cases you will be given time to ask your questions, either during the interviews or in a dedicated conversation.
Besides you getting answers for the things that interest you and will affect your decision to join the organization, the interviewer is assessing your questions, as they show what you care about, your maturity and engagement level.
If you only ask about vacation days, perks, compensation and when the daily standup is, it’s much different than asking about the product, strategy, teams, culture, or why the interviewer joined that company.
Do not generalize
Many interviews are using behavioral questions, that is, asking the candidate to share a specific example of some case.
Simply answer the question. Share an example.
Do not try to avoid by giving some generic answer, such as “people make mistakes, so if we talk, it’s fine”, or “one should continuously learn”.
Be open
It doesn’t make any sense to hide mistakes, weaknesses and conflicts.
If you claim that you never had any in 15 years, you’re either lying or totally unaware, and both are really negative for the interviewer.
Nobody is perfect and we all make mistakes. We improve as we share and learn from them.
Trying to sneakily avoid is again a very negative signal. Besides answering rudely (“it’s a weird question”), or avoiding (“Nothing comes to mind”, “I am a nice person, I don’t have disputes”), trying to fake it is also a negative signal. For example: “I was missing a semicolon and my colleague told me” as a mistake. Another example could be “need to learn docker” as a weakness — it’s not a weakness, perhaps it’s a knowledge gap.
Remember that the interviewer has very limited time with you, and they are looking for signals to predict whether you’d be a good technical and cultural fit. Giving “bad” answers does not cause an immediate rejection. The interviewer collects the signals and evaluates, then comes to a conclusion.
Be professional, be prepared.
Good luck!
