3 ms·

I'm a tech lead in my team. Honestly, I am terrible at whiteboard questions. I've long forgotten a lot of details that I've studied so hard in my CS degree. If

I'm a tech lead in my team. Honestly, I am terrible at whiteboard questions. I've long forgotten a lot of details that I've studied so hard in my CS degree. If I go to interviews right now without adequate preparation I am very likely to bomb pretty hard! But that doesn't mean I'm a bad developer or that I neglect my duties as a tech lead. It means that interviews are testing something pretty far removed from what we're doing at work. It's even worse in some companies that just give you a bunch of CS questions to solve, because a lot of the time it's possible for candidates to just memorize a bunch of interview questions and rely on that, regardless of their actual problem solving skills. There might a better way. When I interview candidates I've started putting less emphasis on O-notation algorithms and how to optimize them, which is pretty much the norm in most tech interviews (make this faster, do this in-place, etc), and started putting more emphasis on the candidate's understanding of IO, specifically when working with databases, congestion, rate limiting, queues, the stuff you actually encounter when working on real projects in my domain. Asking open ended questions and basically building a tiny project together. The experience has been enlightening. You can immediately tell the person's analytical thinking because most of what they learn in "interview prep" isn't directly helpful in this situation. You can see some people frantically trying to match the problem with something they've seen in a video or a book instead of stopping for a moment and giving it some actual thought. At the present I'm pretty certain that asking a person to build something is the best approach to understand their skill level. But this requires more time from both parties.

YZF 5y ago
Someone is going to come and make the point that if you want to get a job at "Booble" then you gotta put in the hard work to get it because there's a million other people that want that job ;) It's not black and white. I do think that as a tech lead you need to be able to demonstrate some technical skill in your day to day. You should be a pretty good coder. You should be a pretty good debugger. You don't need to be a competitive programmer which is what some coding problems are modeled after. You do need to know enough of your CS to recognize a pattern where there's theory that matters. You do need to be able to look up the relevant info/papers in that case and be able to understand them. There's also a plethora of other things you need to do as a lead that related to the engineering side of things. design and architecture. testing. CI/CD. requirement management. project management. people skills. Sort of reminds me of the joke where you take your car to the repair person because the engine is making noise. The guy listens to hit and hits a spot very hard with a hammer and the engine is running again. No noise. The bill says $100. So you ask him $100 for hitting a spot with a hammer? He's like $1 for hitting the spot with the hammer, $99 for knowing what spot to hit. Coding some dynamic programming algorithm on the fly in an interview is hitting the spot with a hammer really hard. Knowing what spot to hit is most of the what you care about in a good software engineer.
- magic_hamster 5y ago
  Good insight. As a tech lead I do all those and then more. Also tons of code reviews and also need to understand what the DevOps guys are doing and handle the product guys and their plans. Sure it's not black and white and every team needs to hold interviews in a way that befits them most. For our team the ideas I described work pretty well and we've been able to pretty much nail it from students to seniors. I am just advocating that recruiting should not be a one-size-fits-all thing and that the massive prep industry is only focused on a certain type of interview, which is just not always the interview you should be conducting. Give it thought and spend the time to tailor the interview process to your team. Here's to everyone's success while interviewing!
billllll 5y ago
It sounds like you've described a "system design" interview, which all (to my knowledge) of the big tech companies utilize for more senior roles, and which also have a wealth of study materials for. I'm also curious what your pass/fail conditions are? I find that if the pass/fail conditions aren't rigorous, then you open yourself up to things like "I just really like that guy," and select for people more similar to you rather than people who might bring the most to the table.
- magic_hamster 5y ago
  It's a version of that, but for candidates of all experience levels. Of course I don't expect a junior or even a student to give the same answers as a senior. But you can already tell some people have better understanding and intuition about how things work besides purely theoretical algorithms. Using open ended questions and building a small "system" together allows you to draw the actual knowledge limits of this person and pivot when something gets too hard so you can explore another 'direction' which will be based on different areas of knowledge or experience. It also allows the candidate to show off if they really want to feel smart. You mentioned that it can introduce more bias to the process, so before I touch on that, I think it actually introduces a chance to test your communication with this candidate which (at least for me) is pretty much equivalent in importace to their credentials. As for passing conditions: I prepare a standard "interview project" that has many different paths for us to work on. We work it together but it's mainly the candidate. Alongside the problem I have a fairly substantial excel sheet for assessment of all candidates. Every component in the "interview project" has some pitfalls, some more obvious than others, all occuring naturally in every path the candidate chooses. You start seeing who can see ahead and think on their feet in a situation that more closely resembles what we do in my team. Eventually I can compare the candidates based on this standardized performance sheet, so I'd like to think it's not too biased. As a bonus, it's a pretty good experience. I know it was a good interview when the candidate thanks me for learning something valuable. It's a great interview when I learn something as well. Sometimes they want to stick around and continue tackling the problem even after we're done, or they want to actually build a POC and send it in!

