It’s hiring time here at Fuery Solutions, and with the help of Craigslist, 10%+ unemployment, and a chipper ad, we have far too many applicants.
As such, we’re asking all of you job hunters to take a quick test.
As such, we’re asking all of you job hunters to take a quick test.
1. Nuts and Bolts.
Build any single major UI piece in this screen shot wholly from JavaScript. You can use any framework you wish, but bonus points if you use either only core JS (impressive) or mootools (cuz we use it). You should fashion your own structured data (as if the labels and such were the result of an XHR).
It is perfectly fine to ignore graphical components, like the subtle gradients here and there. Do replace these with approximate solid colors.
In the interests of time, you can develop against a single browser platform. Do note if/where you took this shortcut. Also, you might want to stick with just a single box. It’s just a quickie.
2. Conceptual.
We currently store archived data via the “old-fashioned” way — apache over http on a web server. We want to move to a model where all static content (picture uploaded Word and Acrobat documents) are served directly through Amazon S3, where they are ultimately archived anyway.
Now, serving static content to the public from S3 is easy. The link above does just that! But here’s the clincher — we want to do it and control the access on a per user, per session basis. Keep in mind that these are end users — not technical people who have an AWS account and think of XML when you say the word “soap”. Actually, in a perfect world, we’d be able to control the flow of S3 object data directly through the authentication model we’re already using, which is based in Apache, PHP Sessions, and some other clever app-level logic for the rest (man in the middle attacks and such). How would you approach this problem? What sort of security worries does your solution address? Or not address? Is your solution efficient? Why or why not?
3. Product/UI Design.
One of the problems plaguing any database of contacts is the problem of duplicate contacts. Think about the products you use that have contacts as a data point — your phone, Gmail contacts, Outlook contacts, Facebook, Plaxo, and all the rest. Ponder the de-duplication experiences you’ve personally dealt with. Or, more likely, the experiences you’ve wished for when dealing with this problem yourself.
Within the context of a desktop based application (whether iTunes or Gmail), describe what the ideal user experience would entail and why. Draw a sketch or three and snap an shot with your phone if it helps.
Stuff to think about:
- How much should a de-duping engine verify with you as the end-user?
- How intelligent would the engine have to be to fulfill your ideal UI? What might the algorithm requirements (or even better, approach) be?
- Do dead contacts go to heaven when they die? (What do you do with extra data? Or, at least, data that you’re not absolutely certain is duplicated?)
