I once had an in-person interview where they gave me a sheet of printed code and asked me to point out the syntax errors. Some interviewers are absolutely insane.
More than a decade ago I had an amazon interviewer write some perl on a whiteboard, and ask me to find the error.
There were two - I pointed out both and they didn't seem super happy about it. To this day I'm still not sure if one of them was an unintentional error.
A past employer of mine used to have one of these. It was a true work of art: around two dozen lines of code with something to discuss in EVERY SINGLE LINE, ranging from dumb syntax errors to logic errors to problems of overall design. Made for some great conversations.
The problem I see is that it probably looks really dense and complex the first time a candidate sees it. This is not a great way to start the interview. To me it comes across like "find Waldo in the next 30 seconds. Also there's a bunch of other characters hidden in there. Go!" We all know what we're looking for (kind of) but it's a very stressful approach. It might work better if you paired and wrote this crazy code, and looked to them to identify issues as you built it up.
I had to review someone's PR for one interview. Ultimately I failed it because me feedback focussed solely on implementation details and asking if there are better ways to solve the problem (with some suggestions as a nudge). Apparently, that was fantastic and showed all the qualities of good coaching...but they expected me to point out all of the instances of poor indentation and other aesthetic things. My justification that it was unimportant and that running rubocop would fix it wasn't good enough - the PR had to know all of the nitpicks.
You know, if I had to do that for every PR I reviewed, I'd be burned out in no time.
It was a shame, but if I didn't flunk that interview then I wouldn't be where I am now.
Done right there will be a lot more in there than syntax errors. A good example of this sort of test will separate those who have revised syntax without really thinking (they'll get the syntax errors but little or nothing else, great if you want to employ a human linter) from those who actually think about what they are looking at will spot much more (a logical error that would cause an infinite loop, a point where a comment and the code disagree, an incorrectly validated input, an injection flaw, a heavy expression inside a loop that could be done first and result-cached for efficiency (your compiler cannot always identify such situations), hard-coded credentials, bad naming, ...). The best may identify some but also state why in the grand scheme of things is might not matter (efficiency in code that runs once so 10μs and 100μs is statistical noise) or where other priorities might take precedence (for example readability and therefore ease of maintenance).
Does this kind of trick question work well in practice? If they explicitly ask for syntax errors it would be a waste of time to also check the code for other errors. I can’t imagine many people opting to do that unless they know it’s a trick question.
It shouldn't be a trick question, but an open one. “What can you see wrong in this code?, there are a few things, we don't expect you to see them all”. For non-junior starters it is effectively a simulated code review — can this candidate spot problems before they get committed further into the pipeline (and hopefully avoid them in their own code).
I don’t see what information people can glean from those trick questions.
Any time I’ve interviewed people I’ve made it a point to emphasize that none of my questions are trick questions and if anything is unclear, they should ask clarifying questions. The result? Interviewees are more comfortable and are far more honest about what they know, what they don’t know, and you get to see a glimpse of what they’re really like.
"Basically, I will ask you questions, and hopefully you will give me answers.
It is fine to say 'I do not know'. It is fine to guess, but if you do, I would prefer that you tell me it is a guess.
If you want any clarification, I will try to provide it. If you don't recall the exact signature of a library function, ask me. I will note down what I said and not hold incorrect nformation I give against you.
What is super frustrating is that these same companies and people are convinced they can find game-changing productivity gains in software development, like magnitude-level improvements, yet ask questions that, what little increases we've made in the past 50+ years have made trivial.This is just a lazy question.
Your IDE can check your syntax. For people who have to switch between languages regularly, precise syntax memorization is difficult and a waste of time.
Your IDE can tell you if your syntax failed to represent any valid program. It can't tell you if your syntax represents the wrong valid program. If you can't even spot invalid syntax, you have no hope of spotting bugs, because you can't read what the code says. Which turns out, contrary to your beliefs, to be important for many purposes.
That doesn't mean you can't debug. You can step through the code step by step in the debugger, or add more and more logging around the bug, until you figure out which expression has a meaning unintended by its author. But that means that, if we're working in a language someone knows well, you're likely to spend hours debugging a problem that they can just see immediately when they're reviewing a merge request. That's an orders-of-magnitude difference in productivity when it's important for code to be correct, precisely due to what you call "precise syntax memorization".
Most of programming isn't writing code. It's reading code.
It's possible to go overboard with this. There are other skills that are more important than being able to look at some code and immediately see what it means. There are excellent programmers with severe dyslexia who will just never be able to do this. But it's foolish to think that gaining this skill is "a waste of time" for those who can.
There are languages I've used where I don't know the syntax that well. PHP, Ruby, x86 assembly, OCaml. There are languages where I know the common syntax well, but there are plenty of obscure corners of the syntax that I don't: C++, Perl, bash. But I regularly switch between C, Python, and JS, and I'm pretty confident that I know their syntax, as well as numerous other languages like Tcl, Lua, Prolog, PostScript, and arguably Scheme and Elisp, which I don't use regularly but still wouldn't have any trouble spotting syntax errors.
I'd struggle to code a five-line program that'd compile in languages I've written tens of thousands of lines of code in, in Notepad, that'd actually compile & run on the first try. I might fail that in a language I was writing last week. I mean, I might manage it, but it'd be sheer luck. Decent chance I forget, in the moment and under pressure and without examples to crib off of, IDE support, or the ability to check the manual, the correct way to do comparisons for all types, even, or basic stuff like how to print to the console or what this language's sugar for a "for-each" is, or whether it has such sugar. Reading input? The right calls for file IO? Anything more complicated than that? Oh god, there's no way.
Luckily I never fucking ever have to do that in my actual job. If I did, I might well get good at it. Since I don't, I... don't. I also haven't gotten much better at driving semi trucks or framing a wall, in my over-a-decade career writing software. Go figure.
An IDE can check your syntax, sure. It can even catch low-level bad practices ("you're making a database call in a tight loop, this is horribly inefficient"). This is, in my opinion, basic tool usage: warn of LHF early.
Last time I saw one of those test-ish pieces of code, though, an IDE+static analysis would have caught about 1/2 of the problems; the other half required actual thinking (not statistical pattern matching, aka AI): "don't trust user data, that should not go there even though the call signature matches, you're holding it backwards."
> "don't trust user data, that should not go there even though the call signature matches, you're holding it backwards."
Good type systems do this, although it's beside the point.
The point I was making is that the IDE remembers unimportant things so that my only concern is the actual thinking part. It abstracts away the minor and sometimes very important syntax differences.
While I understand where you are coming from, I disagree.
IDE tools are great performance enhancers, but they can also be crutches.
I would always expect a professional software developer to be able to parse some code on a page and point out its syntax errors (as well as suggest edits).
edit; here I am thinking about something more substancial then just a missing ';' or a lack of a closing "
Let's use (C++) something not common, but not all that crazy:
bool x = false;
x ||= something();
How many multi-lingual programmers will remember which one of the 7 languages they know does have a boolean assignment operators and which do not without looking it up? Does that make them unprofessional?
How many do remember exact operator precedence rules for all those languages, when in practice you may need just the basic ones and use () to work around the lack of exact knowledge.
Also which version? Something not working in PHP 7.3 may be ok in PHP 8, but company wants you to code in PHP 7.3, or ES5. In practice you get quickly acclimatized to any of the languages you know after working with them for a few days or a week, but good luck remembering exact rules of any of them at any given time when asked.
You're not mentioning or alluding to the one obvious syntax error. I don't know how to spoiler it so I will say there is an issue on the second line that, again repeating, I don't know how to call out.
also if you can't spot that error, you might not realize a subtle, yet important, detail about that line (if written correctly). contrary to what you might expect, it cannot short-circuit the way || does, leading to possible performance or even correctness issues.
This is very true. I hope that people are not using the short-circuit feature in a way that impacts correctness! I would have an issue with that code for trying to be too clever even if there were no bugs and it worked well.
Performance issues, on the other hand, I can see accidentally arising.
Yes, the "and" pattern is common. I've seen plenty of "ensure this exists before operating on it" chains, where it even goes if ( pointer && pointer->otherPointer && pointer->otherPointer->member == value )
I've never seen someone use an "or" pattern in a non-confusing way.
That is, I've seen "and" patterns that act as a safety/early out. I fail to see the use of an "or" pattern where you want to stop executing if the first value is true (ignoring using nots to invert the logic of an and pattern, and I would criticize that).
That boolean assignment operator was addressed. Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.
They do exist in other languages. ES has it in exactly that form. Java has it in the |= form, not to be confused with the bitwise OR of the same form.
Whether or not these short-circuit is not all that interesting for most boolean logic. (Though it can be useful to know if these are used as hacky error-handling and default-setting. It depends on how you read "something" whether or not that's going on here.)
Where and when? Because I was the only person alluding to it, and the replies to my post.
> Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.
C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?
> > That boolean assignment operator was addressed.
> Where and when? Because I was the only person alluding to it, and the replies to my post.
The words "boolean assignment operator" are in the first sentence after the code snippet in megous' post.
> C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?
As far as I can tell the |= operator in C++ is the same as in C, i.e. a bitwise OR operator. It works for booleans due to their bit pattern, but it's not the same. My C++ knowledge is extremely limited, so I looked it up and I may be misinformed though.
Java's |= is different for ints and boolean. There are no bitwise operators for booleans: bool1 | bool2 is a strict logical operation (that doesn't short-circuit). bool1 |= bool2 is a logical operation that will fail when other types are mixed in. int1 |= int2 is a bitwise operation. Java does not have a short-circuiting ||= operation (but ES does).
For the most part these differences aren't that important, but they do trip people up when switching between languages.
I'm just thrown for a loop. Why is the default to assume I'm familiar with the ||= operator in ES?
The fact that the ||= operator short circuits makes sense from an optimization point of view. I will maintain that there is no good use for the correctness (as opposed to optimization) of the code to depend on that feature.
How many of the multi-lingual programmers that know 7 languages are really good in all 7? As an interviewer and hiring manager I am more impressed of people than know 2, max 3 languages very well than 7 at an intermediate level.
I see this attitude in the corporate world and among people who are newer to programming a lot.
For skilled, experienced programmers, most mainstream languages become an implementation detail. You have to spend time learning idioms, footguns, and generally the way the language manages memory, but you absolutely can be great at 7 languages because they fundamentally do many of the same things.
I haven't hired people based on "their stack" in a long time, and it's been completely fine. Someone with skills can quickly learn your stack and be productive in it. I personally jumped on a project as a coder a few years ago having never written C# before, and I was productive in about a day. All the concepts were familiar, and the stuff I had to learn was mostly syntax.
Exactly. "If a person can drive a Honda, how well can he drive a Mazda?". Duh, just as well as Honda.
And just like the natural languages, the more you know, the easier it gets.
> All the concepts were familiar, and the stuff
> I had to learn was mostly syntax.
This reminds me how I have learnt to program. I grew up in then USSR, we had no computers at our school but we had programming lessons. So I was introduced to all the fundamental concepts: variables, assignment, loops, control structures, etc. When I went to university I finally got access to the computer (Yamaha MSX). And then it was exactly as you say: "what's MSX Basic's syntax for this particular concept?".
If a pilot is only type-rated to fly an Airbus 320 he is not allowed to even try to fly an 737 nor a different type of Airbus. This attitude of "a car is a car, what can go wrong?" is deadly in some domains.
In my (corporate) role most of the people around me have over 20 years of experience in a very specific domain (manufacturing execution systems) and it takes about 5 years to train a new person. Having someone new productive in month is a dream for us, but it never happened.
If you can be productive in about a day, please explain why a pilot gets ATPL (airline transportation pilot license) after a minimum of 1500 hours of flight. Also please tell if you would board a plane where the pilot has 100 hours - that's an awful more than a day or even a week.
I know what a language ought to be able to do and where the usual foot-guns are. I haven't even attempted to really learn a language thoroughly since my first one (Perl—and yes, that's probably part of where my brain-damage comes from). It's all the same stuff, more or less. Understand pointers and how things like how OO systems are usually implemented, how stacks work, that kind of thing, and all the languages start to blend together.
99% of the pain in a new language usually ends up being the (often god-awful) tools, platform/SDK bullshit, and learning where the clearest path is incorrect (no no no, the official docs and tutorials say to do it this way, but everyone who knows what's what actually replaces that entire part of the language/first-party libraries with this other library developed & open-sourced by some other company, since the official way is obviously so terrible, and you just have to know that, or notice by reading other people's projects—ahem, looking at you, Android). The language itself is typically nothing.
This has worked out fine for me. It does mean I've gradually grown to hate languages that lack static typing. I don't want to remember or look up things when I can make a quick note and then let the computer remember or look it up for me. I thought that was kind of our whole thing, no? Having computers do stuff for us, when they're able?
I think you overestimate the value of being super intimate with any given language. Pretty much no language in common use is so different from the others that you drastically have to change how you express any given thing you're trying to do. Knowing concepts and when and how to apply them is more important in my considered opinion.
In my opinion, if you're hiring for an expert in a specific language, you're not hiring a software engineer, you're hiring X language developer or X language software engineer. The language needs to be explicit in the position listing and perhaps even job title. That's fine if that's what you want but be specific about it so you don't waste people's time looking for a language specialist when most people anymore are generalists that have all sorts of knowledge distributions for any given set of technologies but can most likely adapt and learn to fit your distribution of technology given just a bit of time and opportunity.
Modern development requires juggling too many technologies for most people to specialize in a single language unless their career goal is to niche themselves to that language.
Someone doing webdev fullstack for more than 10-15 years will know at minimum ES + (PHP/Python/Ruby/Java/Go...) + SQL + HTML/CSS and a few utility languages.
So at least 4. If you combine webdev with something low level/embedded, you need at least one systems language, so you're at 5 languages you need to be proficient in.
Add one hobby language or a second web backend or systems language, and you're at 6 major languages.
7 is a lot. But 5 is plausible to be proficient in for someone who switches between webdev and lowlevel stuff to not burn out, or has a FOSS hobby.
I've shipped production code in 17 different programming languages. I wouldn't say I'm proficient in any one of them, they are all just tools to solve a problem and the knowledge of language specifics comes and goes. Need to hyper-optimize a DB query on an Oracle RAC cluster? PL/SQL. Need a shader? GLSL works fine. Need a webpage? HTML/CSS/JS. Need to build a 7' long flying robot fish? C. Programming languages are just tools.
In over 20 years of working in IT I never found a single webdev-type of person that can write an efficient SQL query by himself. Yes, most are able to write a query to bring the correct result, but I saw way too many cases where the perf test on a database with the expected production volume was running in completely inacceptable times and the developer had no idea how to fix that; for each version of SQL perf-tuning is very specific.
Also proficient != expert. I met enough developers that were brilliant in their work to be convinced that 5x developers are not a myth, but they are real, while rare, occurrences. For me a senior developer in X knows the ins and outs of that X to the level that his code is an order of magnitude better in term of efficiency, performance, productivity and security. A regular developer can be just proficient, but it is not what I wrote about.
It is an option, but how fast will they be very efficient? It takes years to master something and some people, not all, need to have that mastery level.
Yes, they are absolutely crutches. All great tools, libraries, and abstractions are crutches. I want programming to be easier for myself and my employees.
The only problem with a crutch is that you might end up not having it when you need it. That's not an issue in this case.
> here I am thinking about something more substancial then just a missing ';' or a lack of a closing "
The original example that I was responded to was about an interviewer who expected their code to compile. That would include incredibly pedantic things.
For example, if you're the kind of person who uses single quotes in JavaScript and then you're suddenly writing a different language where '' is different from "" and `` and $"" and whatever, you could easily make an unimportant mistake that prevents compiling.
If a company did not run automatic tests and lints on whatever they felt was important to have when merging to production, to the fullest extent possible, I would stop everything and write those. This leaves reviewers free to focus on the intangibles: architecture, expressiveness, logic and data flow, and so on.
In my experience, Pull Requests aren't about catching syntax errors... the build will fail if there's errors like that. Rather, a Pull Request, and the code review involved, is about the underlying logic of the code; both with what it's doing it and how it's doing it.
I don't buy that argument, as a programmer you have to write out code following a precise syntax all the time. Programming would be insanely tedious without knowing correct syntax.
Having said that, if someone came up with an interview test which used especially esoteric parts of the language in unconventional ways and then asked to spot the errors, the could be a dubious question.
> as a programmer you have to write out code following a precise syntax all the time
When did I claim that the IDE absolves you of needing to know the syntax?
It doesn't. But between autocomplete, hinting, linting, and any other static analysis, it makes it close to painless to switch between languages without making horrifying mistakes. The top-tier JetBrains IDEs (IntelliJ and Rider come to mind) will even tell you ways to make your code more efficient or modern, like changing a bunch of if/else to pattern matching.
Why should I have to remember the full truthiness table of JavaScript? Why should I have to remember what all the different string delimiters do in every language? It's not important. My IDE can (and does) know that I'm trying to do some kind of string interpolation and will just fix it for me.
I think some of this is filtering out bullshitters. In a previous job I used to interview a lot of unfiltered candidates. What we did was sit them down at a Linux command line and ask them to show us the files in the directory, open a file for editing and that kind of thing. A surprising number of people who claimed years of Linux experience had clearly never used the command line at all.
I've tried questions like this (super basic but can quickly filter out people who know nothing), but sometimes the candidate seems insulted! I try to quickly move on to a harder question.
If you start with "I'm sorry if you find this question offensie, but recently we had a wave of candidates who had problems with basic things so we need to start from the beginning" and the candidate still feels offended, well, they're being offended too easily which might cause problems in the future.
I think people can still find it off-putting that after all the evidence they provided you to get to that point, you're challenging them to prove they aren't complete frauds. Like you could has spent 30 seconds googling them and verify they are legit, but it seems you didn't even bother to read their resume. Not saying it's the case, but rather that not everyone is aware of how good the frauds can be at presenting themselves and bullshitting through interviews.
I don't think the problem is offending the ones who know how to do things. It's making them think they're applying for a worthwhile job.
I remember thinking what you're writing about there, that there's a lot of people to be filtered out, and that good candidates wouldn't be offended.
So we had this simple two-part quiz question for people, starting with "what is the expectation of a dice roll?". Amazingly a lot of people can't figure this out.
But also a lot of people know the answer immediately and will wonder WTF you are asking such a simple question for. I remember this one lady who interviewed with my firm, the look on her face when she realized we weren't asking anything complicated. You could just tell she thought we were a bunch of amateurs, and she'd better be on her way to see some other proper hedge funds.
I could see it if you're resume talks about a whole bunch of intense recent development in the exact same language they want to test, but only then.
In contrast, I've been stuck in a giant multi-language integration-fest, and... well, there are definitely languages on my resume that I would not be comfortable being pop-quizzed on, simply because I've been using others for the past two years.
I've been doing C++ full time since 1996, and yet I frequently have intellisense warning me about forgetting something silly - like a missing capture in a lambda, or even forgotten semi-colons. That's because I'm not an f'ing compiler.
_Can_ I make sure the code is 100% correct before even compiling? Sure, but I'll spend an hour checking every detail, while intellisense does it while I type.
I mean, yes. In a whole program, typos or mistakes happen. No need to try to prevent those. So do spelling or grammar errors when writing in English. We expect a professional writer to have a human editor to catch those and not be perfect. But asking an applicant for a writing job to find the spelling/grammar errors in a paragraph seems reasonable to me.
The simple fact that you think so tells me that you aren't a programmer, and that you should stay far away from interviewing or managing programmers. About the only thing the two situations have in common is that both are based around a text-based medium; for the rest there is just no comparison between writing computer code, and writing text for humans. Have you ever noticed how very few people can actually write both good computer code, and good documentation for the users of that code? That's because they are completely different disciplines, requiring a completely different mindset.
Let's turn this around: if I were interviewed by someone who flagged down my code for missing a #include or lambda capture (both very easy mistakes to make), I'd know that the people I'm interviewing with are idiots with no understanding of the thing they claim to be testing me on. Would I want to work there? Nope.
You seem very confused. At first I was worried you misunderstood my text: maybe you have trouble with natural language but not programming (or maybe English but not code). That would certainly explain your claim that they are disjoint skillsets. But as you went on, you committed a logic error, so now I'm just thrown.
There is a difference between "find the errors in this provided code" and "write code on a whiteboard with no errors". At no point was I talking about code you wrote.
Also, it's an aside, but I find people who can program well write excellent documentation for the users, if what they are writing is an API. Of course, they are not the best at explaining the steps in a GUI, but that probably has less to do with communication skills in general and more to do with the difficulty understanding how they perceive the problem.
But yeah, I think I've seen questions like that for an intern positions. It's basically a "have you ever seen this language?" to weed out people quickly.
> It's basically a "have you ever seen this language?" to weed out people quickly.
It's not that. People who constantly use multiple languages in an IDE will not be able to point out most syntax errors outside the IDE. So it's not a "have you ever seen this language" filter.
> I'm curious what position would this question make sense?
I was once asked a similar but better posed question: I was given some code and asked what I'd point out if asked to do a code review on it.
And the code had loads of things wrong with it, from bad variable names and incorrect comments, through unit tests that didn't have any assertions and loops that weren't actually loops, all the way to choosing a non-secure random number generator in an application that needed a secure one*
In other words, it was a test of my ability to code review, with some glaring issues to give me some easy marks and set me at ease, and some subtle issues where talented people could really set themselves apart. It was fair and relevant to the job because I was presenting myself as a senior programmer with lots of experience doing code reviews and coaching junior developers.
It's possible trinovantes's interviewer intended to give the same sort of test - but either didn't explain the question clearly enough, or trinovantes misheard or misremembered.
Citrix gave me a page of code which had a lot of tricky obfuscated syntax problems. Code that looked live but was actually commented out, nested comments that were not terminated properly, code formatted in a very deceptive way, strings that were not quoted correctly so they would not end where expected on the page. It was all very contrived stuff that was deliberately deceptive, not like real broken code, and the errors would have shown up with syntax highlighting.
I caught most but not all of the tricks.
This is also the only interview I have ever had where a panel of engineers stood behind a desk and all barked questions at me. I did not get the job.
At a different interview, this one with Microsoft, the lead engineer showed me a page of actual code from their app and asked me what I thought. Luckily the bug instantly leaped off the page to me, although many people would not see it. That was a good way of proving that I have a useful ability, and a better use of time than whiteboard coding or quizzes. I got the job and they were glad they hired me.
I tend to believe that "walk me through a peer review of this code" is a great interview question. It speaks to the user's familiarity with the language, with problem solving in general, and also people skills. Sure, it's not the end all/be all, but someone needs to be pretty amazing to want to work with them if they are incapable of doing a peer review.
This is awesome and I think every company should do something like this. You get to ballpark technical ability really well while getting some very relevant behavioral information (i.e. what will it actually be like to work with this person, without lame ‘culture fit’ questions). It can be hard to test competence in a way that allows all kinds of devs to shine; code reviews are pretty unavoidable on the job though so it’s a good fit.
Coding is a mostly solitary activity that you probably don’t want candidates spending more than ~60 minutes on, ideally on something that resembles the actual day-to-day instead of sucking all the Leetcode possible out of them. Even just quickly pair programming on something nets you more data points in the same time.
Depends... imagine getting four pages of C# code and having to play Where's Wally but you're not even sure what Wally looks like. Surely it'd be better to just write FizzBuzz.
It's literally asking someone to write perfect code in a time limited situation, under pressure, how can someone with any kind of coding experience ask someone else to do in an interview?
Not one person ever code reviews code that was not already compiled. Requiring you know the syntax of a programming language (in my case, Swift, changes syntax in every release) outside of a compiler is pointless. I remember in the early days of J2EE people asking you for the home interface of an EJB stateful session bean. Like who the hell cares about memorization in the era of Google, and that was 20 years ago when Google did no evil. This isn't first year computer programming 101, you are paid to make things that work, not regurgitate syntax.
We may have had the same interviewer- tbh I thought this was pretty reasonable and more of a warm up really. I think this also lead to a discussion on some questionable logic and how you could improve the code.
I had 10+ years experience in C++, I thought it was completely reasonable. Especially compared to their later questions around something along the lines of finding a shortest path in a tree. I interviewed there a bit before their process was so well known to be game-able, I went in with zero study time on obscure algorithms outside knowing the O(N) of the most widely used, and certainly did not practice actually writing or interacting with trees and such.
There was a function with a syntax error, that also returned a pointer to stack memory, and made some logic error where it assumed a class with no vtable would be polymorphic.
I have done this. Is it really such an insane idea? Makes for a nice break from "what does this code do"? You need some technical "anchor" to make for more concrete discussion points.
Would you accept "my build toolchain and linter will catch all of these syntax and stylistic errors." as an answer? 'Cause that's what all your devs are going to do IRL.
Not really since that doesn't leave much room for discussion, but that is my problem not theirs. The point is to have something to discuss, not to listen for a singular answer. Now we can discuss hypothetical situations and philosophy but I'd much rather have a concrete piece of code to go through.
Seeking out problems and errors can be a good conversation piece. Hopefully you get to hear some anecdotes, prod the taste in style and how well that that taste might play with others. The interview situation isn't easy for anyone, and anything that can if something is even remotely qualified helps.
I worked at a place that did something similar. VBA code, printed out in a proportional font, no word wrap so long lines spilled over...
"What does this code do?"
That was a pretty easy one to figure out, it pulled coordinates from a database table, and then it stepped along all the lines trying to find the longest one (they were a metal shop).
"Do you see any evidence that this code has been optimized?"
wait until you see this asshole move being pulled to find a bug in production code under time pressure their team has failed in the real environment by being given out some thousand-lines long printed code from the development branch.
I've been working in C for most of my career and I've never heard of such questions. They're not in any textbook I'm familiar with. In fact they're incredibly pointless and irrelevant.
What about it is disrespectful? It seems to me that it’s testing for something relevant and I don’t see it as otherwise bad (abusive, pure trivia, easily Google-able, etc)
It is akin to giving a spelling quiz to an author. There is a level of decorum required when dealing with professionals. A junior verbally pointing out a syntax mistake reveals a naiveté about the competency itself and "the mission" of the field.
In this interview, I would have liked to receive two code examples (that might contain errors) and discuss benefits according various objectives.
If the interviewer makes it clear that pointing out syntax mistake is not rude, I could mention them in passing. This demonstrates not only attention to details but also decorum.
I once halted an interview because of this kind of thing. Told them their interview process suggested they were looking for someone substantially less experienced. When they then insisted everyone had to go through this, I told them that was a warning sign to me that their hiring process was a box ticking exercise rather than addressing the actual needs of the positions they were hiring for and that I was no longer interested.
Recruiters need to understand that these kinds of processes will often filter out the wrong people, such as those skilled enough to be able to pick and choose.
A lot of interviewers have complete leverage, so they don't get any sort of feedback or real check on their ability or processes. It's only when a candidate isn't desperate for the position, is competent, recognizes red flags, and gives them the feedback that they'd ever be aware of. You don't have to be upset to realize there's a mismatch and withdraw your candidacy.
Candidates often have to call out nonsense otherwise it may never be called out. Processes need feedback to adjust and adapt, otherwise they'll typically continue with momentum alone.
With that said you can give feedback in a polite and professional way, you don't have to be arrogant about it. "Based on the questions, it appears you're searching for these specific abilities which are often attributed to a junior role, so I believe I may be a mismatch for this specific role. I'm going to politely withdraw my continued involvement in this process. I appreciate your time and interest and hope you will contact me if a more senior role is available." Or something to that effect. You don't have to be arrogant to give feedback.
If you were like "what, this is ridiculous, what am I am an intern? Good luck filling this trash position!" And then walk out then sure, that person clearly had some anger management issues.
I once interviewed for a director role and the first round went something likes this:
Interviewer: How would you reverse a string?
Me: boggle Any language I want to use?
Interviewer: Yes.
Me: Okay, Ruby. "somestring".reverse!
Interviewer: boggle
Me: I don't think we're aligned on what this role is. says thank you and leaves
Interviewers need to understand what they are interviewing for.
I mean, it all comes down to how that situation is handled.
If OP was a dick about it, then yeah, it serves to filter out an arrogant assbag.
But if OP simply explained that the interview led them to believe the position was a more junior/entry level than they were expecting, that seems fine. Further, to even explain that the interview process seems to just be a checkbox process seems fine; if you work in a critical thinking/creative role, checkbox culture is an absolute brain drain.
Getting that out in the open, in honest and respectful terms, is a fine thing to do. Why wouldn't it be?
Further, any hiring institution that feels the need to build in 'tricks' to filter people out of the interview process is toxic. Even if the people they're filtering are arrogant assbags.
If a prospective employer has a hiring process that is wasteful and pointlessly bureaucratic and tests people for things entirely irrelevant to a role, that tells me they're likely to be an awful place to work and/or don't understand what they're hiring for (which is likely to make them an awful place to work too).
If you I consider that arrogance, then so be it. I consider it not taking jobs that'd make me miserable, because I don't need to.
A prospective employer doesn't have a right to have me bend over for whatever process they'd like.
TBH, aeons ago, we had this as a high-pass filter (doesn't notice a glaring SQL injection hole, no problem with eval() on user input? Nope.) and a conversation starter (-why are you constructing a database handle right in the middle of business logic? -indeed; how would you do this?)
It very much depends on the code - but I was genuinely surprised how many applicants, claiming to be fluent and applying for a senior developer position, had problems just grokking what the code did (a while loop reading from database).
Definitely not - if an author has written a book in German (even if it's not their native language) then giving them a German test is definitely insulting, the same applies for a newscaster in Italian if they have done reporting in Italian previously.
What you say applies if you're hiring people for their first position at that task (e.g. the author writing their first book in German or a newscaster who has never done reporting in Italian professionally). If you're hiring people at some hypothetical "level 10" then your interview needs to discriminate between "level 9 or less" people and "level 10 or more" people, but asking them to assert that they meet "level 1" implies that they might not, and that implication is literally insulting.
In the interview case, you often have someone who claims they wrote a book in German (but you can’t see the book) or to be a professional Italian newscaster (but you can’t see any of their reporting).
Switching part of the interview to be in Italian or German would not be seen as disrespectful, right?
It’s interesting that some find the coding equivalent insulting rather than merely a bar pointlessly laid on the ground to be stepped over.
The difference IMHO is in the expectations of what's required from the applicant. Switching part of the interview to be in Italian or German would not be seen as disrespectful as it does not add much (if anything) to the length of the interview, but asking them to fill a 30-minute quiz on basic Italian/German grammar would be disrespectful.
A bar pointlessly laid on the ground to be stepped over is reasonable iff it's you can just quickly to step over it - but if they ask the candidate to waste half an hour to prove their capacity for stepping over bars laying on the ground, that is disrespectful of their time.
For programming, a trivial short task (e.g. fizzbuzz) is appropriate but a trivial long task is appropriate only for junior positions but disrespectful for senior ones - ask something that tests whether they're capable of something serious, because passing the trivial task can't be sufficient anyway.
I think the issue is what happens if an author ghostwrote a book in German? I guess that's the book version of copying code off Stack Overflow and claiming it's yours? People trying to game the system make it crappier for everyone else.
Then do it in a different way. Phrase it as a toy pull request that the reviewer has to review, and let that contain everything from minor syntax errors to logic errors to missing core stuff (like missing test cases).
That's why you are reviewing a pull request in your IDE.
And you are having a CI build and unit tests in place. If it doesn't compile or a lot of tests are failing, a sane person won't even bother to review a pull request.
Serious question, as I've never done a PR in my IDE; hadn't even thought to.
If you check out the branch in your IDE, is there a way to have it highlight the changes in the branch you're reviewing? Or do you need to reference the output from `git diff` or the github PR view?
3. Open the branches listing panel in the sidebar.
4. Mouseover the target branch of the PR
5. There's an icon that looks like two nodes with arrows pointing between them. Mouseover text "Compare with ...". Click it.
6. The search and compare panel in the sidebar has a listing of files changed, you can click a file to get a diff view.
There are gitlab [1] and github [2] extensions which streamline this workflow if your code is hosted on one of those services, and let you leave comments in editor which show up in the web UI.
IntelliJ has support for display a diff for a branch or github PR built in [3] but I hate their diff modal view.
