This project was conducted for the Zendesk 2019 coding challenge for the opportunity to engage in a six month internship within the Zendesk Melbourne office. The challenge required participants to build a feature that can make http requests to the Zendesk API, then display the tickets in either a GUI or CLI.
Internship offer received and accepted.
- Connect to the Zendesk API.
- Request the tickets for your account.
- Page through tickets when more than 25 are returned.
- Display tickets in a list.
- Display individual ticket details.
- Happy path tests provided (minimum).
A goal set by my team lead during my internship program was to see if I could iterate over my origin design using new skills learnt throughout the course of my internship. Bellow you will find the list of the current iterations I have completed or am currently working on.
| Project | Interface | Languages | Progress |
|---|---|---|---|
| Version 1 | CLI | JS, NodeJS | Complete |
| Version 2 | GUI | Scala | Complete |
Hello everyone!
Stop trying to look at my code and cheat >:( just kidding.
For some strange reason my repo is at the top of the google search when looking for "zendesk coding challenge” and seeing as my repo gets rammed every year around August, I thought I'd add some notes from my interview experience to help you along your way.
I had two interviews, one technical and one interpersonal. Both interviews were on the same day in-office and went for about an hour each.
The interpersonal interview was straightforward with your generic HR type questions, such as, “What are your strengths, weaknesses, tell us a time you were under pressure” etc.
The technical interview was a little more involved. They had me go over the structure of the project and explain my decision making. I don’t remember being asked about any programming theory, algorithms, or space/time complexity.
They did get me to make a change to the project on the spot which I think was meant to be the main challenge of the interview. They had me update the code to make the ticket requester allow the user to define the number of tickets per result rather than a hardcoded limit of tickets per request.
I was honestly expecting the interview to be a lot harder than it was. There wasn’t any white boarding, leetcode style algorithm questions or difficult technical questions. I don’t know if the Australian interview process is laxer than the American, but I was definitely surprised.
I should also note that most of the other interns who were accepted into the program came from bootcamps, some directly out of university and the rest were career changers.
My main takeaway from the experience was that they weren’t looking for people with great programming skills or high GPA’s, but rather individuals who could communicate their thoughts well, were eager to learn and showed genuine enthusiasm.
I would however recommend:
- Being comfortable in at least one language.
- Being able to make network requests with that language to some sort of API.
- Understand your code, seriously, don't just smack the keyboard and Ctrl + C, Ctrl + V from stack overflow (or my project :P).
- Add reasonable comments. Remember, another human will be reading it!
I realise that a lot of the advice I'm giving isn't groundbreaking or super-secret insider knowledge, but if I'm able provide some level of comfort for all our imposter syndrome, then my job is done.
If for whatever reason you still happen to be reading this, I wish you the best of luck in your interviews and career ahead.
Until then, see you later mates! 😊
Unfortunately, the testing account associated with my internship was eventually disabled hence all network requests will fail.