Slashdot Mirror
Programming Interviews Exposed
Introduction
Many people consider an interview a Kafkaesque experience, where all your skills (technical and social) come under the microscope. My toughest interview was one where I sat in a conference room faced with five hungry interviewers and "How many lines of code have you written in your career?" was considered small talk.
The promise
This book will not teach you how to handle small talk, but still may do wonders for you in your next interview. The author's promise, that reads: "If you work on learning to solve not just the specific problem we present, but the types of problems, you'll be able to handle anything they throw at you," is certainly ambitious, but they've succeeded admirably in my opinion.
General overview of book
Chapters 1 and 11 are short and sweet, but impart important lessons on how to negotiate offers, preparing for open-ended questions like "What are your career goals?" and generally convincing the employer that you can fit into their culture. Appendix A's coverage of writing technical resumes is brief but sufficient. Their bottom-line message is: craft a resume to sell your skills; don't write an autobiography.
The rest of the book comprises a review of common programming questions you may face, as well as a selection of puzzles that appear regularly in technical interviews.
The secrets summarized
The authors' secrets to technical interview success can be summarized as follows:
- Make sure you master the programming language that the job asks for.
- Practice solving problems and study heuristic methods.
- Master common data structures like linked lists, strings, trees & graphs.
- Be conversant in programming paradigms like recursion and Big O notation. And depending on the area of expertise that the interviewer is looking for, brush up on topics like concurrency, networking and database concepts.
Let's dissect these bullet points one by one
(1) The authors expect the interviewee to master every feature of the language that the job calls for, including the quirky and obscure ones. Personally, I think that knowing the core elements plus the specific features that the employer is looking for is more than enough. For example, in the Java paradigm; multithreading would be considered core, while knowing JNDI would be a speciality. But take note that an interview is not something you study for. It's not like a certification exam. You certainly need a couple of projects using that language under your belt to be absolutely prepared.
In interviews where you can choose the programming language, the authors caution against using lesser languages like Javascript or Visual Basic. But my opinion is that -- if it's used appropriately, and within the bounds of the job description -- any of these should be fine.
(2) G. Polya once said "Experience in solving problems and experience in watching other people solving problems must be the basis on which heuristic is built." The authors have kept to this spirit and included a generous number of challenging puzzles to exercise your brain. This is no coincidence, as both authors graduated from Stanford, where Polya once taught. Solutions are provided, but more importantly they've also included descriptions of the thought processes that underlies them. And by the way, the types of puzzles listed here probably wouldn't be out of place in a MENSA exam or the U.S. Computing Olympiad.
The authors also offer practical suggestions on how to solve problems, such as "Think out loud by explaining what you're doing," and "If you're stuck, consider looking at a specific/general example of the problem."
(3) The book offers one full chapter on linked lists. The author is justified in this, as linked lists can be operated upon by a multitude of operations. And each operation can usually be coded with a minimal number of lines of code. Ignore this advice at your peril.
(4) From experience, the authors have found that if you don't put down a particular skill in your resume; questions on those topics will not generally arise. So by setting the right expectations; you'll be able to get through the interview with fewer tangled nerves. But general programming knowledge questions like "What does it mean to be a 32 bit OS?" or "What is the difference between C++ and Java?" should be expected. Chapter 10 offers a healthy sample of them.
Weakness
One of the strengths of this book is that it focuses fully on the topic at hand which is "programming interviews" and never gets sidetracked. However it does have its weaknesses, in that there's very little mention of the high possibility of questions on component programming models (EJB,COM/COM+,CORBA). I think component-based software development (using off-the-shelf components) is the future of our industry (whether open or closed source) and companies are not interested in creating software from scratch. Also missing from the book is any mention of localization or internationalization of software.
Is it worth buying?
At 272 pages, this book can easily be skimmed in one sitting. But its value will not be apparent until you start solving the included problems/puzzles yourself and understanding the pattern of interview questions. This book is not a magic bullet that will guarantee you success in every technical interview, but having a rough estimate of what you will face is certainly better than being surprised.
Who is the target audience?
This book is especially relevant to recent computer science graduates who are just entering the industry. It may also be useful to technical recruiters and software managers (who assume the role of interviewers) who want to get some insights into the interview processes used by other companies. It might not be appropriate for people from other technical disciplines like system administrators or DBAs. Seasoned programmers may still get some benefit from the book although you've probably had first-hand experience with most of the questions/problems posed in the book.
Table of contents
- Chapter 1: The Job Application Process
- Chapter 2: Approaches to Programming Problems
- Chapter 3: Linked Lists
- Chapter 4: Trees and Graphs
- Chapter 5: Arrays and Strings
- Chapter 6: Recursion
- Chapter 7: Other Programming Topics
- Chapter 8: Counting, Measuring and Ordering Puzzles
- Chapter 9: Graphical and Spatial Puzzles
- Chapter 10: Knowledge Based Questions
- Chapter 11: Non-Technical Questions
- Appendix A: Resumes
"I work cheap"
DrLunch.com The site that tells you what's for lunch!
One thing that always helped me was knowing that they need you more than you need them, especially in todays' technical job market.
No biting
When asked about prior work experience, you don't need to mention the summer at the badger insemination factory.
No hairpulling
Never Look the interviewer directly in the eye, this can appear confrontational
Leave before the interview is over, so you don't seem overly desperate
air and light and time and space
No, the author is NOT justified in putting ANY specific programming information in. If the company asks me "can you implement a linked list in Java in 10 lines or less", then that's not a place I want to work.
The place I want to work (in fact, the place I AM working) is where they know you are a good problem-solver and that you can pick up any tools you need. Specifics like linked-lists tell nothing about the quality of the employee.
And this isn't just me talking as an employee. I hired a guy once who had a civil engineering degree. He didn't know things like linked lists, depth-first vs breadth first, turing machines, yada yada yada. And his programming wasn't even all that top-notch (good, but not what I'd call outstanding). But could that boy solve a problem and FAST. Give him a task, however complex, and you'd know it was SOLVED--ASAP.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Beer in the fridge. Domestic and imported. Now that is a programming job I want to find.
Sometimes you by Force overwhelmed are.
I think it's important to realize that tech companies need good programmers more than good programmers need tech companies. There is no reason to subject oneself to a one-way anal probe. Push back!
Remember, YOU are interviewing THEM too. There are companies out there that will suck the very life-force from your body. You must make sure that the company is a good fit before bending over to sign the offer letter. Don't be afraid to get the upper hand. If you're good, you can afford to take the initiative and put them on the spot. Your career will thank you.
The real DunkPonch is user 215121. Everyone else is Bruce Perens.
If I were hiring technical staff here in the Boston area, there's one question I'd need to ask: "When was the last time you went to the MIT Flea Market?" If I get a blank look they'd be out of there...
There are plenty of American citizens skilled in programming looking for jobs. The software companies would like you to believe that there is a shortage of workers. Yeah right.
w0rk3d 4 m3
->mafiaboy
->mafiaboy
don't confuse political expression with vandalism
I suck at the whole job seeking process, not just interviewing.
Luckily for me, the interview for my current job (a rather good one, IMHO) went like this:
I was with a guy I knew, who was talking to a co-worker on his cell phone. He turned to me and said: "How would you like to spend the summer in New York City, getting paid $20/hour while [the company] covers your hotel, travel, and food expenses?"
Me: Sounds great.
Him (to cell phone) : Okay, he says yes.
The company I recently took a job at was more impressed with the fact that I can pick up new languages and learn new technologies quickly, rather than my extreme expertise in one area. I am not looking to get hired because I know the birthdate of the mother of Linus' dog. Get it?
Its a shame when I see so many schools teaching "hands on/technical programming" in their Computer Science courses... IMHO and experience, teaching CS with an "algorithmic" approach is much more effective.
Technology comes and goes, we're in a time of innovation, do you really want to spend so much time and energy into knowing every bit of detail, when you could be building other, more useful skills?
Having a lot of "linux geek" friends, I used to get yelled at a lot to "RTFM" (read the effin manual). Well, I'd say keep this in mind when applying for a job. You can always RTFM. You don't need to know every specific of everything. You need to be able to, and be comfortable with learning new things.
Cheesy quote, but true: "Its not the quickest, or smartest animals that succeed.. but the ones who adapt the quickest." - I think it was Darwin.
Over and out.
I'm not weird, you're just all boring.
You might also want to check out this editorial at freshmeat (Negotiating for Nerds)
To get something done, a committee should consist of no more than three persons, two of them absent.
A couple points I've learned in my interviewing experience (and I've never been turned down for a position I've interviewed for. Ever.)
If you're interviewing at a place that is going to quiz you on the spot, you're not going to be happy. I can see maybe showing you some code and asking you to explain what it does - but your educational qualifications and prior experience should be enough to demonstrate you are capable. I don't remember 1001 buzzwords well. This is usually a mistake that first-time or inexperienced interviewers will make.
What you do to land a cool job is you get a chord struck with the interviewer on a personal level. You take the opportunity to talk about the cool mp3 system you programmed for your car. You talk about the challenges you had going through school. Talk about the moment when object oriented programming became clear to you. You want to avoid the horrible standard questions like what do you want to do with your career - if you're reading a cookie cutter answer, you're going to be like everyone else.
When I get asked questions like that, I talk about experiences I've had in the field, positive and negative, and how I'd make sure that they happen/don't happen again. Demonstrate to the interviewer you're personable and they can work with you - you don't need to prove yourself at this stage, a mistake many people make. If you're being interviewed, you're good on paper. They want to see if they can trust and deal with you on a daily basis. Let your personality come through.
This is something you'll never see taught in a resume course. BE YOURSELF. If you're not, you won't be happy in the job - because they didn't hire you, they hired that person in the book.
..don't panic
that's the harder part really; you've got to be able to find companies you find suitable. Methods in doing this would be appreciated. I.E. in 1 year of being on boston.techies.com with a willingness to relocate, I've only gotten 1 email about something I found interesting, even with the very specific resume tool. and I get 2 or so a week. Also establishing what the job and company is about over the phone before an interview needs addressing. Sometimes a company will just ask you to come in without divulging much information, that's not helpful
There are plenty of people looking for programming jobs, who are unwilling to move or work on the things most companies need. There's a real shortage of people in the places where companies do development. There's also a real shortage of people willing to do anything other than Java and HTML. The DC Area, where I work, has a deficit of about 19000 developers (compared to the number of jobs) right now. This isn't conjecture; I've been a hiring manager/interviewer since '96, and I've seen the quality and quantity of interviewees steadily decrease.
Law is whatever is boldly asserted and plausibly maintained. -- Aaron Burr
Anyway, my question is this: if the company takes you out to dinner, is it appropriate to order a beer?
:-)
I'm assuming this is a straight question, I'll give a straight answer.
The "dinner" part is important - if this were during business hours then alcohol is out of the question entirely. With dinner, then, maybe.
Even then, you're best bet is to pass on the beer. Consider the worst-case scenarios... if you order beer and they're stuck up hyper business types you've just lost points (and possibly the job). If you don't order beer and they do, they'll probably just put it down to your trying to make the best impression, and not hold it against you.
Now I'm assuming you're going for some sort of technical job - if, on the other hand, you're pitching for a position that would have you out and schmoozing, wining and dining the customers, that's a different kettle of fish. They might be very interested in how well you can hold your liquor
This advice is localized to the Midwest US, your milage may vary according to location. Good luck on the interview.
I helped my boss's daughter in our C++ class and BOOM, I got a full time job writing Java Servlets for him :)
List everything on your resume. Even if you've only experimented with it. If the job requires it, bone up on it before the interview if you need to. Recruiters are nothing more than buzzword parsers. If your resume says you're strong with korn shell programming, we can assume you know grep and regular expressions. But recruiters won't know this. If your resume doesn't say the actual word "grep" they'll pass you by. The first page of my resume is nothing more than a list of words (organized neatly).
I get a hard technical interview maybe 10% of the time. Don't worry about all the minor details of the tool they're using.
No one cares what you claim to know. They only care about what you have actual experience with. Most people count years, even though it's the worst way to measure skill. Therefore...
Intentionally take contracts that have tools you don't know or are weak in. Ideally, if they're asking for six different things, know five of them really well and be weak in the sixth. This is the only way to grow. Six months later, you'll have something else to add to your resume.
Don't fill out skills inventories. Just get up and leave.
Don't go on an interview with a consulting firm until they already have a specific contract lined up for you... unless you're just in it for the free lunch. :-)
Don't take salaried positions with consulting firms. If you want to be salaried, work direct. But then again, why take a 50% pay cut? Just be a consultant.
Don't get starry-eyed about the consulting firm being the biggest, best, or fastest something in some area. They all are. My favorite one is, "Let me tell you what makes us different from all the other consulting firms." :-P Talk about irony.
Don't work for (insert your Borg-like monster consulting firm here, i.e. Andersen, E&Y). And don't take contracts relating to them either... unless you want to achieve synergy with your incompetence intollerance matrix.
Sorry for the rant.
brian
At least from my personal experince (recent college graduate) this book probably wouldn't have helped at all.
My interviews were at least half behavioral interviews to see how compatible I would be. The other half was technical but almost never at the syntax of a language level. Since I was rarely interviewing for a specific position I wasn't expected to know (nor did I consider trying to learn) every little detail of a language. I would be utterly shocked if companies expected new graduates to be experts in any language.
Anyways, maybe 1 in 10 technical questions was about C or Java or bash, etc. Mostly there were logic puzzles, design steps, and general system problems. What's the key here? They want problem solving skills. You can teach a history major to program (some companies do) but problem solving is a gift that not too many people have. The better and more quickly that you can break a problem apart and come up with a logical, clean, modular solution the more you will impress the interviewers. (Notable exceptions are places like Microsoft and many startups: expect to be *grilled* in the chosen language(s) at those comapnies).
I can't say enough that you should be yourself. In many cases you are interviewing with people who will be your manager or co-workers. To impress them is nice but to be "real" is much more important for your quality of life. If you don't like the people that interview you go elsewhere. You won't like the place.
Always ask what the interviews *dislike* about their company. If they can't say anything reasonable that they don't like they aren't being honest with you. It's not a mark against them unless they give a really whacked response, and it certainly shouldn't be a mark against you.
And I did find myself in the fortunate position of being able to literally take the pick of the litter among the places I applied to.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
I find myself in the following situation. I've completed 2 years of my bachelors in Computer Science at Washington University. Due to school expenses and other personal reasons, I have decided to take a break from school and work full-time, perhaps finishing my degree taking night classes. I have some experience programming in C and Java (both in my classes and at two interships), but I am definitely still scratching the surface. Given that I don't have a degree (yet), and I'm still developing my programming skills, how can I go about finding a job that will give me further experience and moderate to decent pay? I cannot demonstrate expertise in a language. What should I emphasize? Anyone else find themself in a similar situation?
----
Celebrate the finer things in life
If you want to encourage American high-tech companies to hire Americans, here's what you should do: encourage the INS to allow people with H1B's to transfer to other companies. The same should be true for people who are applying for a greencard.
Right now, H1's are tied to the current employer. This means that H1 employees can't switch jobs without getting a new H1. Also, if you're applying for a greencard, and you switch jobs, you need to restart the application process.
This results in foreign workers ("aliens" in INS terminology) having to undergo significnt hardship if they switch jobs. American high-tech companies end up having a preference for foreign workers because they know they can treat them like crap and pay them less, but they won't dare to quit. If foreign workers could easily change jobs, then the high-tech companies would be forced to pay them the same as Americans. This would be good for all workers ("aliens" and Americans).
The INS has actually created this problem. They try to put quotas and restrictions on alien workers, thinking that that will reduce the number of them. The restrictions on switching companies are exactly what the high-tech companies like about foreign workers over Americans though. I bet if those restrictions were removed, the H1 quota wouldn't even be reached (as it has been every year for the past few years).
As one of the authors of Programming Interviews Exposed, there are a few things I thought I might respond to in the review and some of the early posts.
Dissection of point 1
I agree with Gavin's assessment of what knowledge is important. What we really meant is you need to know every quirky feature (even obscure ones) of the core language. For instance, you should be familiar with bitwise operators, even if you rarely use them in your programs. If you say you know C, you should know what a union is. It's certainly not necessary to be familiar with every library and technology that's ever been tacked onto the language.
Weaknesses
Component programming and I18N are both important topics. I do feel that in most cases, they fall into the "they won't ask you unless it's on your resume" category, but perhaps we'll be able to include some material on them in the next edition ;-)
Posts expressing discontent with the whole idea of being quizzed
I have to admit, I was more than a little put off the first time I was quizzed in an interview. However, I've come to understand that some amount of this is a necessary evil. Unfortunately, there are a large number of applicants who claim they can program, but, to be blunt, can't. I'm talking about people who claim to be "Senior Java Developers" and don't know how to declare a variable. Some of these folks can actually talk a reasonably good game, so it's very hard to screen them out without asking applicants some sort of programming questions.
A couple of people have mentioned that factual recall Trivial Pursuits-type questions doesn't really prove anything. I definitely agree with this, and I think most companies do, too: most of the questions I've faced have required intelligent application of a little knowledge everyone should have, rather than encyclopedic recall. I wouldn't want to work for a company that emphasized the latter kind of question.
All that said, I do think that there is too much emphasis on time-pressured puzzle-solving in most interviews. As I mentioned, some of this is useful to screen out fakers, but the real measure of a programmer is what he/she can do in a few weeks or months, not in 25 minutes. I think interviewers ought to spend more time asking about the applicant's experience and past projects. Nevertheless, right now most interviewers do focus on puzzle questions; we thought it would be most helpful to write a book to prepare people for interviews as they are rather than interviews as we wish they were.
Finally, a big thanks to Gavin Bong for taking the time to read and review our book.
John Mongan
Ive not read this book....however, my personal feeling is that any organization looking for people is in search of people that are willing to put forth the effort to identify problems and develop algorithms and produce the solutions...so the real challenge out there is to be a person that is or find a person that is willing to do whatever it takes to learn what needs to be done and then implement the appropriate algorithm...How many languages you know is a non issue...these days it is "What is the language of the week?" today it used to be c++, currently it seems to be java, next week M$ would like it to be C# ;-) What it all boils down to is being humble enough to realize that you dont have all the answers, admitting that, but that you are capable of developing the algorithms and producing the answers...Knowing where to look and acknowledging resources that you regularly use is always helpful...
so where am i going with this...its simple...its all about what you are capable of...College is evidence to employers of follow through, proving that you have learned how to learn...thats the most important quality in any employee...or employer for that matter....
end of rant...
Internships are relatively easy to find via the university's career-center-like-dealie. (I don't know if they make those services available to students on leave, but it couldn't hurt to ask.) Make sure, if you decide to do an internship, that you have a mentor who will look out for you, who will direct interesting and challenging-yet-doable projects (from which you will learn) towards you, and with whom you get along. Without a mentor, you're just a cheap temp.
WUSTL? If you know Josh Brockman, say hello to him for me.
Ceterum censeo Microsoftam esse delendam.
I don't ever want to work at a job where I have to fix what you broke, and I doubt I will have to.
Yes, I work at one of that 10% of companies that actually asks techie questions in the interview. If you claim to know it, we will ask you about it. Whether or not we are interested in that skill. We don't care whether you know our skillset, we care that you can learn it. The simplest way to do that is to see how well you hve learned what else you said you knew.
If you listed stuff that you didn't learn, you might as well not show up.
And you know what? It is a lot more fun dealing with people with a clue than bullshit artists.
Regards,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
People who go with what they think they know (but don't) are simply a hazard to your code-base.
A person who can recognize and be up front on their ignorance is much more valuable than someone who tries to BS their way through.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Unless you're interviewing with the RIAA. :)
I'd rather have someone respond than be modded up.
I used to work for a consulting firm; I was the only consultant with my particular skill set (embedded and realtime programming) so when it came time to hire more programmers for that client it fell to me to interview them. I discovered that the best approach was to go down their resume item by item and just ask them either something about "how they did that" (if it was a project) or situations in which they "had used that" (if it was a skill). The best applicants were the ones who took it as a conversation, and we basically had a nice chat about that item, possibly going off into tangents where I got to find out more about their interests etc. I tended to emphasize things that I had some knowledge about, as that made it very easy to tell when someone didn't really know what they were talking about. I really hated having to pull out "the dreaded list of ten C questions", and if the interview degenerated to that level it was almost always the kiss of death.
IMO this is the ideal way to do an interview, and it's certainly the kind of interview I would want to be given. The only problem is, a lot of times the person giving the interview is not themselves a programmer, so the ability to establish a rapport with the interviewee is limited and they're forced to resort to standardized measures like quizzes or puzzles.
As an aside, my current new job - where I start next month - was landed the best way of all. I went to a training course given at the company's headquarters and immediately liked what I saw. It gave me three days to talk to everyone, go out to lunch with them, see how they worked and talked to each other, see their projects, etc. and of course they got to know me reasonably well also. I went away from the course feeling happy but not really expecting anything more to come from it; I was very pleased when a while later they expressed an interest in hiring me on. Needless to say, there was no real need for a technical interview at that point.
If only all "interviews" could be like that...
--
send all spam to theotherwhitemeat@ropine.com
This is the core of successful networking, in the older sense of personal networks. If you are comfortable with who you are. If you spend time with people who share your interests and can help you to expand them. If you convey a sense of what is important to you. Those things will give you an edge. The reason that networking works is that people are more comfortable with someone they know than someone they don't.
I've been on the other side of the interviewing desk. I've found myself saying things like, "They all three sounded good and looked good on paper, but who will I be able to work with." I'm glad that I was brought in to ask the technical questions in the inteviews and that I didn't have to make the hiring decisions.
Ask yourself a valuable question. Do you know people, outside your current company, who you would want to work with? Would they want to work with you? Those people are the start of your network.
The net will not be what we demand, but what we make it. Build it well.
You mean: Salaries in the DC area are unrealistically low for 19,000 unfilled positions.
Such as 'If you were a tree, what kind of tree would you be?' or the ever popular 'What are your two biggest weaknesses[sp?]?' I've gotten both of these in technical interviews, and I usually use them to test the sense of humor of the interviewer.
Tree question:
answer 1. The kind that falls in the forest, so you don't know if it makes a sound or not.
answer 2. The one growing in Brooklyn.
answer 3. An aspen, 'cause the cologne smells good.
answer 4. One next to a house with a fast internet connection.
Weakness question:
This one gets fun, because half of the interviewers are looking for you to find a strength and spin it into a weakness. "I'm too dedicated to my job." Uh, right. Usually here, I just tell the truth:
1. I'm out of shape and I'm easily distracted. (absolutely true).
I had one guy interviewing me that this completely floored, because he was used to the
spun-strength answers. Of the 200+ people he had interviewed that year, I was the first one who had given an honest answer! I got the job, and a paycheck much larger that I asked for.
my $0.02
Matt
You are thinking from the PoV of the person trying to get the job. I am thinking from the PoV of the person trying to fill the job.
The fact that the average interviewer doesn't know what to look for isn't very interesting to me...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I was strongly reminded of what I see a lot of people doing. Putting things on the resume that they were exposed to, don't know, and cannot answer questions on when asked.
BTW I would be seriously impressed if I gave an interview to you on my particular area of expertise (Perl) and you knew more than I did.
Once again, sitting on the other side of the table as someone who asks technical questions, I don't care one fig whether you know the toolset. If you can learn, then I can quickly teach you that. But I do not know how to teach people good judgement and a sense for fundamentals.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Let me pass on some things I've learned as a contractor.
Most initial screeners aren't very technical themselves so all they're doing is looking for certain words to appear on the resume. Don't make shit up, but don't hesitate to list a skill even if your knowledge in it isn't that impressive. Most programmers underestimate the number of skills/software they know.
If you can't immediately code through the problem given, there's two other things you can do that will greatly impress the interviewer.
The first is to demonstrate that you do indeed understand the complexity of the problem. Think aloud, showing that you see the roadblocks in front of you, even if you don't see exactly how to get around them. That's good enough in most circumstances. They just want to know that you know how to attack a problem.
The second thing you should do, when you're truely stumped, is simply say "I don't know." Don't gild yourself, don't make up excuses, don't show off...just say "I don't know how to do this." You'll be suprised at how much this can impress an interviewer.
Absolutely the worst thing you can do is stand in front of the whiteboard like an idiot, humming and hawing and trying to bullshit your way around a problem. This just wastes the interviewer's time which will almost always result you in not getting the job. Better to just admit immediately that you don't know how to do something.
The interviewer's next question will probably be "well, what would you do next?" What he wants to hear is that you know of several resources for the language in question so you can look up the right answer. What he doesn't want to hear is "Well, I guess I'd go ask you how to do it."
There is a huge demand for good programmers right now and obscene amounts of money floating around. Take advantage of it while it lasts.
The strangest thing about increasing your salary demands is that it makes it much easier to get a job. If you ask for $30 K, you're going to get grilled at the interview and you'll be suspicious to the interviewer, who is problably thinking, "If this guy is asking for 30K in this market, he must be useless". Ask for $80 K, and your technical skills will be more or less assumed and the interviewer will become more like a salesman, trying to convince you of the merits of working for his company. I know this sounds like total horseshit but I've experienced it personally.
Obviously you won't get away with this unless you really do know your shit. It's been my experience, though, that many hackers seriously underestimate their own market value. If you're the type of person that is compelled to learn new tech for its own sake, then the odds are you've learned far more than the guy that just got his CS degree because someone told him he could make a lot of money as a programmer. Don't sell yourself short.
Deposit your resume on the root directory on a server at the NSA. Don't trash any files or do anything malicious, so you don't wind up in prison.
> if the company takes you out to dinner, is it appropriate to order a beer?
As long as we're in a seller's market, do what you damn well please. If they go ape over it, you will have just filtered out a place you didn't really want to work for.
--
Sheesh, evil *and* a jerk. -- Jade
You're quite right that most of an interview depends on getting on with the interviewer. In fact, the importance of every second decreases exponentially as the interview goes on. Many interviewers will have decided whether they'll recommend hiring you or not before you even open your mouth. Indeed, quite a lot of training *to* interview (rather than be interviewed) involves learning to keep an open mind for as long as possible.
However, I do think technical questions at interviews matter. Not necessarily the "How does this work in Java ?" type of questions (which are really just checks that you didn't exaggerate your knowledge on your CV), but problem solving and puzzles. Interviewers for really serious technical posts (not database grinding or HTML hacking) want to see your though processes and problem solving style, both to check that you really can do it, and to check that your "style" is compatible with "how we do it here". This can only be done at interview. On CVs, or over the phone, these things don't come through.
I drilled some poor sod in a technical interview recently when he put "cryptography" as one of his skills. My first question was, "Which AES candidate do you prefer?" His response was "What's an AES?" at which point I knew he hadn't kept up with the field. Point being, if you say you have some skill, either qualify it, or make sure you're current in it.
From a technical point of view, I don't care if you're up on the minutiae of any particular programming language. Any decent programmer can learn a new language in a matter of weeks, especially if it is a language as simple as Python (which is what we use most at EST). What I do care about is whether you know basic object-oriented programming ideas and terminologies, basic structured programming concepts, etc. Beyond that, if you appear to be relatively bright, relatively well grounded in basic computer science, and either crazy enough or outgoing enough to deal with the crazies in our engineering department, we can't afford to be picky in today's labor market.
I can't stress the 'crazy enough or outgoing enough' bit. We got one guy, a very proper scientist type, who came in, who would never tell anybody hello, who would never say "bye" when he left, who never joined into the impromptu design discussions that happen whenever two people working on the same project run into each other in the hallway, who got upset whenever he, a junior programmer, did not get the senior programmers to do things his way, who seemed altogether uptight and tight-assed... he eventually, after we pulled him into a meeting and asked him to be a team player, turned in his letter of resignation, saying that the other programmers were hostile to him and he couldn't work with them. Oh well. But now you know why companies tend to trot candidates past the engineering department... we can't afford people who can't work with the nut cases who already work here :-).
-Eric Lee Green, Senior Software Engineer, Enhanced Software Technologies Inc.
Send mail here if you want to reach me.
> The software companies would like you to believe that there is a shortage of workers
Because it's true. You think they like paying a premium in a market where the interviewee has the upper hand and feels he can take off for another company if he has a few bad days? This doesn't mean every company is hiring ignoramuses, most would rather leave the position unfilled than pay someone who can't do the job.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Please read Market Yourself - Tips for High-Tech Consultants.
I'm a consultant, and I see a lot of other consultants out there groping for a clue. I also have lots of friends wandering in the dark trying to build a career.
I've been working as a programmer for thirteen years, and I've been an independent consultant for two and a half years. I do not do business with recruiters - I find all my clients myself. The above page tells how I do it.
This is not spam. I'm serious!
-- Could you use my software consulting serv
(Yes, Apple has always used Unix, I had a Sun 3/280 on my desk in 1990).
I got invited into the game after complaining long and loud at A/UX 2.0 wasn't living up to the CERT advisories during it's beta cycle.
-- Could you use my software consulting serv
"What is the most efficient implementation, written in C, of the standard library function strcpy?"
Well damn me, I wasn't able to answer this, and so I was put on technical support at six bucks an hour - graveyard shift, BTW, they offered 24 hour tech support.
If you want to see where I've come since check out my resume
-- Could you use my software consulting serv