The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Avoiding the Technical Interview?

Is there a good method to avoid the standard Q&A technical interview?

If I have an interview with a big company in one of their products division where I could tell you absolutely anything about it.  All of the publicly available stuff inside and out as well as design and intricate details that might make it a better product vs their competitors. 

Unfortunately though, I never ever get a chance to show off how much I know about and ways to improve it.  The interview usually ends up with someone asking some question about polymorphism & functional pointers and I freeze trying to remember what that term means (yes, I know what they mean and used them a lot).  Sometimes it also ends up being a brain teaser and that makes things.  And when that's over, it's time to meet the next person.  Never really have a chance to talk about the products they make. 

Is there a good way to steer the conversation away from the brainteasers and questions and move towards the actual product being made?

Friday, February 08, 2008
It doesn't sound to me like you want to be a software developer.  No harm in that, but if you're all about the design and intricate details and improvements, you sound like you'd rather be a BA or a product manager.  I would say it is not at all unusual to work a job and not have any real input into the features of a product for a year, as a developer.  I don't think you want that.  Interview for the job you want.
Friday, February 08, 2008
"Sometimes it also ends up being a brain teaser"

These are some of the most worthless interview activities.  I remember while I worked at Microsoft we had engineers that went out and bought MENSA puzzle books to find stumpers.  I would tell them if they can't think of a puzzle on their own then expecting it of others is ridiculous.  For the most part they just did it to play with candidates.
Saturday, February 09, 2008
Ignore the comment made by 'gc' above.

I work for a large s/w firm; yes, many of the tech questions cannot be answered by the interviewers themsleves. It can be a type of powerplay.
Saturday, February 09, 2008
M is correct. There are two ways to do the technical questions. One is ask a bunch of stumpers or API questions and it is because the interviewer has low self esteem and is a sadist who plays with the candidate like a cat plays with a mouse. The other is when there are a couple reasonable small coding questions that separate the wheat from the chaff.

This discussion and advice I would give are dependent on if the original poster can really write code and knows his stuff. If all he can do is come up with 'strategic ideas' well ideas are a dime a dozen. We have no shortage of ideas and they are worth precisely zip, nada, nothing. What is valuable is being able to implement ideas successfully.
Tony Chang
Saturday, February 09, 2008
Step 1: Buy a puzzle book.

Step 2: Memorize the answers.

Step 3: Interview at MS.

Step 4: Make Money!

Seriously, the only thing an interview should do is help the right candidate and the right employee find each other. If the hiring process becomes the only way you ensure your company has good staff ... it's no wonder that a bunch of unemployed youths Northern Europe, living with their parents, can engineer a better product.
Saturday, February 09, 2008
> We have no shortage of ideas and they are worth precisely zip, nada, nothing. What is valuable is being able to implement ideas successfully.

+1 to this! Everyone has ideas. But whether those ideas are technologically feasible and whether you can implement them are often what matters.

There is also such a thing as analytical intelligence. It is simply amazing just to listen to someone else explaining their analysis and solution of a "hard-problem". Someone who has very credible analytical problem solving skills *and* deep hands-on technical knowledge is much more valuable to a software development team than  someone who can just "talk".
Saturday, February 09, 2008
> The interview usually ends up with someone asking some question about polymorphism & functional pointers and I freeze trying to remember what that term means (yes, I know what they mean and used them a lot).

What is the job title you are applying for?

Brain teaser is one thing, but polymorphism and function pointers are very legitimate interview questions for a programmer or a analyst programmer.

Polymorphism is not like "swapping two integers without a temp veriable (by XOR)". If you use it all the time you should be able to explain it.
Saturday, February 09, 2008
If there's a technical interview I'd imagine there would be an interpersonal interview as well yeah? Usually you're asked if you have any questions, you could ask what products the interviewer is working on (assuming they're tech and not HR people), and get them talking about it. If you can get into good discussions about their work so that the time flies and they get to the end of the interview thinking "Where did the time go?" you'll probably come across very well.

I know that's not what you asked, but if you get out of a personal interview feeling very confident, and not worrying about redirecting your technical interview, you'll probably be better off.

But, on the other hand... I'm a student who hasn't had a successful interview for a technical role yet. I'm really just extrapolating the advice from professional careers services.
Graham Allan
Saturday, February 09, 2008
I disagree with restAssured - +1 to gc.

A face-to-face technical interview is not something you should want to get out of if you are, in fact, trying to work as a developer. A place that hired a developer without more than a cursory look is almost certainly not an ideal place for a developer to work. Granted, there are places that replace the actual content of a technical interview with brain-teasers and other unimportant nonsense, and that is almost as worthless as a place that forgoes the interview altogether. However, avoiding technical interviews on your part makes it highly unlikely that you'll get in with a company that values developers and will pay more than lip service to your thoughts after employment.

Get used to interviews - they're a good thing.
BrotherBeal Send private email
Saturday, February 09, 2008
Just remember that you are also interviewing the company. If they start pulling silly stunts like this on you then you can either take it as a sign that it's not the right company for you, or you can simply respond in kind with your own stumper questions. After all, if the people hiring you can't answer a few stumpers themselves, what does that say about 1) their hypocrisy, and 2) their ability to correctly evaluate the coworkers you'd be joining at the company?
The Original Henry
Saturday, February 09, 2008
"polymorphism and function pointers are very legitimate interview questions"

Actually he said they asked him about 'functional pointers'. I don't know what a functional pointer is myself, but I did find it interesting that the OP stated clearly that he himself knew what they were, but was unable to answer due to 'freezing'.
Tony Chang
Saturday, February 09, 2008
I don't disagree that a lot of these technical interviews are power plays - I recently left an organization that conducted their interviews like that -that was good fun when a new hire asked me, basically, when they were going to be working on the threading issues they were quizzed on (answer: never,  the heavy lifting was done in batch jobs.  He quit shortly after, and I can't blame him).

