|
Back then, I've always used the Joel Test[^].
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
That's an excellent idea.
Software Zen: delete this;
|
|
|
|
|
Bah! Go for the gusto. Here's my favorite -- from either side of the interview:
"Assume there are Plutonians. Assume there are elves. If the elves attacked Pluto without warning, tomorrow at 9 AM local time, which side would you be on?"
Note that there are three answers to that question, not two -- and perceiving the third is almost as important as choosing it.
Of course, if you think the above question would make you "look silly," the old fallback "Are your stools black and tarry?" is always available.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
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...
ALWAYS:
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.
Sometimes:
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 too dabbled in pacifism once.
|
|
|
|
|
The three question I always ask are:
What's your beverage situation? (Do they provide free soda, or will I have to go to the corner deli for my Diet Coke needs)
What provisions are there for my bicycle? (Is there is inside bike rack? Can I take it up the elevator and put it under my desk? (It folds)).
Why is working here less evil than working at a bank? (Always interesting to see how creative their answers are)
Truth,
James
|
|
|
|
|
James Curran wrote: less evil than working at a bank?
Hey hey hey! None of that! Or are you saying that because you also work for a bank?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: are you saying that because you also work for a bank?
I don't work for a bank ... anymore...
Truth,
James
|
|
|
|
|
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.
|
|
|
|
|
BobJanova wrote: 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.)
|
|
|
|
|
BobJanova wrote: every company has some good code they could bring out for such purposes
My favorite jobs have been the ones where there was no code yet; I had to write something completely from scratch based on just a rough idea of what it's supposed to do and the tools available. 
It's like being back in college. ![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Not likely interviewers would prepare some code for a candidate to see.
TOMZ_KV
|
|
|
|
|
Comments on this.
- Why do I want to see their code? i am being hired to help them write better code usually so it doesn't matter what it looks like now.
I really only need a few things. Good quiet working conditions(dual monitors, comfy chair, bathroom somewhere close and clean(It has been an issue for a friend)), Training so that I can continue to grow and extend the team and myself, The Ability to make changes(Introduce Code Repository, Introduce formal testing) To setup things the way they should be setup.
Don't overlook the ugly coding job with the boss who is willing to let you have the above. Especially if you get to setup the testing plans and the code repository and code reviews and builds and deploys. I have this now. Things are working well 3 years in. Mainly because I came into nothing but a nice window cube and a good machine and the willingness of my boss to let me get things setup correctly(according to ME). Now: The team works together, We share, we do code reviews. It was nice to just have people listen and to try to follow some standards and they were begging for standards and some consistency. Starting from scratch was AWESOME!
To err is human to really mess up you need a computer
|
|
|
|
|
That is a good reason to see some code from the interviewers due to the nature of hiring. It might be tricky how to react when some ugly code is presented. The candidate would not want to offend the interviewers if he wants the job without showing "overly confident".
In most cases, interviewers would want to see candidate's code to evaluate him.
TOMZ_KV
|
|
|
|
|
like the aftermath of an explosion in a Scrabble(tm) factory
Great! LOL!
|
|
|
|
|
Can I listen to the radio at a reasonable volume?
|
|
|
|
|
is like a building ... and the worst place to be is in the basement... I like to take jobs where the group (not the company) is in the basement -- because there is only one direction to go, and that's up, i.e. you can only make things better. so, I think the question to ask is: "when do you want me to start working?" I was listening to a TED talk by Chris Hadfield, and I believe his quote was: "There is no problem so bad that you can make it worse." 
David
|
|
|
|
|
Why did the previous incumbent really leave ?
|
|
|
|
|
Do you guys follow any ITIL methodologies and if so which functions do you implement and which tools do you use to help? This will show how joined up their thinking is from service requirement to delivery - the bits in-between should cover bug tracking etc etc...
|
|
|
|
|
You should have questions.
They should not be overly combative.
As an interviewer I want to hear:
Do you have coding standards?
What are you code reviews like?
How are new developers brought up to speed?
Do the developers go to lunch together?
How much latitude will I have in getting my job done?
and...
How do you deal with conflicts that arise?
How does management view development?
Do you pick release dates or feature sets? How?
That last question will tell you a LOT about the company. I had a company that BRAGGED that they took out a magazine ad BEFORE the software was ready to DRIVE the developers to work harder. I did NOT take the job, never would. BTW, it failed, and they actually soiled their name in the process...
|
|
|
|
|
As a qualified hobbyist, I did toy with the idea of becoming a professional developer once. I attended a couple of interviews, generally did very well, making it to the last stage, but I decided it just wasn't what I wanted in the end. Anyway, my point is that I felt exactly the same - I think asking to see sample code is an excellent idea, or asking to see coders at work. I had exactly the same idea, but never put into practice because of my change in career plans.
|
|
|
|
|
1. What are the hardware and software tools I get to use?
2. Can I add to that list?
3. Do you care about an ergonomic Workplace? How much are you willing to invest on behalf of your workers health and well-being?
Bad code I can work with. But if the Employee isn't willing to invest in the right tools and environment, and understands that his opinion on 'right' doesn't necessarily match mine, then I can't work in that environment.
|
|
|
|
|
I have some DVD's I want to rip to MP4 for our upcoming trip so the girls can watch in the car on the tablet.
What is a good [free] product to rip DVD to MP4?
|
|
|
|
|
|
I tried that and it was, shall we say, less than useful. It tried to install so many bloody bits of bloatware I gave up, hence return t'lounge.
|
|
|
|
|
Indeed. I tried to find programs for specific purposes on a few occasions through google, but in my experience you're better off to just ignore the first 2-10 pages of results!
My best bet is to explicitely search for articles testing software of the required kind: there are quite a few magazines and specialized sites around that provide not only good comparisons but also good indicators of what to expect, and links that actually work.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
