3 ms·
I interviewed an ex-FAANG (developer) currently working as a software executive for a director role at a previous company. This person included 5 years-ish of H
by alex_lav 3y ago
I interviewed an ex-FAANG (developer) currently working as a software executive for a director role at a previous company. This person included 5 years-ish of Haskell experience on their resume. I don't know Haskell at all, but am aware of the language and its design principles, so I figured a lot of my technical questions would be pretty easy for him
Boy was I wrong. My first question was "Name the most common data structures you use day to day". He stayed silent for a bit and then said "What, do you want me to just list them?" I said yes. After some more silence he said he couldn't recall any. The fact that he said "list" was particularly ironic.
I kind of gave up on expecting used-to-be software developers to have retained a single bit of knowledge from their time as a dev after they've moved on to "leadership" or "management". I believe it's important for technical leadership
to understand technical problems and their solutions in broad strokes, but it seems I'm mostly in the minority in the real world. That interview (and trying to hire for that role) really showed me how little engineering leaders remember about software.
- fho 3y agoThat's interesting ... Might be my specific view on Haskell, but there is a lot of emphasis on using the right data structure for the right job. That's probably because due to Haskell being immutable you have to rethink which standard data structures you can reasonable use.
- deleted 3y ago[deleted]
- randomdata 3y agoI write code every day and I still had to ponder your question for quite a while before I could think of a data structure I use regularly by name. It is not exactly useful knowledge to keep top of mind. It is not like you need to look up how to use daily data structures. I had an easier time remembering the names of data structures I almost never use, or even have never used, as retaining their names actually has some usefulness. In an interview situation, I expect I would also give up with stating I could not recall any to save the awkwardness of sitting there silent for half an hour racking my brain.
- Shaanie 3y agoI'm sorry, but what? If you can't even remember what list/set/map whatever is called, how are you going to use them? We're not talking about exact syntax here, just what data structures you use...
- 40yearoldman 3y agoI think the part of the question that throws people is “most common”. It begins to sounds like a trick question, because it hat is the most common? Its going to very from code base to code base. Maybe id the question was name 3 data structures, any 3 it might sit well. But even so. The question did devolve into list of things somebody should know as a ex developer.
- alex_lav 3y ago> I think the part of the question that throws people is “most common”. It begins to sounds like a trick question, because it hat is the most common? Its going to very from code base to code base That’s pretty textbook overthinking for an interview. The point is that it varies from codebase to codebase. Tell me about what you normally use and I’ll ask questions. > Maybe id the question was name 3 data structures, any 3 it might sit well. Trying to get every human to agree on the wording for an extremely easy and general question isn’t a worthwhile use of time though. > But even so. The question did devolve into list of things somebody should know as a ex developer. Interesting use of “devolve”. An an interviewer for a technical role, am I not allowed to have a set of required skills? And is a basic understanding of common data structures not allowed to be in that set?
- randomdata 3y ago> And is a basic understanding of common data structures not allowed to be in that set? It may not be unreasonable, but the question didn't ask that. Granted, it is unlikely the interviewer was skilled in interviewing and the ill-conceived question was born out of their own lack of ability in the the job they were thrown into doing. The reality is that very little effort goes into researching the science of hiring in the first place, and it is even less likely to find people who are both experts in technical matters and experts in what little we do know about interviewing. For how critical businesses claim the hiring process is, it is amazing how they will so often happily throw the first bumbling idiot they can find willing to accept the interviewer role into it like it doesn't matter.