> 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.
I 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.
> 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.
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.