I write a lot of PHP for part of my job.
The beauty of PHP is that for any given task, there are always multiple ways to do it, all of which are wrong.
Any sufficiently skilled developer has a bunch of things they hate about the language they use the most, and are happy to tell you about it.
This is a characteristic I unironically keep an eye out for when hiring.
"Introductions and a bit of smalltalk" - I would shit myself if an interviewer started asking about smalltalk... /s
I was thinking the same thing. I mean, I just did a coding test for a potential job, and I know I did at least as good as, and likely better than this.
edit: just to prove to myself, I went ahead and wrote the program without looking things up. I'm self-taught so I feel pretty proud. It took about 25 mins, and it works!
Yeah, I use Python as a hobby and I my biggest project is a discord bot that does a bunch of things. Just for kicks I tried answering the questions without google and made working solutions. I don’t know if they are optimal but they work and I didn’t have to look things up.
I used to work at a company that used XSLT. They know that it's an obscure language that probably none of the potential candidates have ever worked with. But it's easy enough to learn the basics in an hour or two.
So the entry test was to strip some tags from an XML file. You had a day or two (maybe more) to do it. My solution wasn't ideal, I didn't use several of the shortcuts available in the language. But at least it did what it was supposed to.
A few weeks after I had started working there my boss came up to me, visibly frustrated and asked me whether the test was too hard. Thinking back on my problems I replied that maybe having the desired output ready so that you could test your own solution against it might be nice. But my boss's problem was that none of the last 5 candidates could even send in a solution that would run.
You had so much time, and running an XSLT script is really easy and takes no time at all. And for some inane reason these people couldn't even manage to test their code and still decided to send it in.
And I thought I was an idiot when I didn't know if it was spelled grey or gray in CSS during the in-person interview.
It is very good test for the ability to research, I think. The amount of people who painstakingly went through some video tutorial on PHP and are now developers is insane. I'm sure there's place in the market for them (writing Wordpress themes/plugins, for example), but it's hard to find a programmer with ability to think these days. Not because people are more stupid, but because every other person is a programmer now.
You had a day or two [...] none of the last 5 candidates could even send in a solution that would run.
As harsh as this sounds, this test was doing its job. Assuming you're not hiring junior candidates, that is.
One day is enough to research XSLT enough to get the gist, and two is enough for a polished solution. And since we're just stripping tags, we're really just selecting for all the inner text, which is weird but not hard to do with the right selector expression. The task also selects for people that understand XML processing as programmatically manipulating a DOM, which is crucial to wrapping your head around more advanced tasks.
grey and gray are both in CSS. If you've worked with CSS long enough there's a chance you've seen both. :)
I would prefer your kind of test a hundred times over the one on top here.
That said, why would they expect you to know the css color values by heart? I see no usecase for that.
It just came up in a discussion. The test was to spot mistakes in some HTML code. I marked the "gray". The guy I did it with said that that's not a mistake. At least he thinks it's not. We were musing about that for a minute and later found out that I was wrong. Nothing major. I just felt stupid about it.
I felt especially stupid because he seemed to be rather important. While everyone's e-mail address was firstname.lastname@company.tld his was joe@company.tld.
But he was just a nice guy and apparently I did well and got my rather high salary approved.
I wanted to answer "grey", full of confidence. Then I decided to look it up to be sure and found out that it's "gray".
The test was to spot mistakes in a simple html file. So I couldn't substitute anything. And my favourite gray color is #666.
GrAy for Americans and grEy for Europeans. I used to basically flip a coin but I read that mnemonic once and have never forgotten since.
XSL is like that, I guess.
Some shit still use XSL at my workplace, and once I got a task with them, so... I hit up some online resources and fixed the issue.
I kid you not, from there on, I was (and still am) the XSL guy and gave me more XSL designing and work.
I mean, it's not hard, a tiny little bit complex, but I really just spent half hour researching and some googling during work to complete these tasks, it in its own way makes sense.
But they just... aren't willing to maintain those XSLs, because they indeed looks really ugly and scary in a way.
You can tell this is fake because the code interview actually tests basic knowledge instead of giving you 13 minutes to create a templated polymorphic class which accepts arbitrary flatbuffer arguments and implements factory pattern constructors written in Haskell, with the end goal of recursively sorting nanoparticles by bond strength. Intro level position, $8/hr, must supply your own MacBook.
Oh geez, I'm one of those people who can't code on paper. I was applying for something ages ago and I went in for a programming test and they handed me a paper test and my mind completely shut down. Put me in front a computer and I have no issues at all... It was embarrassing.
I would just write down the steps I would take, just some psudocode. It doesn't have to work, it just has to make sense in the style of the language you're talking about.
import random library
import any GUI/display libraries required for the outcome desired
build array of integers [1..52] (or 0..51 if you're being fancy)
for loop 1..1000
select random number A 1..52 (or 0..51 if you used that above)
select random number B 1..52 (or 0..51 if you used that above)
swap elements in the array A and B
pop first two elements from array
decode at display time what the two numbers represent in terms of playing cards
If the test requires more than that, then they're crazy. The syntax doesn't matter, just that you can logic yourself through the problem.
You can use the IDE, google, or whatever to fill in the specifics. If you wanted me to do that in literally any programming language, once the psudocode is done, you just spend an hour or so looking up the details.
If you wanted me to do that in literally any programming language, once the psudocode is done, you just spend an hour or so looking up the details.
In some cases, you can even use an AI chatbot as a "pseudocode compiler". Just tell it to translate your pseudocode to an actual language. I've done it for shell scripts a couple of times, works surprisingly well. Not that I would do this at a job interview haha.
Even the odd numbers stuff? I think interviewers account for nerves and being outside an IDE. You might draw a blank but would you be would be randomly adding things like these did?
No this was just crazy, I have worked with people like that though where stackoverflow was permanently on a second monitor, and I wondered how they made it through the interview process
for some reason I still needed to know programming on paper so much so that at the university, in class prgramming we had to do the exam on paper. every time. no matter if it was Java or C++...
I strangely enjoyed it, but it still was kinda weird.
In university I written on papers programs in pure C. They did compile. They even worked. But they were school olympiad-level, so it doesn't count I guess.
Oh, and I was supposed to write in Python.
I lucked out, my university was digital before that was a thing. So the amount of written exams was minor enough that I pulled through ok
Yeah, I really liked my prof for some of the programming courses, but also damn him for making us write code on paper in the exams
Want to print out all odd numbers from 1 to 100? Easy:
for(_=[];_<+!![]+""+[]*[]+[]*[];_++)(_%+(!![]+!![])?console.log(_):[]);
Actually, I prefer this one:
for(_=[];_<+!![]+""+[]*[]+[]*[];_++%+(!![]+!![])?[]:console.log(_));
Or this one without the "undefined" when run in a browser console:
for(_=[];_<+!![]+""+[]*[]+[]*[]-!![]-!![];_++%+(!![]+!![])?[]:console.log(_));_+!![]
_ is a variable name, [] becomes 0 when converted to an integer, !![] becomes 1. The + "" + means that the integers 1, 0, 0 get converted to a string - "100", which gets converted back to an integer because it's in the for loop. And there's various other horrible conversions going on to make it all work.
And that's why we're moving away from coding games where I work. Bad people try to cheat, good people can panic and shit the bed.
When I do interviews, I'm more interested in the candidate's relevant experience, what kind of issues they faced, how they were solved, if they think they could have done things differently, and how they think. Code itself is irrelevant unless I can review a sprint's worth of PRs.
When I ask more technical questions, I never ask for code but for an explanation on how they would tackle the problem. For example, I often ask about finding a simple solution to get all data relevant to a certain date in two, simple, historized tables. If you know window functions, it's trivial. If you don't, your solution will be slow and dirty and painful. But as most devs don't know about window functions anyway, it lets me see how they approach the issue and if they understand what parts should have a trivial solution to make it simple.
This is why I prefer live interviews. I tell them they can use whatever tools they want, search for anything they want, there are no restrictions. All I ask is that they share their entire screen (if not in person) and try to "think out loud" as much as possible. I then time-box each step (usually 15m ea in a 1-hour interview).
I am most interested in HOW they solve the challenges I set out for them. Whether they complete it or not is usually irrelevant.
Edit: Lately, though - I warn against AI. I don't ban it, but every person that has tried to use AI in an interview has gone down in flames. AI simply cannot be trusted... and if you haven't learned that lesson, and you can't even tell when it's giving you bad information... yikes.
It's not so bad once you've got your teeth into the problem
assuming you can code, that is
I use ChatGPT sometimes to give me a pointer in what directions I could go/research more for a given problem. But if I ever take the code provided by it, I need to review it line by line and half the time it doesn't even compile anyway. At this point it's just a helper to suggest to me what to google for and then I do the rest😅
I approach interviews for penetration testing positions in the same way, just with hacking challenges!
I hope these aren't real. I, and most people here, could probably write these codes top to bottom on paper without an eraser or strikethrough parts because we have it fully solved before the interviewer finished the sentence.
Sure, programming is hard if you've never worked with programming language features before... Modulus isn't some obscure esoteric operator, it's literally CS 101
I fell backwards into programming and did it for years before ever needing or encountering a mod operator. It never really came up in statistical programming (SAS) and since I wasn't a CS major I don't think I even learned about it until taking online programming classes for fun. But I know I was a pretty damn good SAS programmer. I never had any issues solving any problems in my field programmatically, but I took a few leet code tests and was completely puzzled before taking said CS classes. The algorithms and common problems just never remotely came up. I never found fizzbuzz particularly relevant in statistics and data CRUD.
Now maybe since SAS is procedural and not OO you'd say it doesn't have typical "programming language features", but I could easily see that experience being common in all kinda of business side programming like R, VBA, maybe JavaScript or Python, etc.
...but anyway obviously I'm not saying its not a good thing for a dev shop to interview on, and if they want someone classically trained then it's probably a perfect question. My quibble is just that you might need to widen your definition of who programs.
Is it? I would expect someone to come up with either toggling a variable back and forth for even/odd, or counting by 2s, heck, treat it as a floating point, divide by two, and search the string representation for a period or something!
Shouldn't people familiar with integer arithmetic should be able to struggle to something like x == 2 * (x/2) to test if it is odd or even? Or just bitwise x & 1?
This makes me feel bad for the candidates but gave me the confidence boost I need right now
I once knew a "developer" with 20 years of "experience" who could not write a foreach loop by hand
Some people are really good at bullshitting their way through life
I jump between languages so much I can never remember the structure.
for item in items? Or item of items or items as item?
Best to just have the IDE auto complete it.
Same here. I'm blue collar so I only do it at work if someone fucks up and gives me access to an interpreter. Or I suck it up and use powershell or excel then drink vodka and cut myself when I get home.
Knowing about and having met multiple such "senior Devs" has made me feel so much better about my work and my own set of skills, not gonna lie.
The previous candidate to me at a job a few years ago left the room in tears after not being able to write Fizzbuzz. On a laptop with Visual Studio installed, on their own in a an empty room with nobody looking over their shoulders. The same company said they'd had so many candidate, including university graduates, who simply couldn't code, that they were almost giving up on it.
Same, fizzbuzz was one of our tests. Nearly everyone messed it up. The telling part was how. We had a guy with 20 years of experience who demanded ample compensation write code that not only didn't compile, but it made little sense. A lot of people were pretty good bullshitters - then after the test they went "Yeah, well... That went bad huh?". We had a different, more difficult test that people could choose. We had one guy who did somewhat poorly on that... But asked to take the assignment home for his own sake. He was a very god hire. Not because he worked overtime or anything but because he cared.
Suddenly I feel like a fucking accomplished programmer, despite only doing some questionable stuff on Godot lately, but never messing up my loops... Not too badly anymore, anyway.
A fizzbuzz type of question I know I would mess up on the modulo operator. I know the logic is if the division of the current_number by 3 has a remainder of zero, write fizz, but I always look up the operator
Yeah it always feels like "negative logic" to me. If it's not this and not that then don't do the other... Does my head in. Next time I'm going to use a lookup table "x..f.bf..fb.f.." then mod15 the index. f=Fizz, b=Buzz, x=both. Nice thing about this is that it's easier to change with the requirements. Want to shift the second fizz right one? No problem "x..f.b.f.fb.f..". Good luck doing that with the standard approach. Add Gronk which collides with Fizz, Buzz or both at various times? Also no problem - just extend and modify the LUT accordingly and change the mod.
I can already hear people asking why x is at the start. Arrays are indexed from 0. FizzBuzz starts at 1. 15 mod 15 is zero. Loop N from 1-100, switch on lookup[N%15], case 'f' print Fizz, case 'g' print Gronk, case 'p' print FizzGronk and so on. The only "nice" original feature you lose is when both %3 and %5 fire at the same time and it prints FizzBuzz without any extra code.
Still in university, never did an interview. Is that seriously the avarage difficulty of interview questions?
This is on the easier end of the scale to be sure, but as someone who's interviewed candidates with similar questions, it eliminates a surprising number of people...
My theory is that modern coding bootcamps stuff their students full of buzzwords instead of letting them learn the basics
Which shouldn't be surprising. The company I was interviewing at only feed me the top ~1% of CVs to interview... Of course half of them were stuffed with bullshit
Yeah, this is the problem. Someone who has legitimately built a basic application or website from scratch may know everything you need, but HR will filter it out.
They don't really understand what they are looking for, so someone who says they are an AI Researcher with 8 years of experience in the language "Zendaya" and work experience at five moon rocket startups will be at the top of the pile.
Companies need to beef up their training programs so they can literally take in whoever and teach them what they need to know. Forget trying to get the top people. Just take the first 20 who can make it through an interview without drooling on the floor. You will probably get at least 9 ok developers and 1 good one.
When I interview people, I don't care how they get an answer, I want to see that they can get to the answer, ideally the correct one, but it doesn't matter if it's wrong. I want them to show me their problem solving skills and that they understand their own solution.
If you can read existing code and understand complexities you are already better than 80% of these hires.
This is our approach when we ask what is system, out, and println in System.out.println(). Just talk it out. Look at capitalization.
That's like stage one where you filter out the obviously incompetent ones.
You wouldn't believe how many candidates with years of experience can't figure out those simple problems. Or even the super well known fizzbuzz.
It's insane, people will claim like 2-3 years of experience with Ansible, they can't even get a file copied. Couple years of Python, they don't understand async, generators and other pretty basic features.
People have always been lying a bit about their experience but it's getting way, way out of control.
Knowing specific features of a language is one thing, but not being able to even pseudocode a FizzBuzz shows they lack the basic logical problem solving ability that programmers need.
We eliminate half our candidates when they can't even answer what is static in Java. Or what is object oriented programming. Ours is less coding tests and more explaining Java concepts.
Just to be sure (I haven't done a lot of java and don't exactly like it):
static in OOP means that we don't need an Object of a class to call a static Method or access a static value, right?
Correct. It's mainly used for quick helper methods where you don't need an object context like the Math class. It's also used for class variables like out stream in the System class.
So. Many. People think it means it's a constant variable.
To be fair, the static keyword is overused in various languages and has various other purposes.
IIRC: C has both static functions and variables. Static variables keep their value for the next time a function is called, no idea what static meant for function declaration.
Rust has static variables, which are similar to constants but can be abused as global variables.
That's true, but these are also the same people who say they are a 9/10 in Java at career fairs. I've been working in Java for 10+ years and I'd still only consider myself an 8/10 maybe.
I always feel bad when I try out a new coding problem for interviews because I feel I'm going to offend candidates with such an easy problem (I interview mostly for senior positions). And I'm always shocked by how few are able to solve them. The current problem I use requires splitting a text into words as a first step. I show them the text, it's the entire text of a book, not just some simple sentence. I don't think I've had a single candidate do that correctly yet (most just split by a single space character even though they've seen it's a whole book with newlines, punctuation, quotes, parentheses, etc).
That is totally a non-trivial problem, which requires a lot more conception before it can be solved. Even for English, this is not well defined: Does "don't" consist of one or two words? Should "www.google.com" be split into three parts? Etc.
And don't let me start with other languages: In French, "qu'est-ce que" is one word (what). In the German sentence "Ruf mich an.", the "Ruf an" is one word (call) while mich is another word (me). In Chinese, you usually don't even have spaces between words.
If I got that feature request in a ticket, I'd send it back to conception. If you asked me this question in an interview, I'd ask if you wanted a programmer, a requirements analysis, or a linguist and why you invite people for a job interview if you don't even know what role you are hiring for.
In the German sentence “Ruf mich an.”, the “Ruf an” is one word (call) while mich is another word (me).
They're both parts of the verb anrufen but I've never heard someone say they're still a single word when there's a space (or more) inbetween
There is no single definition, for what a word is, which is exactly my point. Some linguists even argue that "word" is inherently undefinable and refuse to use it as a category.
One common (but still ambiguous) definition is though, that a word is the smallest unit in a language that can stand on its own and conveys a meaning. By that definition, "Ruf .. an" is one word, as "an" is not a word by itself. It might not be too obvious, as "an" can also be a word by itself , just not in this context. Another example, where it's more obvious, is "innehalten". "Inne" is not a word, it has no meaning by itself, it cannot be used on its own, so in the sentence "halte kurz inne", "halte inne" is one word. Another example would be "Stelle etwas dar", where "dar" is obviously not a word by itself.
Fun fact: Verb literally means word in Latin, so saying they are the part of the same verb, but not the same word is kind of an oximoron.
That is totally a non-trivial problem, which requires a lot more conception before it can be solved.
Most candidates don't realize that. And when I say they split by single space I mean split(' '). Not even split(/\s+/).
Does "don't" consist of one or two words? Should "www.google.com" be split into three parts? Etc.
Yes, asking those questions is definitely what you should be doing when tackling a problem like this.
If I got that feature request in a ticket, I'd send it back to conception.
If I got it, I'd work together with the product team to figure out what we want and what's best for the users.
If you asked me this question in an interview, I'd ask if you wanted a programmer, a requirements analysis, or a linguist and why you invite people for a job interview if you don't even know what role you are hiring for.
That would be useful too. Personality, attitude, and ability to work with others in a team are also factors we look at, so your answer would tell me to look elsewhere.
But to answer that question, I'm definitely not looking for someone who just executes on very clear requirements, that's a junior dev. It's what you do when faced with ambiguity that matters. I don't need the human chatGPT.
Also, I'm not looking for someone perfectly solving that problem, because it doesn't even have a single clear solution. It's the process of arriving to a solution that matters. What questions do you ask? Which edge cases did you consider and which ones did you miss? How do you iterate on your solution and debug issues you run into on the way? And so on
I am curious how you'd deal with the ambiguity of contractions vs. ending single quotes. I guess that character between letters can be assumed to be part of the word, but not if it's between a letter and a space, for example. If you ignore contractions, hyphenated words, and accented characters, you could just match on /[a-zA-Z]+/.
I am curious how you'd deal with the ambiguity of contractions vs. ending single quotes
That's the thing, nobody even asks this question.
you could just match on
/[a-zA-Z]+/
That would already put you in the top 10% of solutions I've seen so far on this problem.
My confidence in my job security and general programming abilities has skyrocketed after visiting this thread
Depends if you're working for a good company or one trying to hire people in a third world country for a dollar a day.
I knew a dude who got a job for a programming language he never wrote. Not only that, the guy was hired to be the experienced / lead programmer to give guidance on how to use the language. In fact, I knew multiple people like this. Some were actual programmers and good at other programming languages, but some had decided it was time to switch from another field (geology, marketing, database engineer, ...).
It's still puzzling how they got their jobs.
Sometimes, aptitude and an ability to learn and grow is more valuable than having specific technology knowledge. It suggests a more generalist take on one's career, which means they are always going to be useful. There's also something to be said for "soft skills" and a person's overall attitude. All this can make the balance for a lack of technical experience, provided they have demonstrated talent an ability to close such gaps.
Other times, the whole hiring process is just completely broken. Your friend may have had to contend with co-workers that were utterly incapable at their jobs.
If your client has an HD picture button (like Boost) you need to click it to actually receive the proper image
As someone who teachers high school freshmen computer science this pains me as most of my freshmen could do all of these.