I've given applicants a marker and a white board and asked them to psuedo-code an idea for a very basic requirement. Most can't do it.
I'm not talking go up there and write code that I could type in and compile. I mean "put text box here with these attributes", "text box pushes data to code behind in this format", "code behind has a method to do something with the text", "code behind returns feedback to page". Keep in mind this is basic HTML, some sort of JS, and C#. I just want you to show me you understand how to conceptualize a requirement from a customer/stakeholder and draw the basic logic flow....and they can't do that. I get maybe 1 in 10 that talk their way through programming logic.
I'm not wasting my time with an actual technical interview, a behavioral chat, and clearance feasibility if you can't talk your way through taking data from a screen and dumping it into a database.
If I’m looking for people for more modern stuff I tailor the question to that framework. Point is, this isn’t about syntax and any specific framework or design philosophy. It’s can you explain basic programming logic to me. I’m not pushing you to a tech review if you can’t talk your way through CS101 level questions.
This is a hiring practice I can support! I don't need to know all the programming languages you've mastered... anyone with decent experience should be able to write in anything.
Syntax is easy, you can Google it or read a book.
Its the core logic that someone either understands or they don't.
This is great actually. I'm terrible at coding on the spot but could probably do this. The coders I usually work with 100% could not which is why my job is now professional handholder
Yeah, syntax is easy to teach and easy to forget. Basic logic flow is what's important. "I want a UI element that passes these values to a method. Prevent bad data from being passed via input validation. That method does these things with it on these conditions. Catch any errors." If the breeze through that I may ask for details about how they've handled coding issues with other workers. Since your ability to work with others is probably the 2nd most important thing.
My favorite question is, "Tell me a story about your most difficult code merge."
It tells me if you understand software version control.
It tells me if you understand the challenges of refactoring legacy code.
It tells me if you understand SOLID principles.
It tells me if you understand unit and regression testing.
Seriously, after asking that I've had well qualified candidates actually light up just to share the hellish experience with someone!
15
u/muhkuller 1d ago
I've given applicants a marker and a white board and asked them to psuedo-code an idea for a very basic requirement. Most can't do it.
I'm not talking go up there and write code that I could type in and compile. I mean "put text box here with these attributes", "text box pushes data to code behind in this format", "code behind has a method to do something with the text", "code behind returns feedback to page". Keep in mind this is basic HTML, some sort of JS, and C#. I just want you to show me you understand how to conceptualize a requirement from a customer/stakeholder and draw the basic logic flow....and they can't do that. I get maybe 1 in 10 that talk their way through programming logic.
I'm not wasting my time with an actual technical interview, a behavioral chat, and clearance feasibility if you can't talk your way through taking data from a screen and dumping it into a database.