6 ms·

> I'm a senior dev with 10+ years of experience. I don't do interviews that require a coding portion. It's a little insulting to me. I've interviewed multiple

• exBarrelSpoiler 10y ago
  Sounds like corporations should either: 1. Lower their standards and admit that many, many coding positions are API gluing and tinkering with libraries to fulfill business requirements, and not actually about engineering. Software is in a state where you can be a non-engineer and still write performant code, or at least satisfactory work, thanks to the other people who actually write those libraries. Entire successful products, even companies, have been launched on less-than-optimal code. OR 2. Actually spend time cultivating their engineers, and allow them to gain access to deeper understanding of CS, by giving them the chance to work on non-trivial problems. Maybe stronger standards need to be built into the industry as a whole, engineers should be encouraged to take a regular coding challenge outside of work, to ensure that they still remember their fundamentals. Or at the very least, they should be assigned work by the companies that is more than API gluing. Either way, it seems unfair to place the entire blame of a candidate who has 10 years of actual development experience for having the wrong type of experience. I'm sorry, but that wrong type of experience could still make deadlines, launch products, and bring value to companies. Either be open and transparent about your industry requirements, and give engineers a chance to live up to them, or accept that technology has advanced to a point where people can "program" for 10 years without knowing- or remembering- the fundamentals. And at the end of the day, isn't that the abstraction and convenience we're pushing for? Also remember that there's a difference between a developer who's been working on say Rails apps ten years, and one who's been working on compilers or embedded code. As far as the examples you brought up: did those candidates actually develop in C for ten years?
  • enraged_camel 10y ago
    >>and admit that many, many coding positions are API gluing and tinkering with libraries to fulfill business requirements, and not actually about engineering Sounds like the True Scotsman Fallacy. Why isn't tinkering with libraries and glueing code "actual engineering"? Do you think engineers of other professions invent everything from scratch? Or are they given a set of tools, materials and requirements and figure out how to accomplish the task?
• pmorici 10y ago
  I don't understand your comment. He says he thinks the coding portion is nonsense and your reply is you have discussions about C code snippets. The two things are very different. What you are describing isn't a coding exercise.
• alltakendamned 10y ago
  Now I'm curious how you'd like to see this question answered, or how you would answer it yourself ?
  • jsnathan 10y ago
    The code snippet shows a bug, p is an uninitialized pointer. The behavior is undefined. Theoretically it could point to some valid memory, but saying that it points to dynamically allocated memory definitely implies a misunderstanding.
    • gengkev 10y ago
      Which is why I would disagree with this example. I suspect the interviewee's answer was due to a misunderstanding rather than a lack of knowledge. For example, change the first line to: char *p = ...; Now, the implication is not that p is uninitialized, but that it's not important what its value is, which is likely what the interviewee thought. As for dynamically allocated memory, that's what pointers are used for the vast majority of the time, right? I would react to stories like this with skepticism, whether told by the interviewee or interviewer, especially when accompanied with a pretentious attitude ("Get out"), because the most fallible part is likely to be human communication.
      • nitrogen 10y ago
        To be fair, this is an absolutely essential thing to be a stickler about in C. It's a dangerous language, and placement of semicolons and recognition of unititialized variables should be burned deep into the psyche of an experienced C developer. This is why people advocate for alternatives like Rust where the compiler can be precise on your behalf. But as long as C is still in use, its practitioners need to be exceptionally pedantic with their code.
        • gengkev 10y ago
          That is true, but my point is that in the context of an interview, the purpose of "char *p;" might simply be to indicate the type of p, but not necessarily to indicate that it is uninitialized. It's hard to know what the interviewee thought without asking them. Though it might be a good thing to say "well, p is uninitialized," it might also come across as obnoxious if that wasn't what the interviewer intended. So it comes down to guessing which response the interviewer is looking for.
• Ologn 10y ago
  Yes. People can put anything they want on their resume. I got a resume once where a person said they were working at company X from 1995 to 1999. I knew it was false because they sat next to me at company Y in 1997 for three weeks before disappearing, they didn't even call to say they were quitting. Who knows what would have happened on the company X reference check if we had bothered to get that far. By the way, half the startups I worked at went under or were acquihired by companies which did three more mergers, so who knows if my HR records exist. Most references I know of are chats with someone claiming to be an ex-manager or colleague. The phone screen questions I ask, and the initial in-person technical questions I ask have a very low bar. Over half the people I talk to can answer them. I ask them because I have seen multiple people with seemingly perfect resumes who are unable to answer simple questions. Speaking of references, I don't understand people who are fine giving three references, but are bothered by technical questions. For me it's the opposite. I'd rather not call three ex-bosses, make sure I have their current contact info, and ask for a favor that I can use them as a reference for a job I might not even get. Asking a technical question of me that I may or may not know is much less of a hassle.
