As soon as you receive a pre-interview assignment, you should immediately spend one hour on it.
This is to make sure you understand the directions, that the APIs/data sources they provided still work, and to make sure any other incidental things won’t pop up 24 hours before the challenge is due.
Clarify any issues early on and reach out to your point of contact if you have any questions. Do not be afraid to do this.
Managing expectations are extremely important. Whether you work for a large enterprise company or as a solo contractor, you always want to agree on the requirements. This allows both parties to understand the scope of the work and avoid (negative) surprises.
The last thing you want is to spend hours or days of work on something irrelevant to the employer.
That means:
- making sure you understand the instructions and requirements
- knowing the deadline
- clarifying any questions you have regarding the technology, functionality, features, etc.
Be aware of any communication delays (e.g. if you send an email on a weekend, you may not get an answer back until the next workday)
Remember to keep it simple!
Try not to waste time making things too “fancy” - or risk not meeting the deadline because you want to add to the solution. It can be easy to spend more time on the challenge than is necessary to pass the round, and you may be doing more harm than good.
Our advice? Complete the challenge as if it were a real client assignment, not a competition. The team might be asking themselves: "Would I be happy to build upon this code/data myself?”
Challenges usually have a deadline and they can range from a few hours to as much as one week. Three to seven days is pretty common.
Employers normally give you a deadline for submitting challenges. If however, they ask you to come up with a deadline, before you reply, spend another hour working on the challenge and think about how long it might take to finish. Double that number.
If the employer doesn’t specify a timeframe/deadline at all, you should suggest one. Avoid ambiguous timelines.
No matter what, do not spend more than seven days on a challenge. If you aren’t satisfied with your solution within seven days, submit what you do have.
The bulk of your work will involve you reaching flow state and crushing code. When not in flow, you’ll likely watch tutorials, scour Stack Overflow or Cross Validated, read books, and do tons of research.
This isn’t unlike what a typical day would look like in the job of your choice, by the way. In the professional world, your days will often consist of gathering requirements, research/analysis, implementing features/methods, testing, and interacting with people.
You might have questions. We advise you spend some time researching before you fire off a question to your point of contact. If possible, group multiple questions in one message instead of piecemealing them.
Employers will assume the way you work through the challenge is how you’ll work in their real environment. Be diligent, thoughtful, and deliver on time.
Details are critical. Your whole job is paying attention to the details. Missing a semicolon, forgetting to close a quote, using the wrong key to retrieve a map value, all these lead to errors. It behooves you to be meticulous.
Follow the Single Responsibility Principle. Keep your modules, classes, and methods as small as possible.
Make sure you test repeatedly before you submit.
Cheating is never okay.
Don’t copy and paste other people’s code and pass it off as your own.
Employers will find out.
Ask for it! But don’t wait until the very last minute.
Issues may pop up and require you to delay a submission. Maybe the internet went out in your apartment or Github went down and you couldn’t push your changes. Or maybe you had a family emergency come up.
Things happen.
And that’s okay.
Just make sure you communicate with the employer and alert them right away if something comes up (call or send an email via your phone if need be) to set new expectations around when you will be able to submit the assignment.
First rule of technical challenges: Always submit on time.
Second rule of technical challenges: Always submit on time!
Other rules:
- Make sure you’ve tested it twice, thrice, dozens of times before you submit.
- Make sure your submission satisfies all the minimum requirements
If there are a lot of features, elements, or a flow to navigating your app or project, record a video!
Videos are great for showcasing everything you built and adding context behind your choices.
Sometimes, an employer may provide feedback about your submitted challenge. This feedback can be negative or positive. How you respond is important because it may impact your advancement into future rounds of the interview process.
Do: Reply back with comments about what you appreciated or learned from the feedback. Show that you can not only take constructive criticism, but also apply it to future projects. It would be a good idea to re-submit the challenge with the applied feedback, to show enthusiasm and passion (although this is not required or expected).
Don’t: Become defensive. That can be a big red flag to recruiters/employers. It is important to remember that feedback is not personal, and that being able to receive constructive feedback is an essential part of your professional development and career growth. Don't defend your choice to the employer if they made it clear they thought you went about solving the problem in the wrong way.
Here's an example of a cybersecurity technical interview/presentation with an employer. In this scenario, the expected answers are non-trivial and derive from best practices and the ability to apply established frameworks of cybersecurity with minimal information. In these types of interviews, candidates receive the assignment in advance, and are often expected to present their findings in front of a panel of interviewers.
The pre-interview assignment
Hello Applicant,
Thanks for taking the time to interview with our team. We integrate Mt. Fuji projects into our hiring process. A Mt. Fuji project is a task that is assigned to a potential candidate to closely mimic the daily tasks required for the job. There is no right or wrong answer for these assignments, rather they are meant to be a conversation starter, and a way to investigate how the candidate would accomplish a complex task. This Mt. Fuji project will test your ability to create an Incident Response Plan and conduct a tabletop exercise to test the effectiveness of that plan.
Directions
Unicron Schwartz, Inc. is an online retailer that sells widgets to consumers. It operates an online storefront hosted in a single AWS region. Internet sales account for 100% of Unicron Schwartz, Inc’s $500M revenue. Any service impact can seriously impact revenue.
Unicron Schwartz, Inc. allows users to login and create profiles that store information such as Name, Address, Phone, and E-mail Address. As an online retailer, the company also accepts credit cards and allows consumers to save card information for the convenience of future purchases.
Create an Incident Response Plan based on this company profile
Details:
The goal here is to see how you can develop an appropriate Incident Response Plan. If there are additional company profile details that you need to complete this plan, you can take the liberty of inventing any additional details needed.
- Make sure your plan includes any sections you feel relevant for a basis Incident Response Plan as well as anything additional needed to meet the needs of Unicron Schwartz, Inc.
- Your plan should call out Key Stakeholders as well as Response Team members.
- Be prepared to present and discuss the plan to a group during your on-site interview. You will also be asked to conduct a tabletop exercise to test the effectiveness of that plan.
- You will need to make assumptions throughout this process. This is fine and you are expected to take any liberties you feel appropriate. Please take note of your assumptions and be prepared to discuss them.
Please reply back with your plan. After we receive your project, someone from our recruiting team will contact you and schedule a time for an in-person interview.
GOOD LUCK AND HAVE FUN!
Next: Tips for Technical Interview success!
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent