More systems engineer than network engineer - though most of the systems I've worked on have been things like network management, and large, distributed, networked systems. Anyway... I generally ask people: 1. Tell me about yourself: A good way to find out how someone thinks about themself, what interests them, their career path, etc. (Or it tells me that they haven't been paying attention and/or can't present themself very well). 2. Tell me a bit more about <a project listed on their resume>, or, about a piece of work that you're particularly proud of: Let them tell me about something that's significant to them, in depth - ask questions that dig into design details, hard challenges, and how they approached & solved them. Maybe get a demo, ask for an architectural overview, then deep dive into something interesting. Maybe also ask them about their last all-nighter. 3. Tell me about how you'd approach getting up to speed and getting started on your first project here: First off, it tells me if they've done their homework. Then, what questions they ask me are rather telling. And then maybe we can get into some white board noodling. Ultimately, my main criterion for hiring is if they either poke a hole in what we've been doing (AND suggest a solution), or come up with a good approach to something that we haven't thought of already. On the receiving end: - I make a point of doing my homework about the company, the people I'll be interviewing with, the position, and the project. Kind of the way I'd approach a consulting gig. - If someone asks me to do an algorithm or coding question, I generally tell them to pound sand; that I generally use the language statement or a standard library, or look up hard stuff in Knuth - and then ask them if they'd like to discuss the specifics about how I might approach finding/developing specialized algorithms for the problems I'll be working on. (I refuse to be a code monkey on a string - and if they insist, I know that there's no way I'd want to work for them.) I'm reminded of a story an old-line DEC engineer told me - at his interview they asked him about converting an octal number to hex, or some such - he basically asked if they had an octal-hex calculator handy (remember the old paper ones?). After that, the interview went swimmingly - he thought that was kind of a test to see how he'd react (who really wants to hire someone who's going to start doing paper calculations of something silly). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown