Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Terrible Technical Interview

techcrunch.com

Post reply on HN
Print view View original

171–180 of 236 posts

Re: The Terrible Technical Interview

#171

Post by phazmatis »

mtviewdave wrote: post #33
StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

> "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. After thinking about it for a minute or two, what I _thin…

Unless a software developer is tasked with deciding which version control system to use or for some odd reason has to do a deep dive into the philosophy/design of subversion, why on earth would they bother to know this? You might as well ask if they prefer Cherry MX Blue or Brown. I don't know SVN but if it's anything like Git, there are 100 ways to use it, exactly 5 of which are useful to 90% of developers on any given day.

Re: The Terrible Technical Interview

#172

Post by jdjdps »

ams6110 wrote: post #70
BSousa wrote: post #64

Earlier quoted context omitted.

If you are outside any big tech hub, most jobs and candidates will be filled by recruiters or normal job posts. I've been developing professionally for about 15 years, changed jobs a lot of times, and never was through a referral/network. Most of the people I know are the same. And yes, also having done interviews and sorted through thousands of resumes, there is so much out of touch folks out there that I wouldn't h…

Yes. Living in the midwest, I've done software development for nearly 30 years. I've had more than half a dozen employers and I have never been given any kind of "technical test" in an interview, such as writing code on the spot, diagramming an algorithm, or solving a puzzle. I don't know where this happens, but it's not everywhere.

I saw it in london once. I failed the test so badly that the interviewer refused to believe that I had written the demo project which got me a first interview. He said it was one of the best he had ever seen. But then said I couldn't have written it because I was failing the interview so badly. People who dont get that nervous just dont understand how debilitating being really nervous is. Also the white board code challenge was a total waste of time.

Re: The Terrible Technical Interview

#173

Post by din-9 »

fsk wrote: post #56
fsk wrote: post #40

Earlier quoted context omitted.

