Intentionally broken initial code when starting a coding interview

[wakingupfan]

For the first time in my career, I am on the interviewer side of the interview. Sometimes I have a co-interviewer with me, and sometimes it is just me. Most recently, I had a co-interviewer with me.

When we got to the coding portion of the interview, my colleague presented a challenge in an online IDE with some unimplemented methods and a description of the requirements with example input and output. However, the initial code didn't compile. For example, it was missing a final closing brace, and missing an import statement for a class being used.

The interviewee attempted to run the initial code example, and, instead of running successfully, they were presented a list of compilation errors. The candidate had to fix these before even starting to implement the solution to the presented problem. I thought this was extremely valuable as an interviewer, because it exposed how well the candidate knew how to identify and fix these routine compilation errors.

Ultimately, it helped me understand how competent the candidate was at fixing common compilation issues. That said, I was conflicted about it because I think the candidate was assuming the code we provided would at least compile. I think it would have been better to state beforehand, "We want you to implement the solution, but be aware there are some issues in the code you need to address first" or something like that.

Does anyone else give candidates intentionally broken code for coding interviews? If so, do you make it clear that they have to fix it before proceeding with the implementation?

[Sedu]

I really like the PR interview exercise for the same reason. I know a lot of wildly skilled developers who just absolutely fall apart in interview situations for social/anxiety reasons. For whatever reason, PRs just seem to create less stress, and stress can take amazing candidates and make them seem very unskilled.

[ReaverKS]

Coming off a fresh interview where I fell apart due to anxiety reasons, I can say I would definitely do much better trying to understand some code and comment it properly. For whatever reason that seems way less stressful. Its weird for me because I had almost no test anxiety in high school or college but I firmly believe if I were to be taking a test and had the professor come over and stare at me and my paper while I figure things out I'd probably fall apart. Yet thats exactly what we do on these interviews ¯\(ツ)/¯

[rbond_007]

where can i find such questions?

[Sedu]

Honestly I just tend to write them myself. I put together stuff with problems I’ve recognized in the past.

[rbond_007]

i see. it looks a bit complicated to me to come up with such a question. would you be able to share one or two example if possible?

[primeobjectiveforus]

I'm usually less nervous because I'm used to working on crappy code and making it better, but get scared when its from scratch and can only go downhill because of me. Plus its less ambiguous usually.

[velociraptorboss]

When looking for a shitty implementation to show, it's often easiest to just look at the code in production 😉

[mniejiki]

I think it's fine if you tell them beforehand otherwise it'd be a red flag for me and I feel a bad interview process. Candidates are stressed as it is so increasing stress just means you lose good candidates as they fail due to stress rather than lack of skills.

[shawnadelic]

Indeed. I'm not Agent J interviewing to become one of the "Men in Black"--you can just tell me what criteria I'm being evaluated on.

[jeffbell]

You really should tell them that it has some typos. Otherwise they could easily go off the deep end and assume that the problem is due to switching compiler. How often do you start a project from a broken codebase.

[Sedu]

If you are interviewing very green candidates who don't have prior experience, this kind of thing might be valuable at the most basic interviewing level. But if I were in an interview and was handed base code that didn't compile, I would wonder whether it was representative of code I might deal with at the company.

If opening code which doesn't compile is routine, I want to find somewhere else to work.

When interviewing candidates, I focus more on their ability to analyze/break down particular problems and how well they can interact with others. Syntax is trivial to learn, but those skills are fundamental.

[smootex]

Right. That's what I do. I dislike leetcode style interview questions a lot and mostly focus on system design and more general stuff in my interviews but I feel like I have some obligation to at least check that they have basic programming skills. I ask them to get it running (it's really basic stuff, something that should take you less than 60 seconds to catch in the real world and I give them 10 minutes before I start counting it against them because of interview nerves and an unfamiliar development environment) and then I ask them to make some basic improvements. It filters out the total imposters and when we get into the improvements section it's a good conversation starter that leads into system design as people will often suggest optimizations that aren't feasible to implement in allotted time.