That being said, there's no shame in being a product manager, and good money.  You're obviously interested in the product features, more so than many of the developers might be.  You have time to do your research, you're doing it on the product rather than reviewing things like polymorphism and pointers and design patterns and whatever API they're using.  I'm not trying to be a dick here, it's obvious where your interest lies based on how you're preparing for the interview, it seems like it doesn't align with what they want, so the only things you can really change are the way you prepare for the interview, or what jobs you direct your resume at.  You want to be asked about your ideas about the product.
Saturday, February 09, 2008
Thanks everyone, I guess these interviews don't make sense sometimes.  I'm guessing it was never meant to be though & I guess I did provide some sort of entertainment to the interviewers ;)  Plus traveling across the country was nice.

I'm still disappointed w/ all the rejection emails.  I ended up deciding to go to a startup route with a friend.  No clue if we're going to make it, but I'm ending up doing a bit of everything which is turning out to be very fun & exciting (minus the fact we're poor). 

(Aside: I'm a little confused with my terms though.  What's the difference between Developer, Designer, Engineer, Architect, Programmer, Coder, and this new term called Project Manager?  I thought they were just different names for the same job.)

When that time comes again, I have no clue how I'm going to make it.  I even failed the pointer questions and I use pointers for everything!!  Well....not so much now since I'm using .NET Languages but you get the idea.
Original Poster
Saturday, February 09, 2008
"What's the difference between Developer, Designer, Engineer, Architect, Programmer, Coder, and this new term called Project Manager?  I thought they were just different names for the same job."

Odd, I would have thought that even a self taught high school kid would have know the difference...
Thera Send private email
Saturday, February 09, 2008
"What's the difference between Developer, Designer, Engineer, Architect, Programmer, Coder, and this new term called Project Manager?  I thought they were just different names for the same job."

(Software) Developer: Writes code (Software-related company)

(Software) Designer: UI/Graphics? (Varies), doesn't necessarily know how to program.

(Software) Engineer: Developer who can do more than just code, and also knows how to properly write a system (as opposed to hacking things together); more common in companies that sell products that rely on technology (hardware, GPS, that kind of stuff)

Architect: Engineer who doesn't write the code anymore (read: 20 years of experience, but hasn't learned anything new in 15), but comes up with the specs and has strong domain knowledge

Programmer: Same as developer, often used in non-software related company; sounds more blue-collar

Coder: Same as programmer; sounds derogatory

Project Manager:  Idiot who knows jack-shit about software, but is a good bullshit artist and "manages" the developers to keep them on track (read: Overseer on a plantation - "Our sales guys already promised this feature to BIG CUSTOMER (even though it didn't exist), so it NEEDS to be done by Friday!")

Disclaimer:  My definition of "Project Manager" sounds biased, but that's because every single one I've seen has had little to no programming background, and admitted it, and yet somehow managed teams of developers.
Newbie IT Director
Sunday, February 10, 2008
The best way to avoid the technical interview is to be recruited under the personal recommendation of an owner or an executive of the company. In other words, someone very important in the company already trusts you so much that the interview is almost a formality.

A second (not entirely dissimilar) scenario is to be brought in to a startup or an end user company that has absolutely no implementation level technical people. In that scenario, they simply have nobody to tell them who is good and who is not, so mere talk may get you the job.

So those are the ways in which you can avoid a technical interview and that's the answer to your original question.

I somewhat agree that if you are brought in under normal circumstances (IE, not the above scenarios), and they have a going development group, then something is messed up if they can't or won't ask you real technical questions.

I think you're right to want to avoid this type of interview. It can be useful if done well, but most places, particularly the smaller shops, do it really poorly, so it's usually a risk more than an opportunity.
Bored Bystander Send private email
Sunday, February 10, 2008
gc didn't say "project manager": he said "product manager".

- A "project manager" manages how the project is implemented: by whom, and on what schedule. Apparently, sometimes a team lead will believe that he ought to be called a project manager because he's managing a project, but a project manager is often someone who is managing several team leads (and several projects) simultaneously.

- A "product manager" defines and decides what the product is and will be, but not necessarily how or when: the product manager talks to customers, to sales people, to the CEO, and to the project managers who manage its implementation.
Christopher Wells Send private email
Sunday, February 10, 2008
For what it's worth I'm a software engineer (or programmer or developer...whatever you want to call it) with 15+ years of experience, BSCS and MSCS.  I completely appreciate a good project manager.  A good project manager doesn't need to be a programmer/x-programmer.  I think it is helpful for a Prj Mgr in software to know the industry and know the product domain, but they don't need to be a programmer.  Project management is a career in and of itself.
Sunday, February 10, 2008
"I freeze trying to remember what that term means (yes, I know what they mean and used them a lot)."

This is actually at the core of the question. If you really know the answers to these, but can't say them in the interview, you're suffering from interview nerves. If that's common then two things - first get lets of interview practice. Get your friends to give you mock interviews, go on interviewing courses; practice practice practice. Second tell your interviewer up front that you are nervous. Third take your time in the interview. When they ask you a question that gives you brain freeze, take your time, sort out the answer in your mind, and give it. To an interviewer slow is better than confused (or wrong) every time.

If you really think your main contribution is in improving the way their product works, say so. Almost every interview starts with "why do you want to work here" or some variant. Tell them you have lots of ideas for improving their product. If they are interested they will ask what they are.
DJ Clayworth
Monday, February 11, 2008
Never work for'll know them by the questions they ask.
Rob Henry Send private email
Wednesday, February 13, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz