Applying to Ada Developers Academy — Part 3: Coding Challenge — Technical Interview
Hi there. My guess is you found my blog because you’re interested in Ada Developers Academy (ADA). While I’ll keep my blog content, I want to clarify that at the moment of June 2023, I don’t support ADA the organization nor do I encourage people to apply. This is the second time I put this statement in my blog, the first time was in March 2022.
That’s said, if you’re applying to ADA, I hope the content of my blog will be useful to you. Good luck and happy coding!
These two parts used to take place the same day: you came in person to solve a problem and after that you explained your code. All of the three admission rounds I participated were during COVID-19 pandemic, so they moved everything online, and so these became two separate steps. If you’re curious about the first phase, here’re my thoughts and experience.
The problem to solve is pretty much about storing data either with (insert ADA’s programming language of choice) built-in collective data structure and some calculation. It’s actually more than that (logical thinking and so on), and I just emphasize what were important to understand to me. ADA wants you to demonstrate that you understand the concepts covered in ADA Build. You don’t need to show more than that, you can if you want to though. You can also try the Practice Test, which is last admission’s code challenge. The logic behind will stay the same, at least from my experience. After submitting you cannot access the test again, so if you want to continue practicing with it, you can either delay the submission, use another email, or save the problem somewhere else.
The two most current admissions used HackerRank, so getting used to it is helpful, too. I’m still confused by HackerRank UI (my bad). One thing I would like HackerRank to have is the comparison functionality where differences between the output of our code and the expected test result are highlighted. This is why I prefer LeetCode (laugh). But you can always use comparison tools, like DiffChecker or TextCompare.
From my experience, the technical parts are not the most important steps in ADA’s admission process. Not to say they don’t mean anything. But in my experience it’s better to have your application balanced across all phases rather than really strong in one phase and floppy in others. What I’m sharing in this series are either what I think are strong points of my application, or the floppiness I’ve made and I hope no one would make again. Here are my observations:
- You don’t have to pass all of the test cases to move to the next step/get admitted.
- On the other side, you still can get rejected even if your code passed all test cases.
So take the pressure off yourself on this part. Honestly. If you want to go all out and demonstrate your extensive knowledge about Python or Object-oriented Programming, I would be so impressed (I google most of things when I code in Python, ha). But if you feel like your code is too simple, no worries.
A point I want to spell out: ADA’s made it clear that you should NOT discuss with other people about the code challenge. Remember the code challenge used to be in-person, in a room with interviewers watching you, and just after submitting that was the technical interview. Now applicants have days to complete it.
The technical interview is a chance for you to show that you actually understand your code, and have done some thoughts to ‘improve’ it. Here are the overall of the questions. Keep in mind the actual questions will be tailored to your code particularly, and I’m also not sharing questions that I consider too specific to my code.
- Technical challenges you’ve encountered and how you overcame them. (I think every time we write code we should keep this question in mind. It’s an excellent question.)
- How your code handles the number of input entry.
- How you’ll change your code to handle different number of input entry.
- How you’ll handle a tie case.
- How you’ll change your code to handle one more product (one more input argument).
- Why you did things this certain way (another excellent question).
You can compare the third and fourth questions with the test cases of the practice test, and you may notice that they are, in fact, the later test cases. So part of me (jokingly) wonders what if someone purposely underperformed in the code challenge, leaving a few test cases unhandled (laugh). But honestly I don’t think we should try that, because there’re lots of other features we can support even if out code passed all of the test cases. Underperformance (intentionally) not only can costs applicants a chance to move to the next step, but worse it can impedes our desire to really improve our code. Every line of code deserves our best effort.
I’ll encourage you to keep a copy of your code, and notes about it (inline comments work too), and keep thinking about it even after submission. Most likely you’ll want to change some where.
The idea of ‘improve’ pretty much depends on, →YOU← . You can try to shorten runtime (which is not the same as big-O notation, but that’s for another post), or reduce memory, or utilize cool features of the language you’re using. But particularly for ADA’s code challenge, I think just knowing that there’re are other ways to accomplish the same/similar things will definitely help. Also because there’re many ways to get the same output, there’s no the-one-right-way. Your code works, and that matters the most.
Practice answering the questions with someone and focus on how comfortable you are when talking about your code. If you find a gap in your understanding about your code, fill it in. The technical interview is a conversation, not interrogation. Your interviewer, who most likely will be an instructor or teaching assistant at ADA, will be kind and supportive. Take the chance to ask them anything Python/programming related. Some of my favorite questions to ask interviewers:
- What to learn to get technically ready for ADA. (this question is shared from an amazing ADA applicant and I regret not asking it)
- How to handle a feature that you want to support but don’t know how. (I mean, your interviewer knows much more about programming than you, right? So why not take the chance?)
If you have any questions that you think deserve a spot in this list, please share! And also share your thoughts on …my thoughts, whether if you agree with them or want to introduce me to a new viewpoint. I would really appreciate that. The next post will the the final one in this series, and we’ll talk about the last phase: behavioral interview. In the meantime, happy coding!
