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.
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.
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.
This is, I think, the closest thing there is to a universal experience in this field.
Followed closely by "how did I miss that single-character error?"
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.
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.
Any questions before we start?"
But 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.
* A bug right out of puzzle 94 in 'Java Puzzlers'
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.
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.
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 "
bool x = false;
x ||= something();
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.
And yes, I work in multiple languages.
Performance issues, on the other hand, I can see accidentally arising.
Where you want to make sure a pointer you've been given isn't null before you try to dereference it. Without short-circuit, this becomes a segfault.
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).
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?
https://www.w3schools.com/cpp/trycpp.asp?filename=demo_oper_...
||= will not assign anything unless the LHS variable is falsy. It will not even evaluate the right side unless LHS is falsy.
|= will work the same in C++ and ES mostly (depending on types)
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.
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.
This is true.
> It works for booleans due to their bit pattern, but it's not the same.
This makes less sense. A bool in c++ is just an integer value with few inputs. It is, as far as I can tell, the exact same.
> Java's |= is different for ints and boolean.
Java has bool and int as different types. There were versions of C++ compilers that just straight out had bool as a typedef of int.
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.
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.
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.
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.
> All the concepts were familiar, and the stuff
> I had to learn was mostly syntax.
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.
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?
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.
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."
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.
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.
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.
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.
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.
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.
_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.
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.
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.
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.
But I think the point in this thread is the Google question about Linux inodes was actually part of a pre-screen interview done by an outside agency.
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 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 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.
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.
"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?"
That was the dumb question.
The questions go like,
What is the output of the expression below?
int i = 10;
****++&&*+p;
Not sure how this measures language proficiency.
> int i = 10;
> **++&&*+p;
> Followed by a myriad of options. Including things like Syntax error.
I consider myself fluent in C and to a lesser extent C++ -- that's a Syntax Error in C, at least.
This isn't a particularly difficult one to spot, but I can understand how it would be if you weren't very familiar the language.
Eventually your eyes will give being a lexical analyser.
(/me runs away)
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.
That’s true whether I’m an author writing in German, a newscaster reporting in Italian, or a programmer coding in C++.
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.
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.
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.
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.
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.
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.
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.
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.
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).
If there is an error, I can quickly figure out what that is and what I should do to fix it. I would know why the error occurred.
Beyond that deliberate interview practice is the only way to get a lot of interview questions right.
(Admittedly if the PR doesn't build why are you reviewing it but whatever)
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.
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?
1. Open Source control window
2. Checkout the PR branch
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.
[1]: https://marketplace.visualstudio.com/items?itemName=GitLab.g...
[2]: https://marketplace.visualstudio.com/items?itemName=GitHub.v...
[3]: https://www.jetbrains.com/help/idea/contribute-to-projects.h...