@ David Avraamides on January 23, 2008 05:23 PM
You’re missing the point. Take note of the perspective of most of the commenters. They are interviewers (myself included, see above), not candidates, and they are saying that these questions are not useful.
Yes, Jeff listed some tough questions, but tough questions = well-studied candidates, not necessarily good ones. Your analogy of top tier employees at companies with tough interview processes shows correlation, not causation. I’d be curious to see what kind of candidates they turned away in the process, or even the ones who avoided those companies completely.
@Frank on January 23, 2008 06:17 PM
I guess I read this post to mean more that you should pick some good technical questions suited for the position you are hiring for and challenge people to answer them. And you shouldn’t expect that everyone will nail all of them - that’s not the point. But if you take this approach, and apply it consistently across a large number of candidates, you’ll begin to see trends that will help you make a better hiring decision.
And yes, correlation is not causation, but I still believe that having high expectations for candidates does increase your chances of making a good hire - and that the downside of excluding a good candidate is more than offset by the upside of getting a better pool of quality people to choose from.
The whole coding test is fine, but coding over a phone seems kinda crazy. I’d say hold on I’ll email it.
Another thing is I have built 3 hardware libraries in my time. Full of bit operations, when I was interviewed way back I could do math in Hex trivially. However it’s been about 2 years since I really haven’t had to do a bit operation. So unless you need a hardware guy, bit operations are not that main stream anymore these days.
I’d much rather ask about sql or network questions.
@BoredGuyAtWork: As an interviewer I always ask about bits and bytes. Most don’t know. It’s not an issue though, you don’t need to have correct answers. It’s about the conversation and how you handle the situation. You can tell if a candidate feels like a failure when they don’t know, or isn’t phased at all when not knowing, is indifferent, doesn’t care about not knowing it, is defensive not knowing it, is apologetic not knowing, is confident they could learn quickly if you just told them, etc. There are millions of possible reactions, and that’s what we look at. Not at the actual answer.
If you did bit operations 2 years back I’m sure you would do fine.
Btw, why are you bored at work? Just quit today! Every minute you are bored at work is just a waste of your life. Only do what you love. Imvho…
I think if the top 20% is lamenting over the quality (or lack thereof) of the 80%-ers, I suggest they work harder to change the curriculum in both high school and college. Public school systems stink. Start at that level and rest will follow.
I’ve never done any interviews, as I’m military and somewhat stuck in my current job, but I consider myself a fairly decent programmer for someone who is purely self-taught.
I realize there are many things I do not know. For instance, I know what bitwise shift and comparison are but that doesn’t mean I can explain the importance of them. I’ve just never needed them.
I’d probably be a total vaccuum in the area of writing C, C++, or Java flawlessly. I can identify C/C++ and Java, but that doesn’t mean I’ve ever used them in depth. I took courses in college that utilized them to some extent, but they weren’t my language of choice(C# at the moment).
I’m mediocre on the OO concepts. I started teaching myself back in the days of GW-BASIC, and that’s where I was stuck until I started making a life for myself less than 9 years ago. PHP and C# are the first time I’ve used OO concepts and I’m no master by any means.
I am not familiar enough with regex to write the expression for the phone numbers from my head, but I know where to find out and I’ve dealt with regex before. I could do the rest of the script easily though.
I have never used several data structures… even hash tables are still new to me, but I’m always up to a challenge and I learn quickly, especially if I have a chance to tinker around with existing code.
I can’t give you textbook answers to bits, bytes, and binary mathematics, but I think I know the basics. I couldn’t write a program to count the bytes in a number, but now that I’ve read about it here, I’m off to do some research. It just never occurred to me that something like that would be useful.
Sorry for the long comment, I’m just trying to point out how someone like me would likely fall into your “Never should have been a programmer” category, and that I think it isn’t necessarily true. To echo a previous comment, it should also depend on the applicant’s ability and willingness to learn.
This is mostly good advice, though the Dec/Oct thing is just an inside joke – it doesn’t demonstrate knowledge, just sense of humor. If you offered to explain to me the joke, I would think it was funny, though.
Also, I have ~5% hearing loss and sometimes in a pressure situation with a soft talker, I could run into trouble here; hopefully, people with very minor hangups people like slight hearing loss, crappy phone connections, or time-of-day constraints, would be accomodated.
Someone mentioned how being a skilled interviewee is sometimes enough to get the job done and I totally agree. I think it is in the interviewers and employers best interest to be ready to ask questions that are relevant to the current interviewee and go a little deeper than the superficial “what the diff between and abstract class and interface” type question. It’s obvious that if you keep asking the same questions over and over they will find a way to the internet and the next time you ask them someone will have the perfect answer, and not because they’re the best programmer who ever lived but simply because they know how to search.
My point is (and this is how I do phone screens) is start with simple questions in the 5 categories mentioned above and then dig deeper using the interviewees resume as reference. I like to ask them to model some sport that they like and relate to and I like to refer back to that example. That way the questions, while similar, are in no way exactly the same as the last interview I had.
I think it’s amusing how many people talk about having difficulty with the “scripting language” requirement.
Folks, it’s one command: /bin/grep No scripting involved. Just read “man grep” and match the options up against the problem statement.
I haven’t used Windows in years, but I can’t believe the Windows shell doesn’t have a similar command. Searching through files is one of the most basic things a computer can do.
I just went through a few months of trying to find a decent Java programmer (and I needed a real developer, not a script monkey), but I worked from the top down. I tended to ask questions such as these: what is deadlock, and what can you do to eliminate deadlock in your multithreaded programs? When would you call SwingUtilities.invokeLater(), and why? How would you localize a Java program? How does JUnit identify the testXXX() methods in your JUnit tests? Name some common refactorings. Java listeners and Swing actions are examples of what design patterns? How would you track down a memory “leak” in a Java program, and why does a Java program sometimes swell in memory when it has a garbage collector? Basically, I look to see if they can handle a commercial programming job instead of just being able to knock out a two- or three-hundred line Java demo. You’d be surprised how many programmers can’t answer any of these.
For all those people saying a college grad can’t be expected to know or pass these questions - I’m a not even a CS student, and I know these things. At the very least, I can demonstrate the basics and that I have sufficient grounding to pick up the more advanced aspects.
Why are so many of you feeling so threatened by this?
To those who disagree with Jeff a little bit, I would say Jeff just tried to find someone with global picture of the computing systems, to be more flexible to come up with different solutions for an application, in order to pick-up one solutions. He just tried to test the extension of your knowledge and skills.
Exposure to different levels and different aspects of technology surely will boot your ability to think out of square. After all, I think it is important to demonstrate your approach of solving a problem, if the interviewers really want someone with competent analysis/design skills.
The comments made me really sad. Now I can understand why the quality of software is really dropping all the time #8212; it’s because programmers consider some basic fundamental things to be specific and it gets worse.
Complexity of insertions isn’t math #8212; it’s about whether one uses the right data structure. Binary arithmetics isn’t about hardware or low-level stuff.
If a programmer doesn’t know some of this then the probability that he/she will do something really badly goes higher.
It doesn’t mean that they can’t do good programming sometimes; it means that every their commit should be reviewed.
I think that question about floating point arithmetics could be useful (e.g., what are possible outcomes of comparing x to sqrt(x*x)?).
I could probably fudge my way through the parts of an interview that asked these questions without embarrassing myself too much.
Good reminder that without revisiting the basics frequently, you get rusty.
I agree with the guy who said business problems are the hardest.
Most of us aren’t going to go work for Google or Amazon or the next big thing. So we spend less time close to the metal, and often don’t have the luxury of long stretches of uninterrupted flow, cutting trees and flipping bits like there’s no tomorrow.
Doesn’t mean we’re dumb, I aced that shit in Uni Focus has just shifted.
Focus has just shifted.