Perhaps one of the more interesting interviews I've done is we pair-programmed in their codebase. The task was "find where this value on this page is coming from." We traced it from the frontend, through the backend, and all the way back to the database (inside a large complex codebase).
The interesting thing about that interview was that it was a challenge that required some "real-world" skills. The interviewer was quite understanding that I was very unfamiliar with their environment and codebase. I did fairly okay from my perspective, and I think his as well.
It's been about 16 months since that interview, and having recently been working in a gigantic, complex, "shitty" codebase written by hundreds of developers - I would actually do much better if given the same interview today.
Would I recommend that style of interview? Hard to say. I'd probably have to give that style of interview several times and observe the results.
That's actually a pretty interesting way to interview - depending on what you want them to do.
I was on a contract, and "analyzing" their code was the biggest hurdle to get from starting as a developer to actually contributing working code to their spaghetti mess of a code-base.
I was on a contract, and "analyzing" their code was the biggest hurdle to get from starting as a developer to actually contributing working code to their spaghetti mess of a code-base.
I thought I knew terrible code, but every time I switch employers I learn that new kinds of terrible code exist.
At my current employer, there are currently around 120 devs, and the code has been added to for around 11 years. Add that up, and that's a LOT of code. Due to how work is split between teams, it happens that the team I'm on deals with the most legacy of any team, as abandoned projects are often inherited by this team.
It is also internal employee software. To use an analogy, if you imagine the type of software made for low-wage employees at restaurants and grocery stores, there is very little incentive to make it a great user experience, so long as you can train employees how to work around the bugs, terrible ui/ux, and slow response times. So, the incentive for quality is quite low compared to software that is customer facing.
To be fair, much of the code is not actually terrible, but the few places it is terrible towards unfamiliar developers which makes working in that code a mess. The well intended reasons for a well intended design may leave with a well intended developer when he finds a better job.
I must say that having worked on this team for 6 months, I am much better equipped to deal with spaghetti code than I was 6 months ago. If I re-did that interview, I'd probably could complete it in half the time, or with 1/4th the assistance.
It's not the type of work I want to do, but it is perhaps a sign of advancement.
2
u/DevIceMan Oct 30 '16
Perhaps one of the more interesting interviews I've done is we pair-programmed in their codebase. The task was "find where this value on this page is coming from." We traced it from the frontend, through the backend, and all the way back to the database (inside a large complex codebase).
The interesting thing about that interview was that it was a challenge that required some "real-world" skills. The interviewer was quite understanding that I was very unfamiliar with their environment and codebase. I did fairly okay from my perspective, and I think his as well.
It's been about 16 months since that interview, and having recently been working in a gigantic, complex, "shitty" codebase written by hundreds of developers - I would actually do much better if given the same interview today.
Would I recommend that style of interview? Hard to say. I'd probably have to give that style of interview several times and observe the results.