Programming Interview Questions Are Too Hard and Too Short

[DEAD7]

Programming Interview Questions Are Too Hard and Too Short
Programming Interview Questions Are Too Hard and Too Short - Triplebyte Blog

Programming interview questions can feel unnecessarily difficult. Sometimes they actually are, a new study has found. And this isn't just because they make interviews excessively stressful. The study shows that harder programming questions actually do a worse job of predicting final outcomes than easier ones.
From the study:
Programming under time pressure is difficult. This is especially true during interviews. A coding exercise that would seem simple under normal circumstances somehow becomes a formidable challenge under the bright lights of an interview room. Stress hormones cloud your thinking during interviews (even though, sadly, neither fight nor flight is an effective response to a menacing programming problem). And it can almost feel like the questions are designed to be perversely difficult. I actually think this is more than just a feeling.

Interview questions are designed to be hard. Because the cost of hiring a bad engineer is so much higher than the cost of rejecting a good engineer, companies are incentivized to set a high bar. And for most companies that means asking hard questions. Intuitively this makes sense because harder questions seem like they should result in a more rigorous screening process. But intuition turns out to be a poor guide here. Our data shows that harder questions are actually less predictive than relatively easy ones.

 

[DEAD7]

Has anyone in HL interviewed programmers? What are you looking for/looking out for?

 

[yseJ]

^^Yes. And each interviewer typically chooses what he or she thinks is necessary. I avoid canned questions because people tend to study or memorize them. It ain't a test, it's your thinking and problem solving approach that interests me. Even if your answer is wrong or if problem is unsolvable or not enough info is provided, it's your thought process and approach that will make or break your case.

In programming, just like engineering in general, it's actually very easy to probe peoples knowledge and understanding of concepts.

Unless something is crucial and language specific, like managing memory in c/c++, or if position implies certain language is preferred, you can guide me through your thought process in any language, or pseudo code or just logic. Right algorithm is always a +, as opposed to perfect language mastery and bad algorithms

 

[rapbeats]

Programming Interview Questions Are Too Hard and Too Short
Programming Interview Questions Are Too Hard and Too Short - Triplebyte Blog

Programming interview questions can feel unnecessarily difficult. Sometimes they actually are, a new study has found. And this isn't just because they make interviews excessively stressful. The study shows that harder programming questions actually do a worse job of predicting final outcomes than easier ones.
From the study:
Programming under time pressure is difficult. This is especially true during interviews. A coding exercise that would seem simple under normal circumstances somehow becomes a formidable challenge under the bright lights of an interview room. Stress hormones cloud your thinking during interviews (even though, sadly, neither fight nor flight is an effective response to a menacing programming problem). And it can almost feel like the questions are designed to be perversely difficult. I actually think this is more than just a feeling.

Interview questions are designed to be hard. Because the cost of hiring a bad engineer is so much higher than the cost of rejecting a good engineer, companies are incentivized to set a high bar. And for most companies that means asking hard questions. Intuitively this makes sense because harder questions seem like they should result in a more rigorous screening process. But intuition turns out to be a poor guide here. Our data shows that harder questions are actually less predictive than relatively easy ones.

just like most interview questions or tests. stop TRYING to be hard and be realistic. if you want to design questions. how's about you giving the person an actual programming question that can't yet be answered at your office. something your current guys have run into and are trying to current figure out. the first candidate to figure it out gets hired. or try to have them program a piece of something that is truly in production or going to be produced in the near future that you guys are working on. so basically, REAL WORK. not fake test stuff.

 

[rapbeats]

^^Yes. And each interviewer typically chooses what he or she thinks is necessary. I avoid canned questions because people tend to study or memorize them. It ain't a test, it's your thinking and problem solving approach that interests me. Even if your answer is wrong or if problem is unsolvable or not enough info is provided, it's your thought process and approach that will make or break your case.

In programming, just like engineering in general, it's actually very easy to probe peoples knowledge and understanding of concepts.

Unless something is crucial and language specific, like managing memory in c/c++, or if position implies certain language is preferred, you can guide me through your thought process in any language, or pseudo code or just logic. Right algorithm is always a +, as opposed to perfect language mastery and bad algorithms

i've been saying this for years. I tell people all the time. I'm not a programmer. i could've been, but i dont desire to memorize every coding language out there. I'm too lazy for that now. But I do understand the logic.

No matter how complex the coding can become, its still, If this logic is true, then do this, if that thing is false, then do that.

you can get crazy and start nesting that logic in different ways but its still the same If this else that setup.

you programming a simple log in and password setup. When This Thing and This thing = These two things in a database where your log in and password are held. Then Open.

it never changes.

video games, same logic.

If no other controls/buttons are pressed and user presses Y,if True...make character Jump straight up X high, If False(else).....(then the other scenarios when you can press the Y button, like if you press forward and also press jump. your player should jump forward or back, backward, or run and jump jump forward further.

if this is true, then do that, if it is false then do that.

 

[yseJ]

its a bit more complicated than that, especially when it comes to math and performance evaluation, ie algorithms and your big-Os, but in general -yes

I also dont see a problem with short questions. again, any question will show knowledge level. a long question is usually not worth the time because it takes a long time to digest and we want more sample points. many small questions is better than few large questions, imo for both sides.

clever answers can be a real big +, but they can be a big - if you just memorized the clever answer and you hit your question

Ive heard someone give a clever answer for a canned question once, and I gave that person another question that was very closely related, just not something they can regurgitate without understanding. and they stumbled hard on it. needless to say, they didnt get the position.

 

[rapbeats]

its a bit more complicated than that, especially when it comes to math and performance evaluation, ie algorithms and your big-Os, but in general -yes

I also dont see a problem with short questions. again, any question will show knowledge level. a long question is usually not worth the time because it takes a long time to digest and we want more sample points. many small questions is better than few large questions, imo for both sides.

clever answers can be a real big +, but they can be a big - if you just memorized the clever answer and you hit your question

Ive heard someone give a clever answer for a canned question once, and I gave that person another question that was very closely related, just not something they can regurgitate without understanding. and they stumbled hard on it. needless to say, they didnt get the position.

you are correct but thats the math. but the point i'm making is simple. that is the LOGIC/Engineering of it. There is a reason why they tell you it will take longer to brainstorm the solution than to actually program it. (usually). Now when you get into memory allocation, i'm out. Lol. and to me thats where the next level lies anyway. how well can you program something to use the right amount of memory without freezing up. a lot of guys/gals have the logic down too but they will be completely stuck when it comes to that. obviously you have other groups working on memory but it would be nice if the initial people truly understood that part of the equation. and this is any type of programming down to writing sql to pull reports/data. Computers/Software/Programming is cavernous there's a thousand ways to do the same thing. But there are only a select few ways to do that thing using the proper amount of ram when necessary and have it know when to be able to utilize more when resources are available and less when they are not. but you already know this Ys.

I just hate canned questions. You've been working in the field for 10+ years. are you telling me you dont have any on the job questions you could ask me? are you telling me you dont have a problem on your desk right now that i could solve? or attempt to?

Lets find out real quick if i can actually do the job. give me a piece of the actual job to do.

and last but not least. lets keep it a buck... half of these programmers are online asking each other for help. I know this because i see them. I read these questions and answers even if I barely understand what they are talking about. sometimes I'm like "how did you get hired?" lol. other times i can see guys breaking stuff down collaborating. or old heads teaching newbies how to work those memory issues i described above.

 

[yseJ]

you are correct but thats the math. but the point i'm making is simple. that is the LOGIC/Engineering of it. There is a reason why they tell you it will take longer to brainstorm the solution than to actually program it. (usually). Now when you get into memory allocation, i'm out. Lol. and to me thats where the next level lies anyway. how well can you program something to use the right amount of memory without freezing up. a lot of guys/gals have the logic down too but they will be completely stuck when it comes to that. obviously you have other groups working on memory but it would be nice if the initial people truly understood that part of the equation. and this is any type of programming down to writing sql to pull reports/data. Computers/Software/Programming is cavernous there's a thousand ways to do the same thing. But there are only a select few ways to do that thing using the proper amount of ram when necessary and have it know when to be able to utilize more when resources are available and less when they are not. but you already know this Ys.

I just hate canned questions. You've been working in the field for 10+ years. are you telling me you dont have any on the job questions you could ask me? are you telling me you dont have a problem on your desk right now that i could solve? or attempt to?

Lets find out real quick if i can actually do the job. give me a piece of the actual job to do.

and last but not least. lets keep it a buck... half of these programmers are online asking each other for help. I know this because i see them. I read these questions and answers even if I barely understand what they are talking about. sometimes I'm like "how did you get hired?" lol. other times i can see guys breaking stuff down collaborating. or old heads teaching newbies how to work those memory issues i described above.

its actually very difficult to give an actual job to do. because actual jobs are very specific.

so your knowledge is being tested if you can actually even approach problems, because your job wont be to mindlessly write code you copied somewhere off the net

half of these programmers are online asking each other for help.

and most of the time its very specific things, or concepts in specific languages that arent clear to someone who just starts working on those languages.

programming, especially nowadays, isnt in a vacuum. a large project has hundreds of third party libraries and apis that were written by someone else.

that someone else isnt perfect. some api method for what you want to do exactly might not be present so you have to think of workarounds. some client library might be solid in one language and trash in another. you might have serialization issues. you WILL have constraints where things you would do normally don't work so you have to create ugly hacks. you have design decisions that can't be reversed and you have ugly backwards compatibility issues.

this feeds into what I said about jobs being very specific. you arent going to be reinventing the wheel on your job. if I gave anyone a piece of code I need to write on an interview and expect anyone to finish it with any success, it will take weeks if they get into specifics.

job interviews are never that specific. you will be solving specific problems on your own, but I need to see how you approach abstract/generic problems before I can trust you with specific shyt

 

[rapbeats]

its actually very difficult to give an actual job to do. because actual jobs are very specific.

so your knowledge is being tested if you can actually even approach problems, because your job wont be to mindlessly write code you copied somewhere off the net


and most of the time its very specific things, or concepts in specific languages that arent clear to someone who just starts working on those languages.

programming, especially nowadays, isnt in a vacuum. a large project has hundreds of third party libraries and apis that were written by someone else.

that someone else isnt perfect. some api method for what you want to do exactly might not be present so you have to think of workarounds. some client library might be solid in one language and trash in another. you might have serialization issues. you WILL have constraints where things you would do normally don't work so you have to create ugly hacks. you have design decisions that can't be reversed and you have ugly backwards compatibility issues.

this feeds into what I said about jobs being very specific. you arent going to be reinventing the wheel on your job. if I gave anyone a piece of code I need to write on an interview and expect anyone to finish it with any success, it will take weeks if they get into specifics.

job interviews are never that specific. you will be solving specific problems on your own, but I need to see how you approach abstract/generic problems before I can trust you with specific shyt

you can use the problem, to ask them how would they go about it. they dont have to give you all of the specifics. but its still a real life, real word problem. not some fake test thats a brain test to make it hard for hard sake. now there are certain questions that you can find on IQ tests that will tell you right away how a person thinks and breaks down things logically or illogically.

I can't remember the exact question but it was picture of pieces of wood. and you had to figure out how to lay the wood out in order to get across a body of water. To figure that out you would need to show some logical thinking, analytical thinking, engineering, etc. Programmers are problem solvers. Just like engineers. they are also creators since they can build their own worlds within the program.

 

[yseJ]

I mean, the only reason I don't like canned questions is that they're in every interview book. Many of them test right knowledge but they are so common people just memorize them.

Reverse a string is a classic question. It tests basic logic of reversing a string in memory with least amount of stack variables allocated, but it's so common there's no point asking it. It does test your understanding of loops, efficiency so you don't allocate bunch of variables just because and so on. But again, just too common. Same with fibonacci number function. It tests basic understanding of recursion but it's simply too common.

Also do understand that in large companies like Google you most likely will have zero freedom as a programmer and you will be working on something so specific that they will have to provide you with all the training.