Rewriting the Technical Interview (2020)(aphyr.com)
aphyr.com
Rewriting the Technical Interview (2020)
https://aphyr.com/posts/353-rewriting-the-technical-interview
8 comments
Title needs a (2020) - this is an old classic. It does have a minor 2023 update to include more sample code.
Perhaps I didn't get the message but over-engineering is not something to brag about in an interview.
The real challenge is keeping things simple, readable, maintainable.
The real challenge is keeping things simple, readable, maintainable.
I think the joke is this person is actually very good at programming but has no idea what they are socially expected to do for these alleged tests of programming skill, so approaches it earnestly as a programming challenge instead of a “regurgitate the standard answer as if you are inventing it on the spot” performance.
[edit] it’s also connected to folk and religious tales that feature someone so wise that they basically no longer understand how to be mediocre or how to care about things that do not matter to the wise, often to the consternation of those around them. “Here’s the excellent white steed I told you about”; “uh… this horse is dappled brown”; “Hm? Oh, I’m not sure about that.”; “… you said this guy’s a horse expert, right?”; (but of course it does turn out to be a superb horse). That sort of thing.
[edit] it’s also connected to folk and religious tales that feature someone so wise that they basically no longer understand how to be mediocre or how to care about things that do not matter to the wise, often to the consternation of those around them. “Here’s the excellent white steed I told you about”; “uh… this horse is dappled brown”; “Hm? Oh, I’m not sure about that.”; “… you said this guy’s a horse expert, right?”; (but of course it does turn out to be a superb horse). That sort of thing.
Oh, but it is.
I once had a debugging interview on Linux. In my head. No terminals. Interviewer would propose a hint about the problem, but he was tipping the answers. I could see where he wanted to go every time.
So I applied a concept from Bridge: WHen you are given unintended information from your partner, you must take any logical action except for what is indicated.
So I'd spit out ALL things that came to mind, then finally the answer. (Like 4 or 5 thing PER STEP.)
And I wan CONSISTENT. The more he tipped, I just kept doing it.
At the end of the interview, I asked my questions, and asked if they played bridge. They said no. I explained the concept of Active Ethics, and that throughout the interview I was using active ethics.
;)
Got the job. That guy was one of my best friends in the joint.
At times... Simple questions involve complex answers. :)
I once had a debugging interview on Linux. In my head. No terminals. Interviewer would propose a hint about the problem, but he was tipping the answers. I could see where he wanted to go every time.
So I applied a concept from Bridge: WHen you are given unintended information from your partner, you must take any logical action except for what is indicated.
So I'd spit out ALL things that came to mind, then finally the answer. (Like 4 or 5 thing PER STEP.)
And I wan CONSISTENT. The more he tipped, I just kept doing it.
At the end of the interview, I asked my questions, and asked if they played bridge. They said no. I explained the concept of Active Ethics, and that throughout the interview I was using active ethics.
;)
Got the job. That guy was one of my best friends in the joint.
At times... Simple questions involve complex answers. :)
I laughed at
> “You’re quite right. Shall we do conditionals?”
Of course that should return 3/5. Clojure is quite cool but I suspect this is not the best showcase.
user=> (c
x = 3;
x++ / 5;
)
4/5
> “You’re quite right. Shall we do conditionals?”
Of course that should return 3/5. Clojure is quite cool but I suspect this is not the best showcase.
You are missing the point. It is a PERFECT showcase of understanding.
The person implementing knew what they had to implement, and what they didn't. What looks like a demerit is actually a sign of mastery.
The person implementing knew what they had to implement, and what they didn't. What looks like a demerit is actually a sign of mastery.
Maybe I should have pointed out that's his reply that I found funny, for that very point: “You’re quite right. Shall we do conditionals?
[deleted]
I don't get it, what are they trying to say?
Do you mean at the technical level? Vidrun's asked to solve FizzBuzz, and like a good engineer, she reuses an existing, well tested solution. However, the interviewer, Martin, chides her by telling her the point of the interview is to see how people might solve things for themselves. He then asks her to explain how the FizzBuzz program she copied works. So she implements a C-like language in Cloture.
Pretty elementary stuff. Not "so easy a little kid can do it" but literally, in the sense that these techniques, this knowledge, underpins every programming language you use. Every computer scientist and software engineer should know how to do this. If you get a chance, work your way through a copy of _Essentials of Programming Languages_ (https://mitpress.mit.edu/9780262062794/essentials-of-program...). It will help make sense of what Vidrun does here.
At a non-technical level, well, that requires a longer explanation for which I lack the time to write.
Pretty elementary stuff. Not "so easy a little kid can do it" but literally, in the sense that these techniques, this knowledge, underpins every programming language you use. Every computer scientist and software engineer should know how to do this. If you get a chance, work your way through a copy of _Essentials of Programming Languages_ (https://mitpress.mit.edu/9780262062794/essentials-of-program...). It will help make sense of what Vidrun does here.
At a non-technical level, well, that requires a longer explanation for which I lack the time to write.
I think you have unrealistic expectations of software developers if you think they should all be able to do this. Elementary sure, and maybe they “should” in the platonic sense, but ask 10 developers to implement a language and 9 will fail to make any meaningful progress. And I think that’s fine. It’s like when people get upset at web devs for not knowing the networking layers. Elementary sure, good to know, maybe, critical to their everyday function, doubtful in the extreme
Or to put it another way, why should* someone know how to do anything that's never ever come up before in their life?
* "should" as in someone else externally judging someone
* "should" as in someone else externally judging someone
Of course, some of those people then do get asked to build a language, and the result is awful and ignores the last 60 years of knowledge on how to actually do that ... (yes, I have seen this)
It's been my experience that software developers can be wildly successful not knowing or using any deep magic like this. Still, I think this stuff is good to know.
Edit: Oh, I should have used "elemental" instead. That might have gotten my point across better—underpinnings, not trivia.
Edit: Oh, I should have used "elemental" instead. That might have gotten my point across better—underpinnings, not trivia.
I would argue it's still too much (and not useful) to expect most people to be able to do this.
Understand, yes. Good software engineers and computer scientists should be able to read this blog and fully understand what's happening, modulo any clojure-specific syntax they might be unfamiliar with. But this isn't something people should be expected to able to already know how to up and do.
Understand, yes. Good software engineers and computer scientists should be able to read this blog and fully understand what's happening, modulo any clojure-specific syntax they might be unfamiliar with. But this isn't something people should be expected to able to already know how to up and do.
So this is interesting. ABET says that an accredited computer science program must include "substantial coverage" of "concepts of programming languages" (https://www.abet.org/accreditation/accreditation-criteria/cr...). However, an ABET-accredited software engineering program has no such requirement (https://www.abet.org/accreditation/accreditation-criteria/cr...).
I still think a software engineer should know this stuff, but given the other material covered in an accredited degree program, there probably isn't enough time for computer science fundamentals like programming language concepts. That's a damn shame. I think software engineers having that level of understanding is a good thing.
I still think a software engineer should know this stuff, but given the other material covered in an accredited degree program, there probably isn't enough time for computer science fundamentals like programming language concepts. That's a damn shame. I think software engineers having that level of understanding is a good thing.
PLT was part of my CS degree, but only as a senior level course, and it was extremely abstract, and extremely difficult. Double majors (common with business) were exempt from it.
I think it’s fair to say that almost none of my fellow CS degree holders from that cohort (which was neither a rinky-dink program nor full of dim witted students) could do what we’re discussing here, and if they can it’s because they either were uniquely talented at the lecture material or learned it outside of their coursework, probably after graduation.
I think it’s fair to say that almost none of my fellow CS degree holders from that cohort (which was neither a rinky-dink program nor full of dim witted students) could do what we’re discussing here, and if they can it’s because they either were uniquely talented at the lecture material or learned it outside of their coursework, probably after graduation.
Not all software developers are computer scientists or software engineers, and not all software developers are preoccupied with turning computers into a salary.
[deleted]
This is a pretty elitist viewpoint, and also totally wrong.
It's fully possible to be an excellent software engineer without being able to implement a new language, or deeply understanding how to. It's completely reasonable to be among the best in the world at using a tool, and understanding how the tool works, without being able to create one of those tools.
You might as well ask the same software engineer to design a CPU. Or ask a woodworker to design a lathe.
The best pilot may not be able to design a plane, while still being a better pilot than an aerospace engineer that doesn't know how to fly the planes they design and build.
It's fully possible to be an excellent software engineer without being able to implement a new language, or deeply understanding how to. It's completely reasonable to be among the best in the world at using a tool, and understanding how the tool works, without being able to create one of those tools.
You might as well ask the same software engineer to design a CPU. Or ask a woodworker to design a lathe.
The best pilot may not be able to design a plane, while still being a better pilot than an aerospace engineer that doesn't know how to fly the planes they design and build.
Maybe call yourself a software developer then? Or a software technician?
A mechanical engineer does have deep understanding of everything they do. They understand their systems from first principles. Maybe not as much as a physicist but certainly more than your carpenter example. They know how lathes are designed, they understand the principles, and a good mechanical engineer can design (and build) a lathe.
A mechanical engineer does have deep understanding of everything they do. They understand their systems from first principles. Maybe not as much as a physicist but certainly more than your carpenter example. They know how lathes are designed, they understand the principles, and a good mechanical engineer can design (and build) a lathe.
Building a programming language is such a tiny, niche part of computer science and software engineering that most computer scientists and software engineers never do it. They don't need to do it.
I think a decent computer scientist and software engineer should be able to understand everything written in this blog post, modulo any Clojure-specific syntax if they're unfamiliar with that language.
But replicating it off the top of their head? No, and that's not expected.
A mechanical engineer is a different example than I gave, so that changes the analogy. We're discussing a member of a profession being able to de novo create the things they use in their trade. I would expect most mechanical engineers to be able to build a lathe, yes.
But a mechanical engineer is not a materials scientist or a metallurgist. I would not expect a mechanical engineer to be able to create rubber capable of being used for a belt in the lathe, nor capable of creating steel hard enough to form the cutting bit.
Perhaps you're right, and there's insufficient granularity in the terms used, where "computer scientist" or especially "software engineer" is used to describe the 99% of us who haven't and have no need to create a programming language, plus the rest.
But I won't be updating what I call myself. To paraphrase Office Space, "Why should I change? They're the ones who are elitist gatekeepers".
I think a decent computer scientist and software engineer should be able to understand everything written in this blog post, modulo any Clojure-specific syntax if they're unfamiliar with that language.
But replicating it off the top of their head? No, and that's not expected.
A mechanical engineer is a different example than I gave, so that changes the analogy. We're discussing a member of a profession being able to de novo create the things they use in their trade. I would expect most mechanical engineers to be able to build a lathe, yes.
But a mechanical engineer is not a materials scientist or a metallurgist. I would not expect a mechanical engineer to be able to create rubber capable of being used for a belt in the lathe, nor capable of creating steel hard enough to form the cutting bit.
Perhaps you're right, and there's insufficient granularity in the terms used, where "computer scientist" or especially "software engineer" is used to describe the 99% of us who haven't and have no need to create a programming language, plus the rest.
But I won't be updating what I call myself. To paraphrase Office Space, "Why should I change? They're the ones who are elitist gatekeepers".
I've done it a few times in my career. A lot of people build domain specific languages or compilers or translators or assemblers. Compilers and related theory is often covered in a CS degree curriculum.
I didn't say replicating off the top of your head. The blog post is meant as parody. I'm not suggesting someone should be asked to design a language in an interview though maybe some questions on the topic might be ok for some specific roles.
A mechanical engineer is not a material scientist or a metallurgist but they're definitely educated on the topic of materials. They need to choose the right alloy or material for their designs and understand its properties, they need to select vendors and understand the relevant processes. They're not as specialized but that have some base understanding and the capability to dive in if needed. That's I think what a software engineer needs to have as well. A car mechanic doesn't have those and that's fine.
I don't think this is elitist. There needs to be some distinction between people at different levels and capabilities. I'm not saying a car mechanic isn't capable of being a mechanical engineer. They can even become the equal or better through self study. But replacing an alternator isn't the same thing as designing the alternator.
EDIT: And just to be clear, I wasn't trying to be personal there. The reality of life is that lots of people that work on software call themselves (and companies call them) software engineers.
I didn't say replicating off the top of your head. The blog post is meant as parody. I'm not suggesting someone should be asked to design a language in an interview though maybe some questions on the topic might be ok for some specific roles.
A mechanical engineer is not a material scientist or a metallurgist but they're definitely educated on the topic of materials. They need to choose the right alloy or material for their designs and understand its properties, they need to select vendors and understand the relevant processes. They're not as specialized but that have some base understanding and the capability to dive in if needed. That's I think what a software engineer needs to have as well. A car mechanic doesn't have those and that's fine.
I don't think this is elitist. There needs to be some distinction between people at different levels and capabilities. I'm not saying a car mechanic isn't capable of being a mechanical engineer. They can even become the equal or better through self study. But replacing an alternator isn't the same thing as designing the alternator.
EDIT: And just to be clear, I wasn't trying to be personal there. The reality of life is that lots of people that work on software call themselves (and companies call them) software engineers.
To get the interviews, it's best to read them in the "correct" order:
https://aphyr.com/posts/340-reversing-the-technical-intervie...
https://aphyr.com/posts/341-hexing-the-technical-interview
https://aphyr.com/posts/342-typing-the-technical-interview
https://aphyr.com/posts/353-rewriting-the-technical-intervie...
https://aphyr.com/posts/354-unifying-the-technical-interview
https://aphyr.com/posts/340-reversing-the-technical-intervie...
https://aphyr.com/posts/341-hexing-the-technical-interview
https://aphyr.com/posts/342-typing-the-technical-interview
https://aphyr.com/posts/353-rewriting-the-technical-intervie...
https://aphyr.com/posts/354-unifying-the-technical-interview
[deleted]
These get better every time I read them.
Well, that’s fairly damning.