> I'm a kick-ass get-things-done full-stack web engineer.
And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.
No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.
Not revealed as a terrible company, perhaps, but as a terrible interviewer.
If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries.
That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index, which is likely what I would be doing at most companies.
Part of development is figuring out not just the answers to the questions, but also figuring out "Of all the questions I could have been asked, why was I asked that question?"
A disappointingly large fraction of the time, the answer to "why did you ask that question?" is "we noticed a correlation, confused it for causation, and built an entire strategy around it".
> need to roll their own new solutions in the face of so many well-established libraries
I'm not defending interview quiz-time, but it isn't (or shouldn't be) about rolling your own solution. It's about understanding concepts. Understanding the basics of time/space complexity are pretty fundamental when designing systems.
Developers frequently encounter hashing and (probably less-often) trees, so I don't see an issue with asking something like "Why/how/when is a hash-based lookup faster <in some situation> than a tree-based lookup?" (as one question during an interview). If a person can give a good answer to this, they'll pretty easily be able to understand the performance tradeoffs of hash vs btree indexes when using mysql (and this same tradeoff in a variety of other situations).
If you're measuring my design ability in the interview, you had better give me an opportunity to use that ability after being hired.
Too many times have I been asked questions that shaped my expectations of the job, only to be disappointed later on. The worst offender in this respect put me through a technical screen that could only reasonably be passed by someone with a bachelor's degree in CompSci or equivalent work experience, only to later tell me that the code I write "should be understandable by a kid fresh out of high school" (actual quote). I applied to 12 different job postings that night.
The interview led me to believe that I was being hired for my expertise, and the job expectation was actually to be a warm, brainless body in a formerly empty seat. That's why I don't like questions that act as proxies for some other metric. The questions you ask me are telling me about you as much as my answers tell you about me. When you cargo-cult interview procedures from another company, you are actually misrepresenting the nature of your own company as being like the company you stole your interviews from.
> "before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index"
How I am going to ask you to tweak an index, if you don't know how to browse a tree? Although I would have asked you about B+ and B* trees, the ones used to index a database. There are differences in those trees and you need to know them in order to decide which one is a better option to improve the performance of the queries. Obviously this improvement means nothing for a small startup, but image the impact it has in a company as Google.
I think the point is that a lot of interviewers make those questions because big companies do them. But there is a reason why they do them. Obviously I would prefer the candidate that knows the answer over another one that also does the job but doesn't know the answer.
How big is the chance that you select the candidate who happens to know all solutions (e.g. by learning them by heart recently for the dozens of interviews he's planning on doing), but is not a good technical fit? My estimate is: pretty high; Let me explain why.
If you indeed need someone who knows about B* vs B+ trees, why not ask him about that separately ("explain me the difference between ..."), to see if he has the technical background you need? Even if someone understands that difference, that same person might have problems getting DFS right during the whole live interview, for a number of completely irrelevant reasons (nervousness, a momentary lapse, being a bit "rusty", a.s.f.). For the candidate to know the difference between a B+ and B* index/search and to operate a database correctly doesn't require the ability to implement DFS flawlessly (and most likely will never require the person taking a shot at that, for that matter...)
I think the real problem is that some people don't seem to understand the goal of these questions. If you do algo whiteboard questions (and you should!), you should measure the candidate's behavior, reactions, and analytical skills, while attempting a solution with you - and not to find out if the provided solution is correct or not (indeed, its often more interesting when the solution is not and you work with the candidate on locating the issue!). And all the while, the interviewer can try to figure out if he/she wants to work with that person, given the current interaction, too.
I disagree with you in a lot of things. I don't like whiteboards because they are stressful and feels strange if you don't use them regularly. I was a teacher which uses whiteboards daily and they are completely different to use a computer. I would rather ask the candidate to talk about one of his projects and start asking relevant questions related to the job position and applied to the project he knows. And have a discussion this way. And the iteration with the candidate is only biasing your decision towards his personality and not his skills. To know if he does the things like I would do them.
But that is my opinion, the person who is hiring is the one who decides who he wants to hire. I feel more confident in finding a good fit/candidate my way that how you described.
"Perhaps you won't, but since we don't know yet exactly what you'll be working on, we might know broadly what PA or even project, but we can't know what problems you will encounter or what direction it will take to debug any problems that arise, we want someone with a broad base of skills who can at the very least recognize performance problems and solve them in a simple case. We expect that if you can solve this relatively simple problem in an environment with no resources, that with the aide of documentation, profiling tools, and teammates to lean on, you'll be able to address much more complex issues that arise. On the other hand, if it takes you documentation and teammates to solve this simple case, who knows what kinds of tools it will take you to solve real world problems that arise."
"Correlation does not imply causation" doesn't imply that correlation never implies causation.
> If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries.
Please suggest a reasonable alternative then. I need to interview people and see if they are going to be capable of digging through complicated code, of coding things reasonably quickly, or writing scalable, robust code, of potentially digging into things enough to optimize their performance, etc. as reasonably well as I can in an hour. And I need enough concrete evidence that everyone else in the debrief believes me. I would love to change the way I do things, but I am held accountable for the interview, so I can't just show up to the debriefs saying crap like, "He says he can use a library for anything that comes up." And I need to evaluate some other soft skills type stuff, like caring about the customer, communicating well, delivering more if you see something extra that you think should be done, etc.
But the obvious answer to your question would be, "because if everything we do could be solved just by using a library, we'd have interns or offshore people do it for a fraction of the pay."
As prirun says, you have a conversation, not a quiz.
Quizzes are a terrible way to assess skill; they're used in academics because they're, sadly, the only quick way to get some sort of consistent feeling over the memory and information retention in a group of dozens of students. No intelligent company should be copying this; companies have the luxury of dedicating significant time to exploring the potential of each candidate.
You say "Hey, here's a real problem that we'd need to solve. How would you go about it?" And let them talk. They'll be able to speak in informed terms about how to approach the problem even if their algorithms memory is rusty or if they're self-taught. If it sounds like they're on the right track, you win, if not, you move on. Repeat until end of interview, evaluate at the end.
I've used a basic code competency test for an interview pre-screen before. This is a take-home project that should take a competent person about 30 minutes, 2 hours if they go all out and add a bunch of bells and whistles.
People say this, that their take-homes are non-intrusive, but don't mean it. I mean it. The quiz is seeing if they can make a single API call to a prominent API and return the results according to a very simple format.
These pre-screens should be well below the competency requirement, which can only be assessed in the interview. It's essentially a fizzbuzz that they can't easily copy and paste by searching for "solutions to fizzbuzz".
Other than an extremely simple pre-screen like that, your decision should be based on their ability to reason, discuss, and solve problems on the fly, not how well they remember the particulars of compsci curriculum. That selects for the recency of their last class, which, ironically, is usually inversely correlated with their much more valuable real-world experience and what people think they're trying to test for.
This doesn't apply if you actually are doing deeply theoretical work on the cutting edge of compsci that may require frequent cooperation with academics. But that's a tiny minority of positions.
I love this; it's a good insight into what a hiring company wants to know about a potential employee. So how do you get there? Here's my suggestion:
There are 2 very distinct (in my mind) kinds of skills in question. For the "soft skills", a manager-type could and maybe should do that part of the interview. A trusted tech person should do the technical part. I'd go so far to say to that every technical person on the staff should be trained / groomed to help with interviews. So maybe you have 1 tech person do the tech interview, and a 2nd is learning how to interview.
For the interview itself, the process I'd use is to ask a lot of questions. For the soft interview, things like:
- "Tell me about a difficult customer you've had." Let them explain a while, and ask lots of probing questions: "Why didn't you do X instead?", etc.
- "Tell me about a difficult problem you had with a former employer." Same drill.
For the tech part, bring some code to the interview, ask the interviewee to bring some code to discuss. Another option would be to just throw them into a source code tree and say something like "Here's a tree of one of our projects. Talk to me about it." Maybe I'm wrong, but I think I could tell a lot about a tech person just from how they approached being thrown into a mess with no prior information. After all, that's a large part of being a good developer IMO. As they start to figure things out, look at code, etc., ask them questions about what they're seeing. Let them ask too. If you run into something interesting, like a specialized algorithm, ask them about it: "Why do you think it was done this way? What would some other options be?"
Then let them do these things for code they have previously written. For example, I wrote a Prime minicomputer emulator. I'd love an interview where they asked me about why I did this project, what problems I ran into, what were some alternative designs for tricky problems, what were the tricky problems, what did I learn from doing this, what tools did I use to do it, etc.
>Another option would be to just throw them into a source code tree and say something like "Here's a tree of one of our projects. Talk to me about it."
"Its in perl, I don't know perl, and especially not your internally modified version of custom-magic perl that Steve wrote 7 years ago."
Not to mention that you are now either showing source code trees to random potential hires, or you have to audit/create/otherwise use some potential set of source code. Maybe you prescreen by asking them their favorite language, and you come in with an open source project, in their language of choice, but now you have to have one of your devs spend time familiarizing themselves with Redis or the Python interpreter or Hibernate Core or Angular or whatever, and what happens when they ask to do the interview in Haskell?
FWIW, I know some companies that do the interviews you're describing, but they're all relatively small (<100 employees), and they all do that kind of interview only after a technical phone screen with your conventional questions, because the time investment required by the company is so great.
I've worked on projects where people role their own solutions instead of being able to use stuff that's out there and it's not great either.
The real solution I guess is talking to people and teasing this info out of them, and perhaps showing them some older code you have since fixed and seeing what they find in it.
Edit - one reason I personally try and use a lot of libraries is so that large parts of a project are maintained upstream after I leave my contract; the more I write into the project, the more the next dev will have to maintain, anything I can push back into external libraries is a win.
In fact, it should be explained at the job offer text. With an added bonus that people then can self select in or out of the offer without losing any further time.
No, it most definitely is not "fine". Even momentarily hesitating on question like "Would you use BFS or DFS in this case?" is more than enough to merit a quick transition to the "Do you have any questions for me?" phase, in many a modern, "As hire As, Bs hire Cs, you know" interview session, these days.
As an engineer you should be able to see the global picture and know other things. Because you wont be able to use something to solve your problem if you don't know it in advance. I mean, you don't need to know the details, but you need to know how things works.
For example, you might not need an AVL tree in your daily job, but if one day you need it to use it, you wont be able to notice if you don't know what is an AVL tree and what is its advantages over other trees.
Another example, you don't need to know http1 and http2 differences for your daily work. But if you know them you will change how you do web pages and you will see a leap in terms of performance and scability. And that knowledge also includes some knowledge about TCP, UDP, cache and other stuff.
The amount of things we need to know is not commensurate with salaries for companies that lazily copy someone else's interview. Most of us are not practitioners that get to dictate a lot of the technical decisions. We're just told we need to know what an AVL tree is before we can work on CRUD app #4272095.
If you work really hard, learn all of this stuff, and do a really good job and save your company a bunch of trouble by knowing all of this, you won't get a dime for it, and that's the problem. You get a pat on the back and you feel slightly less like an imposter for a few days.
People are arguing that we should offer quality for free. This is what open source is for.
I would argue security is more important than performance knowledge, but there is virtually zero focus on this that I've heard from the technical interview rabble-rousing that goes on in these threads.
> If you work really hard, learn all of this stuff, and do a really good job and save your company a bunch of trouble by knowing all of this, you won't get a dime for it, and that's the problem
I think that is your problem. I don't stay in companies where I don't feel valued. And anyway you are receiving a salary every month for your work. If you think you should get more, ask for more or move to another place.
For some people security is more important, for it is not. Because I believe that in the current society the companies can fall in few years (Nokia, Canon, ...). My security lies in my knowledge and my skills, and that is something I take with me whereever I am. I recall something I read, it was like this: "A bird is not scared of a branch to break, because it lies his confidence in his skills to fly".
>My security lies in my knowledge and my skills, and that is something I take with me whereever I am.
Sorry, I was confusing, I meant network and information security. Using a good password hash/library, not trusting user input, knowing some basic attacks or stuff from OWASP Top 10 and how to reproduce them. That stuff is still a problem. I'll admit I probably know less than I should because it's at the fore-front of my mind and I don't practice often, but it just seems weird that a company would prefer performance over secure coding.
Oh I missunderstood, sorry. I think everything is important, the more you know the better you can do your job. Probably maintenance comes before security, and security before performance. But it depends on the case.
... but if one day you need it to use it, you wont be able to notice if you don't know what is an AVL tree and what is its advantages over other trees.
No, what would happen is you'd say to yourself "Hmm, looks like I need a self-balancing tree. Haven't thought about those in N years..." and do a few seconds of keyword searching. The idea that people will be utterly helpless on their jobs without instantaneous photographic recall†of AVL tress (and A-star, and all the other crap people are bullied into memorizing these days) just doesn't hold water.
†Which, as we know, is the only level of recall acceptable in the modern interview process. Even momentarily hesitating in your recall of certain definitions will easily get you flushed by some interviewers.
The research you have to do is based on your previous knowledge. The less you know the more you need to learn when you are facing a problem you don't know how to solve it. But people is lazy, if they know a way to solve it they will go that way even if it is the worst way possible.
I am not talking about implementing an AVL tree without any help or resource. That is simple stupid, we have internet we must use it and save time. My point is that you need to know that there are balanced trees, know some of them and they characteristics. That knowledge will save you time when you face problems related to trees. You are not going to know all the trees because researches are working on new ones every day, but you should have some knowledge in the area.
If you interviewer drop you because you hesitate in something, maybe it is the interviewer problem and not yours. We are not perfect, we should know people will make mistakes and hesitate. I was rejected of interviews when I hesitate when they asked something about linked lists. I was happy it happened, because I was in shock when I was explanning how I did something with and A* algorithm and a octree and I couldn't believe the next question was about a linked list. I wouldn't be happy in that company.
> No, what would happen is you'd say to yourself "Hmm, looks like I need a self-balancing tree. Haven't thought about those in N years..."
You're attacking a strawman which has little to do with the original post or what the other commenter is saying. There's a lot of developers out there who lack the knowledge to ask the question you pose in the first place, so wouldn't end up doing that searching. The type of interviewing you're criticizing is intended to identify developers lacking the kind of base knowledge needed as a foundation for further inquiry.
Knowing when to use an AVL tree is orthogonal to being able to write one under pressure on a whiteboard. But as long as someone knows that different trees have different performance characteristics, I care more about how they decided what to optimize and why they recommend a lookup-optimized tree over a cache.
No, we should learn the basic algorithms and data structures (and their performance and storage characteristics) because they're the building blocks of everything else we use. You're using some API? OK, cool. Knowing some about its internal workings means that when you've got some wonky performance issue, you've got a basis to start reasoning from, to find and fix the cause of the problem.
Never once has knowing about the performance of linked lists or hashmaps been necessary to fix an API issue. 99% of your API issues will be "this doesn't work for X reason", not "this API response is slow because weren't using X instead of Y data structure".
You sound like you've worked with significantly different code than I have. Your "never once" is my "almost always", and my "X reason" is often because I'm working with an immature, unreleased library developed by another team at my employer.
What's more likely: that everyone needs to know intimate details about basic data structures or that the world is held together with duct tape and Perl and 95% of code is written by people not in Silicon Valley who need it to just work?
I think you are looking at this wrong. I have zero problems with someone presenting themselves this way and would definitely consider hiring the person.
Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't.
My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc.
A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough.
I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview.
I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.
The problem with your approach is that it excludes anyone who spends most of their time writing code for a business. I legally can't provide you with the code that I have written over the last several years. You're limiting your applicant pool to people who have been paid to work on open source, freelance web developers, and people with very little life outside of work.
I agree that puzzles aren't all that great of a measure of ability, but at least anyone can do them without writing about thorny legal issues over IP or spending all of their free time on spare projects.
Not entirely sure how you might have reached that conclusion. Anyone dedicated to their craft will naturally --out of sheer interest-- devote time and effort to getting better at it.
For example, as a young EE I was constantly reading data books (yes, physical data books) and application notes. I had hundreds of data books and probably went through all of them twice and some several times. I could, at the time, talk about almost any chip from any of the major manufacturers and knew where relevant application notes existed for most problems. My employers did not mandate that at all. I was truly interested in what I was doing.
Someone interviewing me at the time would have learned a heck of a lot more about me if they asked me something as simple as "Can you tell me about a few interesting chips and how you would use them?" rather than asking me to design a low pass filter with a given frequency response using a specific op-amp.
The deep dive I am talking about does not require anyone disclosing code done for their existing employer. Nobody wants that.
Frankly, I would also want to know about life outside of work. However, given our laws you have to be very careful about how you might probe for such information. I feel very strongly that our legal system has, to one degree or another, sapped all humanity out of our work life. I've worked in other cultures where it is perfectly normal for people to greet each other with a kiss on the cheek and a hug or pat on the back in the morning. In the US almost any physical contact can land an employer in court and a manager in serious legal trouble. But I digress.
So here's the thing: not everyone is you, not everyone is passionate about technology, and it's not reasonable to expect people to do more of their job outside of work for free. You might like, and that's great, but people have families and hobbies and interests that sometimes have nothing to do with the 40 hours they churn through for their bosses. I'm so sick of interviewing for companies who want "passionate" developers, which translates to "doing more work for free".
If you're curious about why we have workplace harassment laws, talk to basically any woman with a job and then rethink your sweet nostalgia.
> not everyone is you, not everyone is passionate about technology, and it's not reasonable to expect people to do more of their job outside of work for free
I am not sure how you would twist personal development and remaining up to date with "do more of their job outside of work for free".
Let's get away from technology for a moment.
You need to go to the doctor.
Would you rather go to a doctor who is passionate about their work and constantly devoting personal time to remain up to date on the latest research, drugs, studies, techniques and technology?
Or would you rather go to a doctor who has not devoted a single day in ten years to stay up to date?
I'd pick option #1 every time. Same with engineers.
Look, if you are not interested in remaining current, that's OK. Just don't expect to have access to the same opportunities. It's as simple as that.
> talk to basically any woman with a job and then rethink your sweet nostalgia
Wow. Not sure how you made the jump to harassment there. Gender has nothing to do with it.
> I am not sure how you would twist personal development and remaining up to date with "do more of their job outside of work for free".
Well, unless you're doing personal development at work during the 40 hours (or so) that you're required to be there, then you're probably not getting paid for it. I mean, I'm willing to tinker on my own, but you can be a good developer without doing it (you can also be a bad developer in spite of doing that).
> Would you rather go to a doctor who is passionate about their work and constantly devoting personal time to remain up to date on the latest research, drugs, studies, techniques and technology?
I want to go to a reasonably friendly, competent doctor. I really don't care how passionate they are about being a doctor, because I don't view passion as a proxy for quality (because it isn't).
> I'd pick option #1 every time. Same with engineers.
So my friend is a brilliant chemical engineer, and yet she doesn't sit around designing plants at home on the weekends. No, she hangs out with friends, sings in a choir, watches TV shows, travels, etc. I don't particularly understand the tech industry's fetish with eating, sleeping, and breathing code, and it's a damn shame that we're pushing away really fantastic nine-to-five developers.
> Look, if you are not interested in remaining current, that's OK. Just don't expect to have access to the same opportunities. It's as simple as that.
So it turns out that most software isn't created in Silicon Valley, and more money is made by crufty old Java and Perl enterprise systems than the next sexy JavaScript framework (which is probably just a poor rehash of a computer science concept Alan Kay developed in the '60s).
> Wow. Not sure how you made the jump to harassment there. Gender has nothing to do with it.
Gender has nothing to do with it if you don't experience the kind of issues that women in the workplace face, sure. If you're a man, you're not particularly affected by issues that affect women.
> You're limiting your applicant pool to people...with very little life outside of work.
Imagine that.
If your company exists solely to write CRUD apps in whatever JavaScript framework came out in March, you don't need to spend hours doing a deep dive into someone's side project todo list app. Unless, of course, you're looking for someone who will work 16 hours a day, 6 days a week, for one tenth of one percent.
> My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it.
So another interview and another day off work? Another set of interview approaches/questions that immediately eliminate people who don't spend their free time doing the same thing they do at work 8+ hours a day?
Here's reality: 100% of the technologies I work with today did not exist when I was in school. The only thing that has remained constant, useful and relevant is basic science, math, physics, etc.
What, then, make an engineer a good engineer in any domain? This applies to all aspects of engineering, from software to manufacturing engineering?
If I had to pick one thing I'd say their ability to remain current, learn and apply new unknown technologies through self study. Their flexibility and willingness to do so. Almost their drive to do so.
What I am interested in is someone who has the right approach and attitude for the job, an ability to solve problems creatively and a significant enough desire to learn. I am not looking for a robot that can memorize a hundred coding solutions in a month.
Part of the discrepancy here might lie in a difference in environment and stated goals. I have never worked in Silicon Valley but I have a feeling it is a dog-eat-dog mercenary environment where people are chewed-up and tossed out as quickly as others are hired.
If you are looking for quick hires and you are not looking at the idea of adding a team member for a long term relationship with the company and the goals of the business, yeah, sure, filter them through some quick "can you code this shit fast" puzzles and move on. Great! You are hired. Here's your desk. Here's your ankle chain. Now code away!
If, on the other hand, your industry and approach is such that you view people as a long term investment you really should not care about those skills. Anyone with decent ability can memorize coding problems. And it is worthless. What you are looking for is to bring someone on-board who will become a true asset for the business. I see it as almost short of looking for a partner. I don't care about memorized performance, I care about the ability to problem solve and the creativity, culture and thinking they can bring into the business.
These are two very different views. One is hiring cattle. The other is hiring people.
> If you are looking for quick hires and you are not looking at the idea of adding a team member
> filter them through some quick "can you code this shit fast" puzzles and move on. Great! You are hired. Here's your desk. Here's your ankle chain.
> One is hiring cattle. The other is hiring people.
You seem to be arguing against several points I never made. I took issue with your insinuation that you can just bring someone in for two hours and talk at length about some of their code that they bring it. That cuts out most of the hiring pool, which might be okay if you're Google, but for most companies isn't a smart move at all.
> What I am interested in is someone who has the right approach and attitude for the job, an ability to solve problems creatively and a significant enough desire to learn.
This has no correlation with programming as a hobby or having a wealth of freely reviewable code. Plenty of people love their job, are great at it, very creative, and fantastic technically and never write one line of code that isn't closed source or behind one or more NDAs. They go to work, do an amazing job, then go home after 8 hours and don't write any code or even touch a computer until the next work day.
If they don't have any code or project whatsoever they are able to discuss I have zero interest in interviewing them.
I have never said this is a universal formula for all to adopt. This is what I do. And it has worked very well for over thirty years across a range of engineering disciplines. Google and others can't take this approach because they need to hire people by the thousands. Not me.
Another interesting thing is to talk about someone's hobbies and passions outside of work. This is where you can learn so much about a person. People are passionate about one or more things and that is a reflection of their personality.
We do a lot of work in aerospace. There are very obvious legal barriers to disclosure there. Yet, I have always found that most engineers who are truly engaged with their craft have enough interesting things to talk about outside of work that you can really get a sense of who they are and how they will approach work.
An interesting example was when I needed someone to work on some Python code. I brought in people who had zero experience with Python. I could not care less about that. I wanted someone with some of the qualities I have already mentioned. I ended up hiring a programmer with lots of C++ experience and no Python chops at all.
The first three months were dedicated to taking a deep dive into Python while getting up to speed on the project. After that the focus shifted to the project itself. This person has been with me for many years and doing an amazing job with various technologies we didn't even know we would touch when I hired him.
I know this person can pick-up any technology we might need to utilize and do an excellent job of it.
The investment is in the person, not the technologies or the ability to memorize coding puzzles.
So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?