Lets divide this into 2 questions Sorting questions Everything else I don\'t kno

Question

Lets divide this into 2 questions

Sorting questions
Everything else
I don't know of anyone who asks "Write sort X" during an interview. If I were ever asked it during an interview I would really re-consider why I was applying for a specific job. if you want a good sort algorithm, look it up (really though, just use a builtin framework one).

I do occassionally ask for trade offs on various sorting techniques. But it's a sub-question and I don't really care if people know the various algorithmn names.

Now for the rest of the questions. CS, educational and professional, is all about data structures and algorithmns. If you made it through college without knowing what a binary tree, stack or queue was, I likely don't want you working with me.

While I don't ask data structure questions directly, I find it valuable to ask indirect questions. Instead of asking "build a binary tree", I would ask "given a binary tree do X". I want to see how an interviewee can apply their pure CS knowledge to real problems.

Explanation / Answer

I tend to ask questions that relate to the projects that I expect that people will be working on. Generally, I'm interested, not in knowing if they can write a complete code sample off the top of their head, but if they are able to understand what I am asking, ask good questions to get more information, and understand the concepts. What I would ask would also depend on the level of the person I'm hiring. A more senior person would be expected to understand things like reflection, be familiar with design patterns and architecture, understand database design and normalization, and be able to explain different development methods and the differences between them. A more junior level person would be expected to know the difference between Map and List data structures and know when to use each, be able to explain cross-site scripting and SQL injection attacks and how to avoid them, and be able to read and explain some code and perhaps talk about its complexity. Since it is very important to how we work, I'd also ask them about testing, perhaps explain how they unit test their code. Mostly what I am interested in is how well the person will fit with our organization. Are they technically curious and willing to learn. Have they demonstrated this in the past? If they run up against something in the interview are they willing to ask questions or do they try to bluff their way through it (note: I always emphasize when giving a "code" problem, that if they have questions they should ask. I don't expect people to know or remember everything, esp. things that you can always look up). I also tell them that I'm not particularly concerned with framework details or exact syntax and to not worry about that. The other thing that is critical is how well do they communicate. Can they understand what I am saying? Are they able to articulate their solution so I can understand it? I am concerned about the fundamentals that people have from a CS point of view, but I've found that it is usually more apparent from how they handle real problems whether they have been able to translate theoretical knowledge to practical abilities. Pretty much anything they have learned (or should have learned) in school can be looked up for details. The question is whether they have internalized it and can put it to use in a real setting.

Related Questions

Navigate

• Browse (All)
• Browse L
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.