>Similarly, most programmers just want a good job with a good paycheck. But stating this in an interview is a mistake. Just like everyone only hires the best, they only hire people who are "passionate" about .
How to Pass a Programming Interview
181–190 of 570 posts
Re: How to Pass a Programming Interview
#182Earlier quoted context omitted.
Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.
It sort of makes sense. If someone knows a language well, they shouldn't have much trouble writing it syntactically correctly on a whiteboard. Especially in languages which have simpler syntax, like Ruby vs eg Scala.
I wouldn't call Ruby's syntax simple. Elegant, yes, but not simple. I'd consider myself a pretty seasoned rubyist, but my IDE catches syntax errors for me all the time.
Re: How to Pass a Programming Interview
#183"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.
Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".
Is this seriously what interviews are trying to discover? In what practical situation would this skill manifest - a meteor is about to hit the Earth, and you need to write some algorithm to stop it RIGHT NOW?
Or is it "we need to know how you handle the stress of critical bugs that are existential threats to our client relationships", which shouldn't exist in the first place if the company is run well? If yes then I guess you know what I'd say next...
Re: How to Pass a Programming Interview
#184Earlier quoted context omitted.
As a candidate, I feel that it is fair to stand up for this as well. If the interviewer wants psuedocode, I'm happy to whiteboard it. But I've been whiteboarding before and had the interviewer say, "that code wouldn't compile, you're missing a bracket." So I said, "If you want code that compiles, bring in a laptop and I'd be happy to put it in to Visual Studio [it was a .NET position] and have it be syntactically cor…
What was their response to this? I think it's perfectly valid to state this, and may even throw the balance of the interviewer/interviewee dynamics but I can also see other people seeing this as obtuse. But pointing out a missing bracket (in a nonconstructive manner) on a whiteboard is pretty obtuse too...
It was the last interview of the day, and I was tired and had already decided I was almost certainly going to decline any offer, if given. So, honestly, I probably said it with a little bit of an edge and that was inappropriate on me.
Nevertheless, the interviewer was gracious and replied, "Fair enough" and stopped nitpicking my brackets and semicolons.
Re: How to Pass a Programming Interview
#185Earlier quoted context omitted.
It gets better! After a few interviews you start to get the hang of things and can begin to read the situation and understand what's in your best interest to do. Some interviewers like to test your knowledge of C.S. curriculum like you just mentioned, others prefer a friendly person who isn't afraid to ask questions and be honest about what you can and cannot do, others prefer both. It gets better.
I definitely will be far more prepared for my next programming interview from the experience I gained going through the process once already. It's just sad that my first interview process had to be with a higher-profile company that would have been a ticket into silicon valley. Those interviews don't come easy in the first place. Haven't heard back from anyone else yet, but I trust they'll come along.
You'll look back at it in a year or so and laugh. Personally my resume and interviews were absolutely atrocious (I thought an online resume builder was a good idea..).
Re: How to Pass a Programming Interview
#186Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…
> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…
I am sure the RubyGems authors thought the same way until somebody sped the process up dramatically because they could do space-time analysis[0].
Re: How to Pass a Programming Interview
#187Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…
I already saw such a colleague training hard at competitive programming, everyday. Yet, he wrote that kind of C++ code:
ressource AClass::CopyACriticalRessource()
{
{
std::lock l;
} // Optimization for the lock.
return ressource_;
}
The best technical interview being a homework with enough time for a normal human being, requiring tricky algorithms to solve it in a fancy way, a good architecture and great computer-science knowledge in general. Afterwards, a code-review/interview of 1 hour with debriefing on all the choices.
Re: How to Pass a Programming Interview
#188> Use a dynamic language, but mention C I take issue with that recommendation. You should use whatever language you feel most comfortable with. If it's C, use C. If it's Java, use Java. You don't have the luxury of an IDE or anything like that, so you need to have enough of the language in your head to write a program without looking something up.
I haven't used C professionally in a long, long time, but I naturally gravitate to it when doing technical interviews.
One of the reasons, I think, is that the language itself is "small" enough you can actually hold most of it in your head.
That, and for certain problems it gives you the opportunity to demonstrate understanding of things like pointer arithmetic that you wouldn't have if you used Java. I remember an interviewer at a Java shop being impressed a few years ago when I used C and pointers to reverse a string in place (I wasn't very comfortable with Java back then).
All that said, I'm getting old and cranky and whiteboard interviews are starting to get really annoying.
Re: How to Pass a Programming Interview
#189"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.
i often just refer to it as waterboarding.
I think they really downplay how much of a panic/anxiety these type of closed room with no ventiliation with solemn looking people judging your every move.
I could never calm down and think but the interviewers wanted to test how you would code on a whiteboard under duress
Re: How to Pass a Programming Interview
#190What if designers had to go through a similar interview process? Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? Why is red font on blue background bad, please justify? That would simply be hilarious.
> Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? "Please arrange these colors in complementary, analogous, and triadic color schemes". This is color theory 101 -- something every visual designer should now. > Why is red font on blue background bad, please justify? Again, a valid question. It all depends on the brightness/saturation of the colors, and…
Perceived contrast depends on media. The only question designer answers in real life - is he ready to subdue his taste and skill to PMs whim or not.