Actually, it happens as long as your "stricter hiring practices" increase your false negative percentage by a lot more than they decrease your false positive percentage. Try it out with some numbers. 10100 candidates, 100 are "good". Suppose you have 2% false positives and 1% false negatives. You hire 99 good candidates and 200 bad candidates. Suppose now you have 0.5% false positives and 90% false negatives. (You de…

Also, what makes this mistake common is the feedback you get. When you make a false negative, you never find out that you passed on someone amazing. When you make a false positive, it's professional embarrassment for the boss when he's forced to admit he made a mistake and fire them. So the incentive for the boss is to minimize false positives, even at the expense of too many false negatives. The boss is looking out…

Reasons for not wanting to fire people also include: basic humanity.

Re: The Terrible Technical Interview

#174

Post by smelendez »

StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

It's interesting that so few people can define, or fully explain, MVC.

I wonder how the success rate would change if you defined "model," "view" and "controller," and asked why developers might choose to organize projects in such a way.

My guess is that most working developers would get the concept right away and might even be able to relate it to other named models we've seen--we might just all exist in a web bubble where MVC is trendy because of the levels of abstraction that exist in our common toolsets.

Even Cobol's ancient "divisions" seem to have a similar organizational structure (http://en.wikipedia.org/wiki/COBOL#Features) and so, I'm sure, did a lot of old-school, green screen terminal apps.

Our computers are generally fast enough and our tools good enough for what we're asking them to do that we can often just define data models and user views fairly abstractly--index this, make that an input box rounded corners and indented text--and that we can often avoid delving into the low-level details of how data's stored or pixels laid out on the screen. I'm sure it would be possible to describe an operating system, or a video game engine, or a DBMS in terms of which sections of code model data, handle the meat-and-potatoes "business logic" and communicate with the outside world, but you'd probably need deeper layers of abstraction to actually plan how code would be organized.

We also have enough fast memory that we can basically pass data from one level to another without issue and don't have to deal with abstraction-breaking optimizations like processing data while a disk head or spinning drum is in the right place or before an old video game system's tiny RAM chip is full.

But I think programmers who worked with those kinds of systems could quickly jump into web and app development, and if they couldn't, it's probably not because they don't know what MVC stands for (although it's possible it's a useful proxy).

Re: The Terrible Technical Interview

#175

Post by bshimmin »

zo1 wrote: post #167
marktangotango wrote: post #122

Earlier quoted context omitted.

>>I sometimes ask candidates what the letters "MVC" stand for. The successful response rate is around 50/50. I ask candidates to briefly explain the advantages of the Model View Controller pattern, It's good you don't ask for a definition. Even the inventor of MVC thinks it's rarely been applied as intended [1] (see forward by Trygve Reenskaug). [1] http://downloads.nakedobjects.net/resources/Pawson%20thesis....

This. I recently got asked a definition question. Oddly enough, one I researched prior: Polymorphism and Inheritance. Short of quoting a single book's definition of them, word-by-word, you'll find hundreds of different definitions of those two terms online. So, definitions are bad, rather ask for an "understanding" or "explanation" of the interviewee.

I'm surprised you would say that there "hundreds of different definitions" of polymorphism. Here's one of the top-ranked results for the term: http://stackoverflow.com/questions/1031273/what-is-polymorph...

If you look at the answers, aside from a few that are really poorly phrased, they all fundamentally say the same thing.

If I were interviewing someone and asking them about polymorphism, I would expect a definition which shows understanding and perhaps an example which explains to me that they really do understand it in concrete terms. (I'd probably give them bonus points for mentioning what the Greek words mean, but only because someone who knows that is likely to be someone I'd enjoy working with.)

Inheritance is certainly a dicier subject. I'm not 100% sure I'd ask about either polymorphism or inheritance in an interview nowadays (though I certainly have in the past), but if I were asking about the latter, I'd probably phrase it in the specific context of a particular language - or perhaps request a comparison of how inheritance differs between two languages. I guess, really, I'd actually want a discussion about inheritance versus composition - but, having asked for just that in the past, it was quite surprising to me (at the time) how many people had literally no idea what the term "composition" meant (despite, I'm sure, using it on a daily basis).

Re: The Terrible Technical Interview

#176

Post by raverbashing »

StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

"We bring in Java and C# candidates who have been working with their respective language for 10 or 15 years, and they get COMPLETELY EXPOSED during the face to face round when asked a series of basic certification exam style questions. Nothing tricky, just core fundamentals."

Let me guess, they work for a "big box software factory/consultancy".

They don't program, they just click buttons on Eclipse.

That should be your filter.

Re: The Terrible Technical Interview

#177

Post by [deleted] »

rupert_murdaaa wrote: post #137
bsder wrote: post #109

Earlier quoted context omitted.

> In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. Fail. You just killed the quality of your pool. You've just negatively screened against people with a life (experienced, 30+ years old, generally with a family) and screened for people with no life (aka single, male 20-somethings). For an example, if John Car…

> You've just negatively screened against people with a life That kind of works both ways, though, doesn't it? As a 30 year old developer with a family, I don't want to waste time interviewing somewhere that has the expectation I'll work outrageous hours. If I get filtered out early in that process because I'm not involved in multiple OSS projects or whatever, all the better for me. That being said, resumes are a rea…

[deleted]

Re: The Terrible Technical Interview

#178

Post by teen »

crdb wrote: post #139

I've seen two kinds of motivations: that for career climbing, and that of an engineer who enjoys making things. I personally prefer my engineers to have the second. I tried hiring the normal way (CV, white board) and had one candidate worth speaking to in over 200 applicants. We decided to try something else. We stopped reading any cover letter or CV and wrote that in the job ad. We asked candidates to build a simpli…

I would never do a 4 hour project for an interview...

Re: The Terrible Technical Interview

#179

Post by raverbashing »

skwirl wrote: post #58
tptacek wrote: post #44

Earlier quoted context omitted.

Having performed a thousand interviews by now, I am awestruck by how poor the software development talent pool is. My experience: exactly the opposite .

Steve works for a relatively unknown company making products for businesses, mostly using Java/C#, whose technical staff seems to be based in Atlanta, which is not a super attractive city for tech workers. Your experience comes from matasano, a company where people get paid to be hack, a dream job for many techies, with offices in New York, Chicago, and Silicon Valley. Is it surprising that your experience is exactly…

http://www.paulgraham.com/avg.html

"After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried."

Re: The Terrible Technical Interview

#180

Post by rwallace »

bshimmin wrote: post #175
zo1 wrote: post #167

Earlier quoted context omitted.

This. I recently got asked a definition question. Oddly enough, one I researched prior: Polymorphism and Inheritance. Short of quoting a single book's definition of them, word-by-word, you'll find hundreds of different definitions of those two terms online. So, definitions are bad, rather ask for an "understanding" or "explanation" of the interviewee.

I'm surprised you would say that there "hundreds of different definitions" of polymorphism. Here's one of the top-ranked results for the term: http://stackoverflow.com/questions/1031273/what-is-polymorph... If you look at the answers, aside from a few that are really poorly phrased, they all fundamentally say the same thing. If I were interviewing someone and asking them about polymorphism, I would expect a definitio…

> (I'd probably give them bonus points for mentioning what the Greek words mean, but only because someone who knows that is likely to be someone I'd enjoy working with.)

I know what the Greek words mean, but it would never in a million years occur to me to mention it in an interview; I would have no way of knowing without being told that you would assign positive value to such.

Post reply on HN