- It was extremely disappointing that there were "no" questions, not even a mention, of the coding challenge they gave me. I spent a lot of time on that, and believe I addressed it in an interesting way that highlighted several key design principles I've learned over the years, in addition to my knowledge of Java and relational databases. No design is perfect, though, and I was looking forward to their feedback. As it stands, I have no way of knowing if they even looked at it. In previous interviews, a take home question like this is often followed up by a pairing session in the onsite interview to extend the design, describe the architecture, and address shortcomings. - Questions like how to implement a hash map from scratch are not things that directly relate to job performance for application developers - this wasn't an interview at Oracle to work on the JDK. Most great developers I've worked with don't know the implementation of every tool they use. Knowing how to make a scalpel doesn't make you a surgeon: I'm not interviewing to create hash maps, I'm interviewing to build applications that *use* hash maps. I also happen to know how PageRank works. If I ask a candidate that question, and they don't know the answer, I haven't learned anything about how they work on a team to deliver applications unless my team is in the business of implementing ranking algorithms over networks. - I was asked an esoteric question about IDM's security model by *the most senior person at the company*. Security is nowhere in my resume, and I never listed this as one of my core competencies. Overall I didn't see myself working at a company that is looking for people who memorize facts to pass interviews rather than for deep learners who can solve the real problems the company has. ----------------- - extra bells and whistles - graph traversals - state machine java - everything about previous projects - how hashmap works (I don't know the deep implementation of it, but know how it works) - Network and security questions