Expensify's Interview Preparation (Revised)
6 Feb 2012
Alright, the first version of my preparation is not concrete enough. It is not focused enough. So, I come up with a new plan. I have done a scorecard of outcomes and competencies.
(It might be a little strange, well, because I come up with all of it by myself)
Outcome of being an engineer
I will focus on the short term goal in a very concrete way.
- Learn the whole system within a month and be able to augment anywhere in the system after a month of learning
- Come up with 8 small tasks and finish them. Here the tasks should increase the value to current users. They should not add new use cases or acquire new users. (2 free days a week. Therefore, it is 8 days a month. If a task takes more than one day, then break it down.)
- Complete one feature “vertically” per month. The feature must be given by the CEO.
- Know Expensify's current value and direction
- Can design good UI interactions (without even testing) and implement them
- Can gather requirements on one's own given a single-sentence feature or direction
- Can evaluate UI interactions objectively and philosophically
- Can devise a good and reasonable-in-size set of test cases
- Can learn new languages or framework quickly (in 8 hours, I suppose)
- Can come up with a good architecture given a requirement
- Can improve the architecture or the code to be more efficient
Based on each competency, I should devise concrete questions. I hope I am right. Even I want to hire this kind of guy :)
Know Expensify's current value and direction
I believe that the core value of Expensify is to facilitate the process of filing expense report. It should be as easy as possible.
To achieve the easiness, it tries its best to remove human intervention.
The direction, as I understand, is to build an end-to-end service from inputting the expense (with receipt) to reimbursement.
What I don't understand is why Expensify starts to approach the organizations that have more than 100 employees.
There are 24 millions organizations that have less than 100 employees. I'm sure that they haven't reached even 10% of them. Why do they add a new direction?
That's a great question. I'll ask them because this could be a red flag.
Or maybe I don't know the similarity between an 100-person organization and an 1000-person organization.
Can design good UI interactions (without testing) and implement them
I'm just gonna throw some questions here:
- Could you please design a form for inputting an expense with a receipt on iPhone, Android and a web page?
Btw, if you don't know the difference between the appearance and the interaction and that they require different skills, you're doomed.
Can gather requirements on one's own given a single-sentence feature or direction
- Could you connect Expensify to Facebook?
Can evaluate UI interactions objectively and philosophically
- How would you evaluate the design of expense input form?
- What is wrong with Expensify's mobile UI? (Probably they might show me some screenshot, and I should be able to tell what is wrong with it from the first glance)
Can devise a good and reasonable-in-size set of test cases
- What are the test cases for inputting expense report?
- What is your principles to design test cases?
Can learn new languages or framework quickly (in 8 hours, I suppose)
I don't have a question right now. I guess, they might ask me to connect to a set of API to perform some tasks.
I think I can finish that within like 30 mins anyway.
Can come up with a good architecture given a requirement
- How would you backup Expensify's data?
- How would you cache a web page?
- How would you design a heartbeat mechanism?
- How would you maintain 3 web servers for the sake of availability?
Can improve the architecture or the code to be more efficient
- What is the big-O of a certain piece of code?
- How to make a web page more responsive? (Using Twitter's technique)
I should always write down all requirements and ask for more requirements.
I should start with a plan that solve most of the requirements. It's ok to drop some of the requirements and come back to solve them later. Or, I can just admit that some requirements are impossible. Or, I can admit blatantly that I don't know how to fulfill some requirement.