259 karma · joined August 17, 2012
Second, I would wait and see how their reliability hashes out before I rely on them for any production services.
2nd, know your usage upfront before you incur thousands of dollars in usage fees! services like dynamoDB can become very expensive very fast!
44% of car fires happen due to mechanical failure. Wire insulation is 28% of car fires. and fuel in the engine area was 18% of fires.
Leading cause of highway vehicle fires, "mechanical failure" http://www.usfa.fema.gov/statistics/reports/vehicles.shtm
I really just can't stand all the type checking all over the place, it makes the code feel like all your reading is type checking and not the real logic of what is going on in this function.
Additionally, returning an empty string when i mess up a data structure is horrible for debugging. I would have to actually go into the code now to figure out why an empty string came back instead of processing as I thought it should.
if your really worried about exposing errors to the end user. wrap that whole thing up in a try catch block instead, log an error and don't display anything to the end user.
- Know that an interview is a 2 way street. Have questions to ask the interviewers, if they ask you silly algorithm questions, have them explain to you how they use those algorithms in the workplace.
- Make sure the job your interviewing is a place you can fit into, not just the other way around.
- If you don't know something they are asking, just be upfront and say you don't know it, then ask them what it is and how its used at their company. Take note of this for future interviews.
- Don't let the interviewer lead the interview the entire time.
- For those of you haters that don't like the B-list idea, you could ask your peers that work at other places to interview you. (Interesting idea for a startup? Mock interview company? :)