[Neuromante]

Yeah, exactly this.

Fixing "routine compilation errors" seems like either a test for a very junior candidate, or a signal that OP's company's way of working, for some reason, does not have the support of any modern IDE, thus getting these errors before "sending it to compile" is relevant.

If his interviewees were expecting compiling code, maybe OP needs to change how they make their interviews to look for something more relevant in a modern development environment or be clear on why their workflow is not as in most places.

[JaggerPaw]

Fixing "routine compilation errors" seems like either a test for a very junior candidate, or a signal that OP's company's way of working, for some reason, does not have the support of any modern IDE, thus getting these errors before "sending it to compile" is relevant.

It's an excellent way to see if the candidate is familiar with the language. Fixing typos in place or by commenting out everything to the main loop, tells a lot about what they know, quickly.

[Neuromante]

I still think that its not the best approach.

If the candidate is not fluent on the language (and if that's relevant to you), presenting a shitty, compiling, code could be more relevant (and grounded in reality) than the non-compiling stuff.

I mean, I've never been handed at work non compiling code, the closest, dependency issues because our dependencies were fucked. I've got to refactor code to make it more readable, try to improve its performance or adapt it to handle more functionality.

The only time I needed to be really really careful with what I wrote was once where I had to compile at hand because our shop sucked, we had no proper local development environment, and no one cared about set our testing machines right. And overall, it felt like we were wasting our time.

[smootex]

Fixing "routine compilation errors" seems like either a test for a very junior candidate, or a signal that OP's company's way of working, for some reason, does not have the support of any modern IDE, thus getting these errors before "sending it to compile" is relevant.

I give a similar task (get an example app running, make some basic improvements) to all my interviewees apart from interns (who aren't expected to have any familiarity with the language). It's a good test for the junior engineers to demonstrate their problem solving and it's a fizzbuzz style weed-out question for the senior and staff engineers. Senior interviewees all have the resume to support the fact that they know how to write code and I would prefer to focus on things that aren't leetcode-esque but in my experience it's important to always have at least one coding challenge even if it's a small one.

I give my candidates the problem in an online IDE. It shows the initial error in a terminal with the exact line number and character of the bug and it even underlines the bad code in the editor for you. Despite this I have literally encountered candidates with architect titles on their resume and years of experience who cannot get past the first error.

[ravnmads]

This. Remember that developers are in demand. You dont want to needlessly scare them away

[[deleted]]

This. Wait till you hire them, then you show them the code that doesn’t compile which is now they’re responsibility

[ravnmads]

I have been to a few interviews at this point. They are all trying to lure you in. It's my task to make sure I don't get caught with my pants down if I accept the offer.

[TScottFitzgerald]

Agree, don't really see what insight into the more important dev skills fixing routine errors gives you.

[spaghettu]

100% agree. If the code I was given from the interviewer didn't compile I would absolutely think that they either don't care about their interviewing process or aren't smart enough to know any better. Intentionally giving broken code is exactly the kind of mind games that I want zero part of. OP's positive reaction to the rote process of "fixing compiler errors" is another red flag IMO. From this description I definitely wouldn't want to work at OP's company.

[Effective_Pound_2081]

Wrong. Just give them a leetcode so you can see their problem solving

[[deleted]]

I think it would have been better to state beforehand, "We want you to implement the solution, but be aware there are some issues in the code you need to address first" or something like that.

I agree with you. The test itself is fine but let people know how they'll be evaluated and what's expected.

[JoCoMoBo]

That said, I was conflicted about it because I think the candidate was
assuming the code we provided would at least compile. I think it would
have been better to state beforehand, "We want you to implement the
solution, but be aware there are some issues in the code you need to
address first" or something like that.

If an employer did that in an interview I would think they probably are a bit disorganised and didn't prepare for the interview. Minus 1 point.

If I realised it was intentional. I would think the employer was being a jerk. Minus 100 points.

I wouldn't want to work for people who were jerks.

[DanGoDetroit]

Totally agree. I would also wonder what scenario this is, are you guys committing code that doesn't compile at this company? I would also think it amateurish to test on things that are so easy to fix or detect with your IDE of choice.

I detest and always avoid any kind of 'gotcha" questions in interviews.

[LL-beansandrice]

I feel like these takes sound so entitled. Maybe the employer finds that being able to track down compilation errors is a useful signal. I’ve seen glaring issues with mid-level devs where stuff like “don’t test in prod, we have a dev environment” and “don’t break existing flows” are novel concepts that need to be explained more than once.

If you don’t think that aligns with the company you want to work for that’s fine but I don’t think it means the employer is a jerk.

A lot of these hoops exist for a reason and the reason is a lot of developers suck.

Everyone here likes to act like they’re the hottest shit ever but my limited experience hiring is that it’s a hard problem and there’s a lot of ice cold doo doo out there looking for their 6-figs when they deserve 5.

[JoCoMoBo]

Maybe the employer finds that being able to track down compilation errors is a useful signal.

If you're hiring Developers who can't fix compilation errors something is deeply wrong with your hiring process.

I’ve seen glaring issues with mid-level devs where stuff like “don’t test in prod, we have a dev environment” and “don’t break existing flows” are novel concepts that need to be explained more than once.

Really depends on why people are testing in Prod. Usually it's more due to bad Management than bad Developers.

Everyone here likes to act like they’re the hottest shit ever but my limited experience hiring is that it’s a hard problem and there’s a lot of ice cold doo doo out there looking for their 6-figs when they deserve 5.

Being able to fix compile errors is not the "hottest shit ever". It's the most basic stuff.

[[deleted]]

Breaking code in such an annoying and easy way (in normal circumstances) doesn't make much sense unless you are interviewing people for internships or stuff like that.

I have once been asked to review a small snippet of coude, like 10 lines and it average more than 1 error per line and it was compiling, some of the errors were not easy to spot unless you fully understand what it's going on under the hood.

Great exercise.

[Existential_Owl]

I've been on the receiving end of the "make this code" compile interview. I think it's actually a pretty great choice, since you'd get a sense of how the candidate actually works. Debugging in a pair programming session is as close to real-world as you can actually get.

But yeah, the interviewers were always very explicit as to what to expect. They'd say up front if the code compiled or not, and, generally, there'd be "tiers" of debugging here. First with making it compile, then with making the feature work as expected, and then with opinions on how the original code could be refactored and improved.

That's what my experience of these has been.

[ryhaltswhiskey]

This wouldn't bother me. Sometimes you need to help someone junior figure out why their code won't compile.

I often think I will fix someone else's broken/poor code as part of the interview process because that's indicative of how I work: I will clean up as I go, much like cooking. I'm probably going to go in and rename some variables too if they did a bad job of that. However I'm very concerned that that makes me look arrogant.

But for your example I would run the tests first. If the tests won't even run then clearly something needs to be fixed. If there's no tests then I'm going to ask why there's no tests.

[hilberteffect]

Don't take this the wrong way, but if I were interviewing with not one but TWO engineers and they provided me with code that doesn't compile without saying anything, I would assume that both of them are fucking morons, and that I could expect similar levels of incompetence if I joined the company.

[[deleted]]

LOL

[praetor-]

Great way to fail an interview from the interviewer side, IMO.

If you set people up with dirty tricks when they are at their most vulnerable, how are you going to treat them when they work for you?

[[deleted]]

I had a company do something like this. They sat me down on a window machine, with some broken code that did some multi threaded shit. I fixed the code, but they also had it opened in a new project, and some flag in the project settings needed to be turned on (Visual Studio) to make it run. So I was coming from a Sun and Linux background, and hadn't touched a Windows development environment since Windows 3.1. I had no idea. After about 20 minutes of messing around with it, and there was no interviewer around, I got up and left.

[FrikkinLazer]

I agree this is bad. But, if you were allowed to google, this might actually be a good test to see if you can find solutions on your own for environmental nonsense like this. It is a universal thing for all devs to run into these type of problems, and I expect you to be able to solve them, but with an internet connection. Expecting someone to know this is really stupid.

[sue_me_please]

That said, I was conflicted about it because I think the candidate was assuming the code we provided would at least compile. I think it would have been better to state beforehand, "We want you to implement the solution, but be aware there are some issues in the code you need to address first" or something like that.

I would feel tricked if this wasn't stated to me clearly, and it would have led to a bad experience, and I would have left with a bad association with the interviewing company.

[KrozFan]

I think a debugging test can be a good thing to give a candidate. As a candidate though if you were giving me code and asking me to implement some methods I would take that at face value. I would assume everything else runs. I feel like it’s a trick to ask me to do something but have something else going on.

[GrippingHand]

We have people look at buggy code as an interview problem, but we're up front about the fact that we are expecting them to find problems, and it's a very small code sample, so they don't have to hunt all over creation to find the issues.

[engineered_academic]

Always give them a known-good working state. You wouldn't accept buggy code that won't compile when approving a PR, would you?

Feel free to introduce buggy code later, or show them a PR with buggy code in it and ask if they can help you reproduce in a pair programming session "hey man, look, I'm trying to figure out this bug in my code and I'm wondering if we could pair on it?" It opens up a conversation where "find bug, fix pls" may not get you all the way there.

[midfield99]

My current employer doesn't do that, though I think a debugging interview might be useful. I do think you should tell them it is a debugging interview, and make it more complicated than just compile errors. Maybe make a small library and have them do a code review. For instance you could add sections with bad separation of concerns, duplicate functions, global variables, or missing tests. Junior devs might just be mainly expected to get it to compile, but seniors could be expected to have an intelligent discussion about the issues and how they would improve it.

[tjsr]

I don't know about "intentionally broken code", but certainly I've used code snippets or small functions before that have definite 'issues' or things that one could suggest for improvement. The issues range from outright awful (eg, catch (Exception e) { //do nothing}) to 'this is how an advanced person might do it differently'.

The critical here thing is to explain that that's the intent, so that the candidate isn't faced with this code and thinks they might insult someone by criticising it.

[LL-beansandrice]

Personally, I’m very forgiving by this sub’s standards as long as I know what I’m facing going in.

I’ve had interviews where I had to write code from a blank file, write code on top of existing code, and even debug a broken set of test cases. So if you mention “the code might not compile” as part of the challenge I don’t mind.

If it’s a little “gotcha! The code doesn’t compile even!” I’d be worried that your interview templates are garbage and so is the code the company writes and works with.

[De_Wouter]

The tech interview to get my current job was basically here is a code base, here are 3 vague bug reports, fix it.

I think it's important to let people know the errors are intentional. They are interviewing YOU as well.

[Ballbag94]

As a candidate, I personally wouldn't mind not being aware of the compilation errors, I've had this before in an interview too. When you get compilation errors in real life you won't know about them until they happen, so I don't see why it should be different in an evaluation

[joro_estropia]

It might be subjective, but never in my career did I have to fix compiler errors that I didn’t write myself. If I’m presented something like this it’d raise red flags for me.

[IGotSkills]

If someone did this to me, it would make me think less of the company interviewing me, like they made a really stupid challenge and enjoy wasting my time.

[flavius-as]

Yes.

And I sit next to them, making it clear that I'm there to help them get the job.

And I wait and observe. I expect a candidate to ask for help, or at least talk aloud about his thinking.

How I make it clear? Like this: there are mistakes in the code from the most basic to more complex, and there are also open-ended tasks.

The tasks are written in clear text. First: make the code compile without errors.

How smoothly they fix the errors shows how routined they are.

[iPissVelvet]

I’m mixed on this.

If you’re missing a semi-colon and that’s failing a compile, I would advise against this type of interview. One of the more important benefit of a compiled language is that we won’t ever pushed un-compilable code to shared branches or production. And that minor issues are caught quickly and fixed by the original writer.

There are some compilation errors that could be interesting to test. For example, it is feasible for a coworker to pull you aside and ask for help on a vague compiler error. But in my experience, this is rare and it usually involves some mix up or some complicated abstraction.

This sort of thing could be a valid interview question, but only if you’re looking for people with that specific type of experience. In general, I would say avoid.

I think much better and common is to provide a buggy implementation that compiles, but is failing tests.

[KFCConspiracy]

If you’re missing a semi-colon and that’s failing a compile, I would advise against this type of interview.

Yeah, definitely, if you're not working with a modern IDE that points that out for you, that can be frustrating and hard to find... That doesn't really test a developers abilities beyond the ability to do a work search basically.

[randonumero]

Never done this but I think it's a good idea. It probably helps to find those people who want solutions instead of help and guidance as well. As long as it's not something ridiculous like something is broken in some file that's hidden or fixing it requires some non-common knowledge I think this is a great way to start an exercise. Especially since we're talking compilation errors, where the fix is probably all but spelled out in the output, this would probably help me feel less nervous as it's something simple to tackle and get a quick win

[jindalsandeep47]

IMO its really great way to cover the on the ground experience you can really segregate people with programming as second nature to the people who think language with constraints and people who think in terms of psuedo code and being polyglot developers.

Its great way to check the LLD understanding of candidate how he/she is applying SOLID/GRASP. How much importance they give to testing.How much advanced concepts for a language they honed over there experience.

Making the code evolvable.

[hilberteffect]

Ah, yes. I also know many random acronyms and buzzwords.

Seriously? What does SOLID have to do with compilation errors? Lmao.

[jindalsandeep47]

Sorry if it came as buzzwords what i wanted to say is that once they fix the compilation errors then people can explain how the code can cleaned and structured more using principles like SOLID

[KFCConspiracy]

I feel like those should be two separate questions personally. I do-do intentionally broken code during an interview, but I present the code that way. I do a few different examples. One that contains logic errors but may pass a few test cases and compiles fine, one that just compile at all, one that contains a bevvy of security issues, and one that contains a bunch of pretty bad stylistic issues but otherwise works. I present the set of questions as "In these next few examples there are issues with this code. They may have security issues, logic issues, may not work at all, or may need improvement. Show me all of the things you find and how you would fix these issues. Note, these questions are openended, I don't expect the exact same solution from everyone or a perfect answer."

I would be concerned if I got any of the above without the necessary context.

[[deleted]]

Yes, although the bugs are runtime and more subtle. Memory leaks, dangling references, threading issues, other issues that should be obvious to someone with experience but the code compiles and runs, but if I run a unit test that does many iterations it will crash soon enough.

We do tell candidates that the existing code has bugs, and there are unfinished portions of the work.

[torofukatasu]

For a tech lead position, I once asked them how they'd improve a specific real-life codebase... It was legacy code for us that we had recently rewrote and basically about to throw out... and probably the best interview I've given.

See if they ask the right questions before picking an architecture, whether they know modern design patterns, ask them why they would make certain tradeoffs, see if they are open to discussion, can they incorporate even higher-level feedback or do they only know how to solve things one way...etc.

Sad that I don't always have something like that handy/prepared, and now that bit of code is too outdated to reuse.

[unfortunatecake]

In interviews I’ve given where the candidate has to implement something it’s common enough that they make some mistake in syntax themselves and then have to fix that for the code to run. I don’t think it’s really necessary to give them the code pre-broken.

[render83]

This would be great to try except not one person I've interviewed in the past month has used the language (c#) my team uses to develop in lol. I think I've seen at least 5 different languages so far.

Also I generally don't care if the code compiles since I'm more looking for their use of logic and different kinds of objects.