• amag 10y ago
  Hehe, I once had a manager, who was also a programmer, asking me about the difference between new and malloc. He wasn't testing me, I was working at the company. His question was something like "Isn't it that if you use new you get virtual memory but with malloc you don't get virtual memory?"
  • brianwawok 10y ago
    Was he even a C programmer? I don't know if it matters if a Ruby or Java programmer knows new vs malloc.
    • amag 10y ago
      Well, he had somehow managed to write an awful lot of C++. Most of the code base at that company was in old school C++ (huge monolithic classes). Since he was one of the founders I can only assume C++ was his main language.
  • david-given 10y ago
    ...be aware that in Windows, there are two main ways to allocate memory: HeapAlloc(), which comes from your process heap and is equivalent to Posix malloc(), and VirtualAlloc(), which comes from the kernel and is the equivalent to allocating anonymous pages with mmap(). (Windows malloc() usually wraps HeapAlloc().) So he's not necessarily completely wrong. If he's used to a system where the default C++ allocator uses VirtualAlloc() but malloc() still uses HeapAlloc(), then referring to memory allocated from VirtualAlloc() as 'virtual memory' makes sense, in a specialist weird-windows-terminology kind of way. ('Virtual memory', here, having nothing to do with virtual memory in the Linux sense.)
    • amag 10y ago
      In Windows (as in most OS:es), any memory you allocate in user space is virtual, end of story. Ok, not really end of story (I just said that because it's mostly true). You can allocate physical memory from user space but that is for very specific purposes and your general purpose CRT allocator (whereas new or malloc) will not be doing that. Also (last I looked) the MSVC CRT "new" uses malloc.
• roscoebeezie 10y ago
  As one who claims to know C on my resume, but I too am a < 3 month novice, lemme try to answer this one. You declare some pointer and give it whatever value 'c' is? I probably would have gotten the question wrong too and just saying "Get out" is kind of harsh.
  • satysin 10y ago
    char *p; p doesn't point to anything[0]. You have declared a pointer to char but not given it any memory to point to. It is uninitialised. *p = 'c'; So what are you dereferencing here? You can't dereference something you haven't initialised. [0] well it might point to something, it is up to the compiler as it is UB. Edit: btw if you could not answer this very simple problem please do not advertise yourself as a C programmer as you are not yet. Learn C and then advertise yourself as a C programmer.
    • NotSammyHagar 10y ago
      Yeah, one more thing. C and C++ type languages where you have to manage memory allocation are a different kind of intellectual challenge than languages like java or python. It takes a certain amount of try and failure and intellectual carefulness to get the ability to write trustworthy code. Just keep going at it. And be careful not to call yourself an expert c programmer, even after you get basic fluency. That's usually a sign that someone is not a great programmer in my experience :-)
  • twblalock 10y ago
    > I probably would have gotten the question wrong too and just saying "Get out" is kind of harsh. If you can't do that, you don't understand pointers. If you don't understand pointers, you're going to write really buggy code. I've never told someone to leave an interview early. That's a bit unprofessional in my view. But I certainly wouldn't hire a C programmer who doesn't understand pointers.
  • NotSammyHagar 10y ago
    Get out would be rude. If you interview a lot of people who say they are programmers, you get people who can't do anything sometimes. It is frustrating perhaps but that's no reasonable way to treat people. Back to the question. In C or C++ the pointer is pointing to a memory location. If you don't set it to something (ie no malloc, or assignment, then it is uninitialized and you can't use what it points to. It is essentially a random number. Looking at a random memory location "(* p)" could likely crash your program, but it won't be anything useful that you should use. So when you say "* p" = 'c'; you say overwrite the memory location (which is randomly chosen) with the ascii code for the character 'c'. Side note - the surprising markup language here doesn't let you use asterisk p directly, you have to put a space in I just discovered.
• david-given 10y ago
  Mmm. Be careful --- I've been programming in C for years, including frickin' K&R C, and I'd probably say something like A here (although instead of 'memory' I'd probably have said 'it points at whatever you set it to, what do you mean?'). The reasoning is: the code as written makes no sense; therefore it's incomplete. Obviously, then, it's not intended to be read literally, and is just an abbreviated portion of the real code. The first line just declares p as a pointer. The second line dereferences the pointer. The pointer assignment has been elided for brevity and is not relevant to this question. That's an expectation impedance mismatch. I'm expecting you to want a high level description of how pointers work. You're expecting me to provide a blow-by-blow machine level breakdown of the instructions involved. (Also, the blank line enforced by HN between paragraphs really doesn't help here.)
  • ubernostrum 10y ago
    This reminds me of the Google phone screen article that went around recently where the recruiter was reading off a sheet of answers and failed the candidate because the candidate gave answers which were too technically nuanced to fit what the answer sheet said. And is also why these kinds of things are a terrible fit for recruiting experienced-to-senior-level people.
    • zubat 10y ago
      I am developing a rule of thumb for this: the more pointedly in-depth your technical question is, the more likely you produce false negatives through obfuscation of intent. The grandparent's "what does this mean" question suffers particularly from being in-depth without stating it. Every CS student who learns C gets the high level treatment of pointers. But in many cases, their class does not proceed on to examine what this looks like in assembly code, except in a separate course devoted to ASM or compilers where it might be mentioned obliquely that such a representation exists. That is a relevant skill, but you have to ask for it. An easier way to get there is to ask how a C compiler turns a pointer assignment into executable binary, working backwards from the output. There are now degrees of success, since the candidate gets to discuss how compilers work if they're really engaged. But a basic answer can still capture the essence.