Drowning in a C of Interviews | Hacker News Reader

Drowning in a C of Interviews

blog.bitquabit.com

54 pointsrockhymas23 comments

I really did like getting interviewed in C. :) But I was also confident using it.

It was appealing knowing that interviews were conducted in a language that wasn't really being used. Lots of companies claim they will hire smart people regardless of skills, but then you show up to interview and the guy across the table really expects you to know python and is flabbergasted that you bothered applying without it. I felt Fog Creek really demonstrated commitment to the principle by interviewing in a "useless" language. As someone with a bit of experience looking to make a change, it was a nice touch.

You're pretty deluded if you think that C is a "useless" language.

It more or less is at Fog Creek. I am not unfamiliar with the usage of C outside of Fog Creek.

They have their own compiler for a custom VBScript derivative. If there's no C anywhere in it, I'd be surprised, but I am operating without knowledge of its implementation or output.

Edit: So what did I do wrong here? I admitted that I'm shooting in the dark, admitted that I'd be surprised if my hypothesis was true, and had absolutely no knowledge of who the person I'm replying to is. It's certainly not on his profile.

I put forth an incorrect assertion, a couple comments corrected me and I was happy to learn this insight, but my comment is already -1 because I'm what, not contributing to the conversation? Or because I was wrong? Do you have to vote on everything?

It's really interesting to me that HN whines daily about the decline in comment quality, then turns around and grays this comment. Decline of HN, indeed, downvote everyone unless they're correct or a valued member of the community. After yesterday's observations I figured I'd give it one last go, but now I just hope this community dies the hypocritical death it deserves.

Ted worked at fog creek until very recently. He's also an OpenBSD contribiuter. I'm inclined to agree with his opinions regarding the relative value of C at fog creek.

I did an internship there but didnt ever look directly at wasabi. I know that it's not really in active development (only FogBugz even uses it) though so even if K&R hacked it up themselves, I'd argue it's not really important there anymore.

There's no C in Wasabi; it's pure C#. That said, keep in mind that Wasabi's only purpose in life is as a compatibility shim so that we weren't forced to rewrite FogBugz from scratch. No products other than FogBugz will ever be written in the language. Kiln, for example, is C#/Python/JavaScript.

A 'random drive-by downvoter' struck again... Not much thought involved in the action, and certainly nothing to contribute to the discussion. They feel good downvoting such an obvious 'troll', and then vanish into the ether.

I'm not sure what's surprising about a compiler with no C in it. They're becoming much more common. I personally think C is an awful language to write a compiler in. One shouldn't be worrying about C's bookkeeping while also worrying about the bookkeeping a compiler requires.

Also, I think it's interesting when people use the word "interesting" when they probably really mean to use the word "annoying". If something really bugs you just say it bugs you.

I didn't downvote, nor do I think your comment deserved to be, but I'll point out one thing. Instead of asking a question about the language used, you made a statement. In effect, you asserted that I was wrong. You don't need to know someone's full background to give them the benefit of the doubt, especially if your own knowledge is limited. I admit to being guilty for doing the same, it's quite easy to dismiss faceless handles.

I would agree. Though C is far from useless, it really isn't used here at the Creek. Which was a double bonus for me, since after 6 years immersed in C and C++ I could find a job that let me do something new but that I felt very comfortable interviewing for. That said, I really don't believe you need lots of C experience to do well in our interviews.

My full response to Ben is at http://news.ycombinator.com/item?id=2442696.

It's a bit hard for me to believe that there are programmers, who dont understand Pointers!

Though I am still in school, I feel everyone should understand how Memory works.

My assumption is that everyone should at least know about:

1. Pointers and their physical meaning

2. Difference between Process specific virtual memory and physical memory

3. Difference between Static, Stack and Heap Memory.

4. Also it is important to understand what happens when a disk access is required, and difference between Random reads and Sequential reads.

5. Bonus if you can understand, how swapfs is utilized and L2,L3 cache work.

