One of the things I've done is to hand a candidate some existing code and ask, "What do you think of this code? Do you see any obvious problems? Are there things that work but could be done better? Is there anything exceptional in there? Tell me what you see." This allows you to test that they know how to read code, which is what they'll be spending the majority of their time doing. You can ask them how they'd improve it, which should give you an idea of how they write code, too. And of course, you can see their experience by checking out their resume and if possible running some of the apps they worked on. And if they have any code on GitHub, etc., you can check that out, too.
One of the companies I interviewed at had me do this exercise at the end of the interview and to be frank, I bombed it quite badly. One issue was the syntax was so weird compared to the type of code I'm used to writing and reading from others in library code that it was hard for me to comprehend the logic without the benefit of looking it up.
I was filled with anxiety working under the time pressure to understand a document of code which I had very little context of, and no previous relationship with the reviewer so I kept thinking to myself whether or not the question that came into my mind was stupid obvious.
In contrast, when I had take-home tests, I scored exceptionally high on all of them, leading to offers. I recognize that a lot of people here hate them because of the time involved and it's akin to spec work, but IMO it felt much more like my usual day-to-day life as a developer.
One of the take home tests had existing code to work from but again, working at my own pace and having access to online resources to read docs was much less anxiety provoking.
These sound like very valid issues. It might not be good for every candidate, but having a conversation about the code seems less stressful to me than having the interviewer bring out a whiteboard and essentially say, "Please perform for me!"
You say:
> One issue was the syntax was so weird compared to the type of code I'm used to writing and reading from others in library code that it was hard for me to comprehend the logic without the benefit of looking it up.
From the point of view of an interviewer, that's feedback I'd be interested in. One problem I've seen in some of our code is an engineer using a completely valid but very obscure method of doing something, and then the rest of us having difficulty maintaining it. I would want to hear, "this looks hard to maintain." But I understand that in an interview, it can be difficult to assess what the interviewer wants to hear and that can be nerve-racking. I personally think take-homes are a reasonable compromise, but not everyone does.
You can work on that anxiety, just like you ace programming tests with enough time & effort. Therapy, especially group therapy might be really helpful.
Yes! I've been on the interviewee side of this a couple times and absolutely love it. It has so many nice properties:
1. It fosters meaningful conversations about code that is not dependent on the candidate solving a toy problem.
2. As you said, it tests a candidate's ability to read and understand code.
3. It's actually representative of the type of work you _will_ do at any given company, i.e. code review.
The major downside is if you give the candidate code in a language they're totally unfamiliar with then that candidate will likely bomb. I think this can be mitigated by sticking with mainstream languages like C/Java/Python, or domain specific languages where not-knowing would be a deal breaker anyway, i.e. must know Swift for iOS dev.
I do this as well. It's the best signal to noise ratio. Developers spend much more time reading code and understanding the system rather than writing code, yet interview questions don't acknowledge this.
It also works even if the person doesn't know the language because you'll get to see them mapping this new language to something they already know and it can give a good understanding of how well they think of things beyond just the code in front of them.
I have create a git repo specified for the question, with some code working in way, but buggy, such as logical bugs or race conditions...etc. with a lot of not business relevant assumptions. I usually told the candidate what this code supposed to do, and ask him to review the code first, then tell me what was his impression on the code base, and what were the problems, and how he can fix it. By doing this, I can judge the candidate if they are good at general coding, debugging and and comfortable to work on projects which they are new to, as well as their mindset on writing maintainable software.
A good candidate will not just fixing the obvious issue, but propose some architectural changes, then I will ask them what are the strategy to do so as the project has existing dependents, this can give me signal on how the candidate coordinate with other teams.
Then I will ask him some more questions related new features, and scaling..etc. to measure his design, communication skills and more.
It never failed me for senior level positions hiring, that either the candidates were hired and proven to be a great match, or they got a better offer elsewhere.
This is pretty similar to a ML Engineering interview question I got once. Basically, you get some mildly obfuscated code implementing a statistical concept and you have to tease out what the code is doing. Then you have to fix a few bugs, the variables names, and make it easier to read.
If I had to do interviews I'd do this and something complementary to this: bring a piece of code you're especially proud of. What problem were you trying to solve? How did you try to solve it? What options did you discard? Why did you discard those options? What resources did you use? How do these concepts/solutions relate to the CS theory you learned in school/your own?
I don't really have code I can show you. Most of my code I write is in my employer's VCS. I have some throwaway scrips on Github, but those not production grade.
LeetCode could be a good source for code for this.
Pick some interesting problems from there, and without asking the candidate to actually code a solution, discuss the problems with the candidate. Ask for ideas on how to approach the problem, and suggest some yourself if at any time they appear to be getting stuck.
After they, possibly with guidance from you, have reached an approach that if correctly implemented would solve the problem, including meeting time and space requirements, discuss what issues might arise in actually implementing it, such as edge cases that might require special handling. This would be a good place to talk about how they would go about testing an implementation.
Finally, go to the discussion on LeetCode for that problem. There you will find various solutions posted by others. What I have found looking at those is that a lot of them don't meet the time/space requirements, or miss edge cases, or sometimes are just wrong. Go over a few of these with the candidate and have them criticize them for you.
Anything leetcode related comes down to rote memorization. If LC is part of interviewing process you are hiring people who good at repeating things they’ve memorized, have a lot of stamina to spend hundreds of hours doing meaningless work and are very good at following orders. If that’s what you need than it’s a great filter.
You can save some effort though and just hire anyone who passed Chinese or Korean grueling school system with emphasis on standardized tests. LC-based interviews follow the same tradition.
It’s very company-dependent, but most are not wanting a regurgitated answer. If you have a solid grasp on data structures and traversals, you can solve a lot of those puzzle problems. Sure some have tricks, but they’re not completely pointless and certainly don’t indicate anything about the person being willing to “spend hundreds of hours doing meaningless work” or are “good at following orders”.
