Recruitment: How not to answer our take-home questions

Congratulations! So, you have landed here after being shortlisted to be a member of the Product and Engineering team at Affinity Answers or you are just curious about our recruitment process. We are a small (but nice) company and our Engineering team is less than 15-member strong, so we are a bit finicky when we add people to our team. Many apply to be a part of us and the shortlisted prospective team member is sent a questionnaire. A good majority of them do not make the cut beyond this stage.

I thought I must write about what kind of submissions do not make the cut:

Throwing it over the wall

The web-app or a program that you have been asked to build does not do what it is supposed to do or even worse, has obvious bugs (we do not stress test your program, just simply do a basic sanity test). This is construed as being careless and a bit juvenile. Take some time to use your own creation and make sure basic things work fine.

Jupyter Notebook instead of source code files

If you have been asked to express a concept in code, then it is OK to submit a Jupyter Notebook file. However, if it is a program that is to test if you can write solid code and can be trained to write production code, Jupyter Notebook does not make the cut. Call us conservative and old style, but right now that is how it is.

“Intentionally” complex solutions that does not do the work

Simple programs do not need Data Science libraries/packages — they are overkill. Well, if the intention is to impress, I understand if the program ultimately does what is expected. Unnecessarily complicating an otherwise simple solution is not appreciated.

Copy-paste from ChatGPT without thinking

Well, ChatGPT can be an inspiration — but do not let it be your permanent crutch.

While the above tells us you what does not make the cut, the following can earn brownie points for sure:

• Eliminate any hard-coding, show your fineness
• If your code is not self-documented, then having comments at key places helps understand the assumptions you are making
• Write readable code; one way is to follow a style guide, for example this
• Modularise your code with at least one method
• A decent README in the project folder which is not boilerplate text from some framework
• Multiple commits in the repository with relevant comments

Just keep the above aspects in mind when you submit your answers and we would be delighted to invite you for a face-to-face interview.

We constantly look for people from various backgrounds to join our Engineering team, write to careers@affinityanswers.com telling what you can bring to the table.