Do you pay attention to the signals your technical interview questions may give?
Couldn't sleep tonight, after having some particularly bad technical interview a couple days ago which I can't stop thinking about...
Thinking about it - not necessarily because I had trouble with a couple of technical questions - it has more to do with what questions were asked that bothers me. You may or may not choose to believe me.
I'll spare you the wait. One of the questions was "How would you program a simple test in C to figure out the endianness of the underlying architecture?". I will not contend with the fact that this is a valid question to pose to someone applying for an Embedded C/Linux position. I'll also agree that, as someone who put in "mastery" of the C language in his resume, I should definitely shoot the answer immediately. But I didn't, I blanked at the whiteboard, first thinking that endianness is bitwise and trying to (still wrongly) solve the problem with that assumption, then, after the mistake being pointed out, still trying to solve the problem with bitwise operators. [1]
You'd think this kind of question is innocuous, It's simply testing the competence of the programmer, correct? I don't think so.
This type of a question I'd call a theoretical one, even academic, because it asks for a creative use of a language-specific feature (Flat Memory Model)
to solve a problem that's been solved many times. Encountering this problem in the wild would warrant one search through
the standard library for the appropriate macro (BYTE_ORDER in endian.h). Do you think that this question, compared to any other type of question, selects for your desired employee?
To answer that question we need to answer a different one first, which is: What characterizes a desirable employee?
I'll try. To me, a desirable employee is an employee that provides value to a business, and while it's definitely important to have experts in fields the company operates in, most companies need one for each field, often not even that (outsorcing is a thing). If reading HN every day taught me anything, it's that most companies need product-oriented team-workers, someone who acts in service of the current and any future product of the company.
In case of a software developer that would mean:
Being Efficient - avoidance of reinventing the wheel
Emphasis on software architecture -> formalization of problems -> reusable components (> fast future products)
Keeping it simple, so a junior colleague would be able to contribute (> low technical debt)
So with that in mind, what message does the interview question convey? I think it conveys that this particular company doesn't value any of these points enough to test them. Instead, it seems that it looks for a domain expert, which may sound as a bit of a leapy conclusion based on one question, but there wasn't really any question relevant to those points in this case. For context, I've already been tested for core competency in C and Linux (and networks) at this point.
I like to think of myself as an empathetic person, always trying to put myself into the shoes of the bussiness, thinking of answers to interview questions from the POV of a valuable member of the company. That being said, I knew what was being asked from me, so I couldn't simply respond "find the corresponding macro in the standard or POSIX C library".
This, for me, was the first kind of a technical interview in this vein, usually it has been more about writing some function according to spec or formulating a solution to a problem in UML. I guess I'll have to get used to these more. Might have to start leetcoding and stuff.
Footnotes