The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
What source control system do you use?
Is your database schema normalized?
What's the spec's on the dev's workstations?
Who does your testing?
Do you even do testing?
What's your code coverage? (I love the "well, that's really hard to measure" dance)
How do I work from home?
And then for the real fun question:
I'd like to see an example of some specification / requirements documents.
And one more:
Do you pay for your employees to go to training seminars or to take online courses?
I've been on the other side of the desk for some years now (I'm not a good interviewer, I think it is pure luck we have a quality team) and have never heard these type of questions. I've even had a few who have no questions at all. I hate interviewing, from either side of the desk.
Never underestimate the power of human stupidity
That's because people don't know how to interview the company. And you've never interviewed me. I ALWAYS ask the version control question (and even a couple years ago, I've heard the answer "we haven't gotten around to it." TFS, Git, etc., have helped a lot with that though.
I also always ask the remote work question. It gives me a good read on the management style.
I also always ask the "what are the specs on the dev computers" question. It's amazing how often I will discover that the devs are not happy with their computers, and if there's a QA department, they have even older hand-me-downs. Again, a good read on the priorities of the company (at least from my perspective, hahaha.) It's also interesting to see the managers (who are often in the interview along with a dev or two) raise their eyebrows when the devs answer honestly.
People who have no questions in an interview I would never hire. They most likely also don't ask questions when they're hired, and that can lead to some real big problems and a lot of wasted time. I have some horror stories about that.
There's really two parts of an interview: the technical skills and the personality skills. I am often appalled at the poor technical questions, but good technical questions are hard to come up with. I've done some interviews that have a "homework problem" -- I quite enjoy doing these exercises, and if I were interviewing someone, I think that is absolutely the way to go. It gives the interviewee the time and space to put something together with relaxed constraints, and it gives the interviewer a really good read on their skills. Another more "high pressure" but fun thing is to do a simple pair programming exercise -- sit with the interviewee, give them a problem, see how they communicate, ask them why they're doing things a certain way. Lots of good stuff is revealed that way.
Personal skills (mainly communication) are hard too, but again, the pair programming exercise reveals a lot.
"the aftermath of an explosion in a Scrabble factory"
That's actually a good discription of the stl template library source code and also their error messages... so don't go for an interview with that company, whoeve they are
I actually ask to take a closer look at the workspace. I'm not interested in the nice office of the boss. One of my last pointy hairs used to sit at a desk right before rows of desks like a teacher before a school class. And guess what, spying on his people was one of his dirty little hobbies.
A good look at the way the team works and their little specialties tells me far more than they would ever tell me voluntarily. If I get to see some code, that's also nice and well. I hope for the best, expect the worst and am rarely disappointed.
This is an interesting topic, seeing that I interview a lot of candidates. Obviously asking annoying questions will mark you as being a troublesome characters which most developer teams prefer to avoid.
But beyond being polite, and beyond checking if the candidate took actual interest into our workplace, this question does come up, and I am wondering what I would ask if I was to be interviewed myself.
I think I would ask:
"Can I spend a few minutes with one of the developers who is working now, to see what kind of environment you are working in"?
This would give you a chance to look at the work environment (hardware), and to ask some 'none formal' questions (QA, testing, dev software, procedures, etc), and of course check out the people where you may find yourself spending an incredible amount of time with in the near future.
I've gotten very good at this one, through bitter experience of being grilled to within an inch of my life and then asked to write database layer code, or sit around hassling server admins for certificates and fill out forms...
1. Ask to meet the team, maybe have lunch or coffee.
2. Ask to see some code, but accept that might not be an option
3. Ask to see the workspace.
4. Ask about the typical workday scenario, bug fixes etc.
5. Ask about how disputes are resolved. Usually your prospective boss is in the room. Use this to find out how he reacts to confrontation.
6. Ask about code standards and who is in charge of what goes into the codebase.
Ask a curveball... Example; "So, say after this interview, we're both happy, we move forward, and I comne to work for TechCorp LLC. But, fast forward three months down the line, and I'm sitting in this office handing you my resignation letter. What's the most likely reason this has happened?" This is again a challenge to see if they react well. Be careful who you ask this one to though.
If it's an old project, ask questions about how it came about. Get a good sense of the history of it. Old projects have a way of being cash cows, and this makes them cumbersome and unwieldy. Companies romanticize them.
I'm not sure how relevant that would be – every company has some good code they could bring out for such purposes, and most of what they actually work on will be under IP agreements so they can't show it to you until you join anyway, I'd think. Having a look at where the devs actually work so you can get a feel for the place and the people is the most important, I think. Here at my company our second stage 'interview' includes the prospective new employee doing some coding on a computer in our main dev office, so they get to see how we all work and whether they like the working environment.
every company has some good code they could bring out for such purposes
Ahh, but there's the rub: the real insight from this experiment is:
(1) If they know good code when they see it, (several of the organizations I've worked with over the years would stumble here), and
(2) How easy it is for them to put their hands on (extra points if they offer to take you to a dev's desk as they pull up the version control repository, drill quickly through the code base and pull out some representative piece of code -- this will check off 3 or 4 items on the Joel Test right off the bat.)