It's not really that shocking. Most people don't program in a language with manual memory allocation anymore.

I would guess that people might know 1 when they think about it some, but really don't know anything about the rest.

Even if they don't personally use languages that require this knowledge on a regular basis, the idea that someone could come through a CS education and not know it is pretty stunning.

Not being able to write code that performs memory management doesn't mean you don't know how memory management works. It just means that you trust your GC.

Much more relevant would be to ask questions about what to do if you're spending too much time in GC and how to tune it rather than how you'd perform your own garbage collection.

I believe there is a difference between knowing how memory and pointers work and being proficient at pointer manipulation in C.

If you enforce such kind of interviews in C, you will miss lots of great FP programmers. Maybe you don't care anyway.

I would bet that people who are good at working with pointers in C are drastically over-represented among great functional programmers, so you won't actually lose that many.

This blog post seems to have the feel of someone interpreting scripture. Only in this case, the author of the scripture is also the one he's presumably challenging with his interpretation. I assume Joel is ultimately responsible for the existing FC approach to interviewing... (?)

This isn't a C-specific problem; of course people are going to be more relaxed in their comfort zone. If you asked me to write a Web server in Python, I'd be a lot more relaxed about it than if you asked me to do the same in Forth. There's a reason nothing changed when he dropped C (what goes unsaid: is he putting C in the job description?).

Joel's observation about pointers is dead-on, but I've personally beat that horse on HN in the past and will spare everyone a greatest hits anthology.

Hmmmm. Given a language X that is not used in actual development in an organization, at what point does interviewing with whiteboard coding in X become just another credential?

I like (FTA): "So I’ve picked a question that forces candidates to design a data structure" . . . "I’ll continue conducting my interviews in the language of the candidate’s choice"

As an even more general question to hackers here, what would impress you more? A candidate who comes in, whiteboards out an algorithm and data structure in C to solve a problem, or a candidate solves the same problem in Clojure?

Particularly if your org uses neither of those two languages :-) Of course, you have to grok the different paradigms you might use in both languages or you'll probably be unable to make a decent judgment.

My tactic interviewing people for a sysadmin position was to allow them to use any language they knew. For the most part it went well. Even someone who doesn't know a thing about programming can generally pick up how the interview is going from the candidate's reactions. But occasionally someone would quite confidently assert some code would do something I didn't think it did, but I didn't really have the powershell chops to call them on it. For a sysadmin position, there was no one language we could standardize on, and the interview was designed more to test ability to use one's tools, not to program, so it was the best we could do. We weren't going to make every candidate learn perl/python/ruby just to apply.

A dev candidate who solves a problem in clojure may be impressive, but since I'm less qualified to judge, I will be less confident hiring them. Your best chance to get hired is to convince me that you are better than everyone else, and the best way to do that is to do something impressive that I can compare to everyone else.

I've also had people go from passing to failing because they overreached. More than one candidate successfully produced a correct C solution and then sunk their own battleship by volunteering a completely wrong soliloquy on heap vs stack memory. "Noone knows you're stupid until you open your mouth." Do NOT use clojure if you're betting the interviewer won't catch your mistakes.

I interviewed at Fog Creek recently (and I don't think it was with Ben, the post's author), and I actually didn't code in C. I answered my questions in Python, just because I'm more comfortable with it these days. So I don't know if this is a new thing they are trying out, or if internship interviews are different.

(I believe I'm allowed to say this about the interview. If Joel or someone at Fog Creek comes across this and takes issue, just let me know and I'll remove the post.)

If you interviewed in Python for a dev position, then you interviewed with me or one other coworker who is also trying this experiment. The majority of Creekers still do their interviews in C, and are in fact passionate about it: http://thoughts.rockhymas.com/post/4580899270/in-which-i-def...

Really depends on your situation, but do your interviews in pseudo code. Evaluate their ability to translate your requirements into a logical set of events that will satisfy your requirements.

Reply on news.ycombinator.com