YZF 5y ago

Someone is going to come and make the point that if you want to get a job at "Booble" then you gotta put in the hard work to get it because there's a million other people that want that job ;) It's not black and white. I do think that as a tech lead you need to be able to demonstrate some technical skill in your day to day. You should be a pretty good coder. You should be a pretty good debugger. You don't need to be a competitive programmer which is what some coding problems are modeled after. You do need to know enough of your CS to recognize a pattern where there's theory that matters. You do need to be able to look up the relevant info/papers in that case and be able to understand them. There's also a plethora of other things you need to do as a lead that related to the engineering side of things. design and architecture. testing. CI/CD. requirement management. project management. people skills. Sort of reminds me of the joke where you take your car to the repair person because the engine is making noise. The guy listens to hit and hits a spot very hard with a hammer and the engine is running again. No noise. The bill says $100. So you ask him $100 for hitting a spot with a hammer? He's like $1 for hitting the spot with the hammer, $99 for knowing what spot to hit. Coding some dynamic programming algorithm on the fly in an interview is hitting the spot with a hammer really hard. Knowing what spot to hit is most of the what you care about in a good software engineer.

magic_hamster 5y ago
Good insight. As a tech lead I do all those and then more. Also tons of code reviews and also need to understand what the DevOps guys are doing and handle the product guys and their plans. Sure it's not black and white and every team needs to hold interviews in a way that befits them most. For our team the ideas I described work pretty well and we've been able to pretty much nail it from students to seniors. I am just advocating that recruiting should not be a one-size-fits-all thing and that the massive prep industry is only focused on a certain type of interview, which is just not always the interview you should be conducting. Give it thought and spend the time to tailor the interview process to your team. Here's to everyone's success while interviewing!

billllll 5y ago

It sounds like you've described a "system design" interview, which all (to my knowledge) of the big tech companies utilize for more senior roles, and which also have a wealth of study materials for. I'm also curious what your pass/fail conditions are? I find that if the pass/fail conditions aren't rigorous, then you open yourself up to things like "I just really like that guy," and select for people more similar to you rather than people who might bring the most to the table.

magic_hamster 5y ago
It's a version of that, but for candidates of all experience levels. Of course I don't expect a junior or even a student to give the same answers as a senior. But you can already tell some people have better understanding and intuition about how things work besides purely theoretical algorithms. Using open ended questions and building a small "system" together allows you to draw the actual knowledge limits of this person and pivot when something gets too hard so you can explore another 'direction' which will be based on different areas of knowledge or experience. It also allows the candidate to show off if they really want to feel smart. You mentioned that it can introduce more bias to the process, so before I touch on that, I think it actually introduces a chance to test your communication with this candidate which (at least for me) is pretty much equivalent in importace to their credentials. As for passing conditions: I prepare a standard "interview project" that has many different paths for us to work on. We work it together but it's mainly the candidate. Alongside the problem I have a fairly substantial excel sheet for assessment of all candidates. Every component in the "interview project" has some pitfalls, some more obvious than others, all occuring naturally in every path the candidate chooses. You start seeing who can see ahead and think on their feet in a situation that more closely resembles what we do in my team. Eventually I can compare the candidates based on this standardized performance sheet, so I'd like to think it's not too biased. As a bonus, it's a pretty good experience. I know it was a good interview when the candidate thanks me for learning something valuable. It's a great interview when I learn something as well. Sometimes they want to stick around and continue tackling the problem even after we're done, or they want to actually build a POC and send it in!