3 ms·
I wonder why so many interview questions are focussed on knowledge and memory. For most technical roles, and especially in the ever-changing world of FE; your m
by codeptualize 5y ago
I wonder why so many interview questions are focussed on knowledge and memory. For most technical roles, and especially in the ever-changing world of FE; your main skill is looking things up and applying what you find.
I do find this an interesting question in some ways, it probably gives some insight into the breadth of knowledge and experience. But I would not spend too much time on it. Get the impression, move on.
What would potentially be more interesting is to ask them to look up some of the things they don't know.
But interviewing is hard, it's a strange dynamic by default, it's hard to not make it cringe. A conversation like described in the article is sort of nice compared to many other tactics.
- AdrianB1 5y agoWhy interview questions are focused on knowledge? Because you want to hire someone that knows how to do things, not how to Google it or ask on Stackoverflow and assemble bits and pieces of stuff wrote by others in a Frankenstein monster. Memory? It is not a test to write rare parameters correctly, the questions problem the knowledge about the most basic things in web development - html. It's like asking a surgeon in a hiring interview if he knows what a scalpel is; not the chemical composition or forging method, just what is used for. Imagine the guy saying "I don't know, I never memorize this stuff".
- codeptualize 5y agoHow often do you write the html params and meta tags? I really don’t care if someone memorized all the meta tags. What matters to me is that if I ask them to write a template they can find out what they need to include according to the latest best practices and our situation. I rather have them looking it up than relying on something they memorized years ago and might be outdated. Looking things up is not the same as carelessly assembling as you describe it. It’s the ability to gather knowledge quickly, learn on the spot, so they can work on things they haven’t worked on before, and keep up with the latest best practices. Absolutely essential to FE development. And some of it is assembling and relying on tools to work efficiently; for example I would highly recommend to generate Favicon and tile tags. To be an effective fe dev require tons of learning on the job and doing your research as new things arrive constantly, best practices change, and you will encounter many things you haven’t before. Like I said; experience and breadth of knowledge is an interesting indicator, but it doesn’t make much sense to me to have it as the main indicator. > Imagine the guy saying "I don't know, I never memorize this stuff". Then I would ask them to look it up and get an impression of their ability to gather quality knowledge and understanding. Not a problem to me, and I would appreciate the opportunity to gain insight in those skills.
- AdrianB1 5y ago> the ability to gather knowledge quickly, learn on the spot, so they can work on things they haven’t worked on before That is perfect for a junior, not acceptable for a senior that is supposed to already have solid experience with that stuff; HTML tags should be something they worked before a lot.
- PragmaticPulp 5y ago> I wonder why so many interview questions are focussed on knowledge and memory. For most technical roles, and especially in the ever-changing world of FE; your main skill is looking things up and applying what you find. Yes, but you need to have some foundation of quickly-accessible knowledge ready to go, so you can focus on looking up the hard things. Technically I could hire motivated college students and give them years and years to look everything up and study it as they go, but I could also ship the same software in a fraction of the time by finding someone who has experience doing something similar. That's the purpose of interviews: To gauge baseline experience. The alternative interview format is a take-home problem. The candidate receives a small, arbitrary problem (not real work) that approximates a ticket they might work on at the job. They're free to solve it at home on their own time. Unfortunately, take-home interview questions are also a contentious topic on HN. A lot of people on HN insist they refuse to do take-home problems or otherwise hate the idea of candidates having to put effort into the interview outside of the conversation. I think the real take away is that engineers (and other professions) just don't like to interview. Nobody likes sitting in front of someone else and having their performance evaluated. Nobody likes potentially being rejected. Nobody likes being asked to do effort to interview for a job they might not get.
- ZephyrBlu 5y agoI disagree with this point of view. The main foundation isn't of quickly-accessible knowledge, it's having a good process and strong intuition. Knowledge feels more incidental than being the main focus. If you throw a Staff engineer into a new domain they're likely going to quickly become more effective than a mid level engineer with domain knowledge because they have better meta level skills. Of course, this is very dependent on how specific the function of the person you're hiring is and how quickly things are moving. If you're hiring for a very specialist role then knowledge will be a lot more valuable. Same goes if the domain is not moving very quickly (I.e. historical knowledge is valuable). Though in general, I think a lot of people would jump to hire a SWE who has been an expert in a different domain.
- codeptualize 5y ago> The main foundation isn't of quickly-accessible knowledge, it's having a good process and strong intuition. Knowledge feels more incidental than being the main focus. Well said! I very much agree.