Candidate with strong theory but less practical skill vs. confident coder with mediocre theory?
Posted by NightestOfTheOwls@reddit | ExperiencedDevs | View on Reddit | 200 comments
We've been looking for a Java developer for a little while now, and while most candidates are predictably mediocre and somewhat fine in everything, every now and then you'd get one of those guys:
-
Very good at theory, knows, a lot of details, trivia and "how things work" but has below average code reading and writing skills. Either writes too slow and with mistakes, unable to find bugs in existing code or properly architect a solution
-
Confident at writing code, generally solves the problem in an acceptable way but seriously lacks the knowledge, often saying "I don't know\don't remember that", "Can I google/look up docs?", "I don't know how (algorithm) works, can you remind me?" and sometimes uses suboptimal solutions due to not knowing advanced Java and SQL functionalities
Either way, in cases like these I'm often leaning towards the latter type, because it just seems easier to get them to start meaningfully contributing, while when hiring the former type we had cases where a seemingly great candidate who knew the language and theory perfectly was struggling to create a simple controller according to specifications (and it REALLY didn't sound like he was cheating on the interview, but maybe we're just bad at catching this kind of thing). On the other hand, the former type of guy could just be nervous on the interview and just needs to get into some kind of "flow" once on-board.
In your experience, was hiring a know-it-all and getting them up to speed more beneficial over getting a productive coder with a noticeable lack of knowledge and filling in the gaps via code reviews and mentorship sessions?
HiImWilk@reddit
I dispute your definition of “good on theory”. Knowing which type of sort .sort() actually uses is nice. Being able to spot an SRP violation, explain why those are bad, and how we can avoid them, is way more important.
I’ve had the former also labelled “theory”, and would agree. The single responsibility principle is, technically, just an opinion on what good code is that we’ve all come to agree on.
Lumethys@reddit
What kind of developer do you expect if that is "seriously lacking fundamental knowledge"?
NightestOfTheOwls@reddit (OP)
The current hiring standards at my org is that you know SQL very well, you know Java very well and you know how popular algorithms for (at least) sorting work, and can answer without looking it up. I don't really agree with this, but it is what it is.
Also, I believe I never said "fundamental", as we're interviewing for a middle position.
HiImWilk@reddit
That’s the equivalent of demanding all players on an NBA team know how to spin a ball on their finger. Steph Curry doesn’t know how because he was too busy learning to play real basketball.
MCFRESH01@reddit
I’ve been doing this for a decade and I blanked out on switch statement syntax yesterday and had to look it up . Your company needs to revise their hiring practice.
NightestOfTheOwls@reddit (OP)
You know, even when I was looking for a job myself, I never once had an interview during which I could ask to google something and not get a weirded out look. To everyone saying it's unheard of at their place to refuse this kind of request, please let me know if you're hiring.
Willing-Database6318@reddit
If you’re interviewing for a senior position in top hedge funds (citadel, Jane street, etc), you will be allowed to Google. Even basic things like CASE syntax in SQL are fine.
CommodoreQuinli@reddit
That is the change I’m trying to make to our recruiting, I just got full control of our engineering reqs so if your good and want to work in AI drop a resume or linkedin in my dms
Win_is_my_name@reddit
backend devs?
CommodoreQuinli@reddit
for backend ideally really solid java xp, python/node could be useful as well or if your just great at some other stack. but java spring with good writing and communication skills are needed
NatoBoram@reddit
I do open book interviews and we're hiring
Ozymandias0023@reddit
The experience I've had when I don't remember exactly syntax is that as long as I make it clear to the interviewer that I know the method I want but can't remember the exact name or signature off the top of my head, they let me just guess as "we're not testing syntax here".
It sounds to me like whoever is setting the interviewing standards at your shop is valuing syntax over functionality, which is concerning. If you have enough political capital, you can try pointing this out to leadership. Otherwise, I feel bad for candidate #2 because it sounds like he's about to lose an opportunity due to incompetence on the part of management.
selfh8ingmillennial@reddit
Did you actually ask that in an interview and get a weird look, or are you just assuming you would have? If you didn't ask, then you don't know what reaction you'd get. And if you did ask, then why would you hold it against someone else for doing the same?
If I have given someone a very specific problem to solve on the spot, I don't mind them using Google. It's like an open book test: if you don't already know the material, the book isn't going to save you. And hopefully you are reviewing their solution with them and can tell if they are able to reason about it or if an AI wrote it.
FX2000@reddit
I always find it refreshing when someone I’m interviewing actually looks for documentation instead of blankly staring at the screen for 5 minutes trying to remember some random syntax.
caffeinated_wizard@reddit
Why ask the question in this sub if you already know the answer you want? If you care more about people who can break your interview process just hire the inexperienced know it all.
MCFRESH01@reddit
I’ve had the opposite experience. Interviewers have told me at pretty much every interview I’ve done it was fine to look up documentation
Careful_Ad_9077@reddit
I always look up switch syntax.
FlipperBumperKickout@reddit
Code snippets to the rescue 😁
TheTyger@reddit
One time I was doing a pseudo-code white board interview, and wrote a loop with a sort of for (1 -> n; ++) syntax intending that I wasn't going to write out the actual incrementer syntax because it was a pseudo-code whiteboard question and didn't matter, did the whole rest of the logic for whatever the loop was, and then the interviewer complained that I wrote 1 instead of 0.
Like dude, the shit on the board is not actually in a proper programming language, the fact that I described the loop starting at 1 instead of 0 in human-ish terms isn't going to be the make or break here. (I later found out that the reason I didn't get the job was because one of the more senior people there was trying to sleep with my girlfriend, who also worked in a different department there. He later for fired for sexual harassment when he started trying to leverage my "not being good enough for the job" as a way to try and sleep with her).
beefz0r@reddit
I can't imagine a scenario where knowing a sorting algorithm by heart is of any importance. Let alone implementing a sorting algorithm yourself.
zero_hope_@reddit
Who doesn’t know sorting algorithms. “ | sort” or “.sort()” what else do you need?
Potato-Engineer@reddit
I can bubble sort, and I've never had to write it.
(Okay, I think I know quicksort well enough to write it, but again: never had to write a sort, outside of schoolwork)
Junior-Ad2207@reddit
Will you remember them ten years from now?
EvilCodeQueen@reddit
Seriously tho, how often are you writing sorting algorithms in your daily work?
SketchySeaBeast@reddit
Instead you're using '.sort()' but you're still looking up the syntax for the lambda function.
jimsmisc@reddit
i've been writing javascript for like 20 years and I still look up the syntax for the sort lambda function.
Actually for the last \~6 months or so I just have AI write this kind of code. It's perfect at things like "write a function to take this array of objects, sort them by domain name and parse the URL value to be relative instead of absolute"
po-handz3@reddit
Meanwhile there's a dozen threads a day complaining about how useless AI is for coding lmao
EvilCodeQueen@reddit
AI isn’t useless. It’s great when you keep it on a tight leash and fully understand what you asked for and what it provided. But it’s not at the level some CIOs think it is.
EvilCodeQueen@reddit
Right. Generally speaking, if it’s not something I’m doing just about daily, I’m usually looking it up again.
Sporkmancer@reddit
Sorting algorithms have the same problem as using hard leetcode (easy and some mediums make a lot more sense) for interview questions. Unless you need a very specific type of specialist, you're now filtering for people who study for these interview questions, not people that are good software devs.
I have written a sorting algorithm exactly once in professional capacity in my years of software development: when interviewing for my second job, I had to white board a sorting algorithm. I purposefully did bubble sort (nowadays I'd consider bogosort if someone is wasting my time with this interview question after >10 YoE lol) in pseudocode to make sure they weren't just filtering for quicksort or something. I got that job, had it for more than half a decade, never once needed to do a sort more complicated than an "order by" in a sql statement.
In other words, I don't see what use this test actually is, especially when developers nowadays are specifically taught (often by us that used to have to answer the sorting algorithm interview questions) to never write your own sorting method as it'll be worse than the one in the library (at the very least because of worse test coverage).
From your questions, it seems you're indirectly involved in hiring at least. I'd strongly consider evaluating what signals your questions and tests actually give you, and whether or not those questions are also positive indicators for the person you are interviewing. A much more useful test would be something like a leetcode easy that you either paired program or review afterwards; alternatively, you can test the developer through intentionally bad (not just broken) code and see how they code review it, as that gives you a LOT of useful signals in both soft skills and language-specific/general programming knowledge.
TilYouSeeThisAgain@reddit
I’ve seen a software architect have to Google things as simple as string syntax in C, yet by all standards he does know C very well. The more people learn and use a language, the harder it is to have every little detail you’ve learned memorized. These standards are pretty disconnected from the reality of what makes a good SWE.
It sounds like you want to hire a good computer science professor rather than a good software engineer.
Snape_Grass@reddit
“They can’t remember how to merge sort on the fly?! Useless!”
eat_those_lemons@reddit
I'm sorry we asked for the sorting algorithms from worst to best big o, you forgot bogo sort
tonjohn@reddit
Interviews should not be trivia based. If the answer can be found in 30s of Googling it’s not a good question. In fact, watching a candidate try to find the answer can be tremendously insightful as it’s one of the most important skills in our actual day-to-day job.
It’s important to remember that interviews are stressful situations which cause incredibly smart talented people to forget basic syntax in the moment. Also, many of us work across multiple languages so it’s common to have a lapse on specific syntax as you are paging that language back into memory.
Finally, it’s straight up discriminatory towards people with certain disabilities like dyslexia who otherwise are excellent teammates.
touristtam@reddit
Culture / Character matching is so much more important once you've identified someone is capable at the job. Talent is nurtured.
zapman449@reddit
Real question: have you ever had to write a sorting algorithm for your job? Almost certainly not.
I remember 18 months ago I got to write a graph traversal algorithm for work. It was the first “real CompSci” code I had written in at least a decade, perhaps two.
We interview on sorting because it is tricky, and because we had to learn it, so we force others to… not because it is valuable per se (other than a way to poorly filter out more candidates)
What do you need out of a mid level candidate? Some who when given a problem goes and solves it. Within reason (code review, fits in general architecture, etc), it doesn’t matter how they solve it.
Unfortunately this trait is not something an interview can show.
Dexterus@reddit
About once a decade for me too, lol. And one of them was reading a paper and implementing that math so not really a "known algorithm".
TornadoFS@reddit
I used to work with complex SQL queries at least every week (and often every day), but I haven't had to that much in the past few years. So in an interview if you asked me how to do a group by or the difference between a left or right JOIN I would not be able to answer out of the top of my head.
nfigo@reddit
And this is why you have employees who can rattle off trivia instead of solving problems.
Xanian123@reddit
Kinda ridiculous honestly.
PettyWitch@reddit
When is the last time someone needed to implement sorting in your company’s codebase?
FluffySmiles@reddit
You work for idiots
GrayLiterature@reddit
Lmfao dude your company sounds horrendous.
letsbreakstuff@reddit
What the matter, don't trust java or SQL to sort?
Lumethys@reddit
The hiring policy is one thing, but you as a developer should know what skill is required to do your daily work.
If you, or any dev currently in your company, senior or otherwise. Sitting on their desk doing normal work on a Tuesday and suddenly someone comes and asks you/them on how do [X sorting] algorithm works. What would you or your colleagues say? Or, any of the hiring questions really, do all your devs be able to answer any and all of these hiring questions on a whim?
If your answer is the same as one of those candidates, then why are you judging them as "bad"?
kondorb@reddit
That’s a stupid hiring standard that no doubt some HR came up with.
failsafe-author@reddit
I have to look up stupid stuff all the time.
vienna_city_skater@reddit
Better look it up than to remember incorrectly. I oftentimes look up things just to cross check my knowledge, it doesn’t cost anything.
sawser@reddit
I've been a python developer for close to 20 years and I still have to double check
If name == "main":
Every. Single. Time.
chaoism@reddit
I have to look up legit stuff all the time :p
Monowakari@reddit
I did a math major. I looked up Taylor Expansion every single time. Because id rather not look the fool for getting something basic wrong, and somehiw was mostly an A student (seriously baffled how i didnt scrape by with Cs).
Give me a dev who consults docs every single time. Fuck your memory, if you can't execute you're next to useless. Ill take a midrange dev whose trainable and easy to work with all day, nvm they can consult LLMs now on the fly. I however do not accept vibe code and thrash people in PRs (gently) if I catch vibe coded bullshit
midwestcsstudent@reddit
Someone who studied for the interview?
Lumethys@reddit
on every possible algorithm? and/ or language features? i dont think so...
midwestcsstudent@reddit
I can tell you wouldn’t pass it lol. Never said you need to know “every algorithm” or language features.
KnightBlindness@reddit
Yeah the follow up to that is the most important part of the interview. Explain the concept and see if they have difficulty understanding the information. If they have a solid foundation, the concepts should be familiar and come back to them easily. The important thing is not that they memorized everything, but that they can easily learn new knowledge when needed.
Most of my day to day work is not spent coding, but trying to figure out optimal ways to do something. At this point it is never my assumption that I have to invent an algorithm myself, so it is a lot of searching and reading what solutions others have tried and understanding what applies to my particular problem.
marquoth_@reddit
The one who can't find bugs or the one who has to Google things sometimes?
How is this even a choice?
DeathByWater@reddit
The former lacks wisdom. The latter lacks knowledge. Knowledge is much easier to teach.
midwestcsstudent@reddit
It’s much easier to teach someone who knows the fundamentals to be a good coder than to teach a good coder a 4-year CS degree.
Few_Raisin_8981@reddit
Hard disagree. Just because one has a CS degree doesn't mean they are a talented programmer.. some traits are innate.
midwestcsstudent@reddit
That could totally be the case, but I’d still rather try to teach someone with good fundamental knowledge how to be a good coder than try to teach an innate programmer why O(n^(2)) is an unacceptable time complexity for certain algorithms.
God forbid I have to also teach them what time complexity is while I’m at it (has happened to me in the past).
QueenBlanchesHalo@reddit
A truly “innate” programmer will understand why O(n^2) is not acceptable even if they don’t describe it in so many words.
midwestcsstudent@reddit
Sure, but that’s clearly not the scenario OP is describing.
Variety-Unique@reddit
I don’t have a CS degree (master in electronics and never coded in my major) and I’m a much better programmer than most people I have worked with simply because I love programming and I like learning new things by reading whereas many CS graduates don’t read a single book after they graduate from university.
ThatFeelingIsBliss88@reddit
The funny thing is, asking to google is something they would only do in an interview. When they’re on the job, they’ll simply get the job done by any means necessary. Google might be part of the process.
The theory guy refuses to get the job done using the any means necessary route. They will only complete tasks using a perfect solution. Only after they’ve spent an inordinate amount of time on the problem will they finally concede and be willing to ship a “sub optimal” solution. What’s even worst is they apply that same standard to others during code review.
There’s a guy like this on my team. Incredibly smart, knows all the “right” way to do things, but he ships waaaay slower than I do. And whenever he reviews a PR you can guarantee it’ll take you five times as long to merge it. I occasionally tag him because I think it’s a good learning experience but at least half the time I end up deeply regretting it. He has absolutely no regard for shipping features in a timely manner.
And I would say that’s fine, if and only if after the pr is merged if there’s never any bugs found. Then the trade off would be worth it. But there still usually are bugs found because some bugs simply cannot be found in a code review. You need to get actual users in front of the feature, even if it’s just a dozen internal users.
Appropriate-Dig4180@reddit
They also asked if tests would help prevent prod issues.
Vector-Zero@reddit
Oooh, it's that guy.
eat_those_lemons@reddit
Tbf many eng teams don't have tests so the candidate just might not have worked on a good team before
Sporkmancer@reddit
Not the dev. The OP asked if tests would help prevent prod issues.
eat_those_lemons@reddit
Well that certainly brings their analysis into question
SpaceBreaker@reddit
They sound like proper senior candidates to me 🤷🏾♀️
NightestOfTheOwls@reddit (OP)
A good senior should be skilled in both, imo. Those seem like polarized middles to me
Crafty_Independence@reddit
You're looking for a Staff+ with specializations, not a senior
NightestOfTheOwls@reddit (OP)
Ok this is getting ridiculous. Where are you people finding middle-senior positions in which the interviews are so basic? If the combination of both of those guys in my post is a Staff+ engineer, what are the "normal" knowledge and skill standards for a middle, senior SWE? Everyone in the replies is losing their shit over how unrealistic the standards at my org are and I genuinely can't understand whether it's my company that has everyone overqualified and underpaid or just the people replying got extremely lucky to land in a minority of chill ones.
Crafty_Independence@reddit
Where are you finding seniors expected to have the skills of an architect AND perfect recall and implementation skills? That is quite literally Staff+ expectations
Willing-Database6318@reddit
Tbh the line for “senior” has just shifted, as a lot of people got the title of “senior” due to how long they’ve been coding, as opposed to how good they are. So now we have a bunch of seniors that 10-15 years ago wouldn’t pass as one
slopirate@reddit
That's standard senior level stuff at most top companies. Not staff+. I know this firsthand from many recent interviews.
Crafty_Independence@reddit
It's not, and I know that from seeing the internals of multiple orgs.
A lot of mid-grade companies force seniors to wear multiple hats like this, but it's a bad org practice and at least a yellow flag. Top companies understand the difference between senior and staff roles.
You might be able to force a good senior to carry that water, but it shouldn't be part of your baseline expectations. A senior is an IC who is capable of a large degree of autonomy, which primarily falls into the pragmatic implementation side of things.
slopirate@reddit
Downvote me all you want, but that's false. I've been doing this for twenty years. Have been on both sides of many many interviews. Last role was senior engineer @ FAANG. Senior level must pass rigorous system design/architecture interviews. That's a core responsibility of the job. This isn't my opinion, it's a fact.
Crafty_Independence@reddit
LOL. First off FAANG is known for hustle culture and blurring actual responsibilities in an irresponsible manner, including creating the mess of an interview process that a lot of people blindly copy. They are also a very small subset of the "top companies" and each of them actually have quite different responsibilities for seniors not only between them but also at the team level.
They helped build the staff+ role partially because they kept having failures with forcing seniors to carry both roles simultaneously. It may have been common in the past, but it's been through a lot of review at this point and there's a reason FAANG has moved to a lot more levels of engineers.
slopirate@reddit
You have no idea what you're talking about.
7heWafer@reddit
Such an irrefutable argument!
Appropriate-Dig4180@reddit
Your team doesn't write tests...
IsseBisse@reddit
This last part gets me. If you "have a bunch of theoretical knowledge" but can't design a system (which to me is still theory), you're not a good candidate. Knowing a bunch of theory by heart is pretty much useless if you can't apply it.
Sure, not knowing basic syntax or concepts could be an indication of lacking skills, but if that candidate "generally solves the problem in an acceptable way" I don't see the problem.
Developers don't get paid to recite algorithms, we get paid to solve problems.
Variety-Unique@reddit
And knowledge is different from information. Sounds like the first guy can’t get job done
OkWealth5939@reddit
wannabeaggie123@reddit
I think in the world of Ai coding, knowing things should be ranked higher than being able to write them. If you know then you can instruct the Ai better which will write the code for you. But you have to know what's happening which the candidate does right?
orz-_-orz@reddit
Don't you feel if a person knows the theory but somehow couldn't perform their job is more infuriating? Like the guy could beat you up in any debate and convince bosses on their proposal, but either couldn't execute it or would screw things up in practice.
warmans@reddit
Relevant question - as an engineer is it in fact possible to look things up in the docs?
NightestOfTheOwls@reddit (OP)
Sure. I get it why many forbid to do so during the interview, but sometimes they take it a bit too far imo. Personally, I let people look stuff up as long as it's not something comically basic
gdinProgramator@reddit
The more YOE I have, the more I look up “comically basic” stuff.
I haven’t written a date without looking it up multiple times in years.
EvilCodeQueen@reddit
What is “comically basic”? I look up basic syntax all the time because I’m a polyglot. Like, I can know I need to put stuff into the array (list? Tuple? Set?) In an interview I might forget that you don’t loop through sets in Python, and tuples are immutable and need to look that up because I’ve been working in JavaScript more lately.
kayimbo@reddit
I’m the same way. I been writing is 10 years but I also write 5-6 other languages so it’s all mush in my brain
EvilCodeQueen@reddit
This is the part that most interview cycles miss. Most of coding isn't writing code. It's reading code, understanding it, and understanding how it needs to change to accomplish a task. Interestingly enough, AI isn't very good at this either.
kayimbo@reddit
I’ve passed every job interview where they give me a problem to debug in realtime. I’m not sure I’ve passed any job interview with a realtime coding challenge.
EvilCodeQueen@reddit
I wish more interviewers asked debugging questions instead of LC garbage.
Schmittfried@reddit
That obviously depends on the candidate and position. If a senior JS developer applies for a senior JS position and they don’t know how to write a simple array mapping then chances are they’re not actually a senior JS developer or really really nervous.
EvilCodeQueen@reddit
I agree that there is a line in general, but I'm still not drawing it at "has to look up syntax". I flake all the time without someone watching me code. When I'm live coding, I swear, I forget my own name.
unskippable-ad@reddit
I have a ‘why is my unordered map ordered’ moment at least once a week, and I refuse to learn what the fuck a dictionary is
unskippable-ad@reddit
What the fuck is a hashset
SketchySeaBeast@reddit
My primary language has been JavaScript for three years now, I still try to append instead of push sometimes.
NatoBoram@reddit
At that point, make a snippet haha
Schmittfried@reddit
To be fair that’s on the JS language designers.
dosk3@reddit
This guy thinks that each developer knows everything all the time, lol. When i do recruiting i always give them task and a doc even google idgaf as longs they can read and solve issues
haskell_rules@reddit
People have different kinds of brains that work differently. Not everyone has a "jeopardy brain" with immediate retrieval of trivia. By selecting this very specific type of engineer, you are causing a lack of diversity that is seriously damaging your team and your organization.
Representative_Pin80@reddit
Not wanting people to look at docs an in interview is counter productive. Are you there to test memory skills or see how they perform on the job? I’ve been working with Java since 1.1.6 - back before it even had the collections framework! I spend so much time writing Kotlin and Typescript now that I’d likely have to look up how to perform a sort (Collections.sort?). Would you mark me down based on that?
TheTacoInquisition@reddit
I mean, I'll allow for comically basic if someone's having a moment. As long as they can rally or even just describe what they're doing in a sensible way, I don't care much about forgetting syntax
GTHell@reddit
I’ve noticed that people who are strong with theory, even if they're less practical at first, often have a lot of long-term potential. That’s definitely the category I fall into. Over time, I’ve been able to develop my skills and it’s really helped my career grow.
Now, that’s not to say the super confident, practical coder is a bad thing at all! Those people are absolute heroes on support teams or when you need a hot fix ASAP. You really need both types of people—it’s not even a fair comparison.
It’s like trying to compare a Project Lead and a Tech Lead. They’re just different roles, and each one brings its own unique value to the table.
If you're leaning to the later type it's mean your team is not focusing much on delivering constant new features? I guess your product is already establish and most of the thing is just small features requested week by week from the owner?!
damemecherogringo@reddit
Assuming the interview gives an equally accurate picture of either, I’d tend to give a “horses for courses” answer - if it’s a role that needs a doer and a finisher that needs to work more on their own, the second profile may yield better performance . On the other hand, if the role is for a team that has plenty of doers but lacks some theory to guide or deepen their work and make it reliable and performant, the first may be best.
One may look at engineering teams like an athlete: there is no “best” training, only well prescribed or poorly prescribed training according to the athlete’s specific needs and weaknesses. What are the needs and weaknesses of the team?
davy_jones_locket@reddit
That's what seniors and tech leads and principals are responsible for. And I'm sure they can also write code. Plus they'd have tips on how to find the solution themselves, like looking up on google or in the docs.
The first sounds like a new grad who knows the classroom but not the application of the knowledge and the second one sounds like an experienced engineer.
damemecherogringo@reddit
Yes, but if the needs of the team are either "our short term goals are paramount: we need someone to deliver high value right now" (e.g. a startup) or "our medium to long term goals align with investing in the talented new grad because we don't need immediate return, but we need to invest in talent" then the decision would be different, no?
davy_jones_locket@reddit
You expect the new grad to "guide the team on performance and deepen their work" though?
If you want to hire new grads, do it. I want new grads who will pump out code and then have it ripped up by seniors so they can learn. You don't hire new grads to "teach the team to be for performant or deepen their work with theory."
liquidpele@reddit
The first sounds like someone bullshitting OP and they don't realize it. I don't care who you are, you don't actually know theory if you can't utilize it.
Mammoth-Clock-8173@reddit
This. I want both on my team. Not always in a single individual, and not both in all individuals.
PayLegitimate7167@reddit
I guess the one who is open to feedback
PayLegitimate7167@reddit
You want a balance between of both
nokky1234@reddit
Know it alls are very good at creating tension.
People who do shit and have to look stuff up or even have cursor do most of their work are very appreciated by people who pay invoices.
BeardyDwarf@reddit
It is easy. You are hiring people to write code. If person cannot write code why are you even considering this candidate? Rare knowledge can be compensated by seniors.
midwestcsstudent@reddit
This thread pretty much sums up why most software out there is utter trash.
It’s much easier to teach someone who knows the fundamentals to be a good coder than to teach a good coder a 4-year CS degree.
It’s a buyer’s market. Don’t skimp out on good talent or you’ll end up with a shitty product like everyone else.
zoolicious@reddit
You'll regret hiring a know-it-all. Their solution will always be the right one, turning every solution discussion into a debate to be won or lost. They will go down rabbitholes, focussing on the details of the specific technology they're using, rather than stepping back to consider the root cause of a problem. They will always want to demonstrate how much they know about something, which at best means they'll derail meetings/solution sessions by getting into the weeds.
Isogash@reddit
The latter type will get more done than the average person, but at a cost: they will accrue tech debt at a faster rate.
Therefore, whether or not they are a good hire depends on what you're hiring them to work on. If it's something where tech debt is absolutely unacceptable then they are probably not going to be a good fit e.g. critical software or long-running hyper-scale projects, but they would probably be great fit for smaller, less critical tasks where speed = value e.g. prototyping and non-critical supporting tools development.
The former type seems completely useless if they don't also have good architecting skills; if they don't have confidence doing something then they can't do anything. However, if they were confident in architecting, then actually they might be a better candidate than most for the exact opposite roles than the confident coder.
OkLanguage9942@reddit
You seem to be equating confidence with competence?
SeveralAd6447@reddit
Always pick the latter. Every time.
CompassionateSkeptic@reddit
Holy shit, this is one of the most stark gaps between post title and description I have seen in this sub.
Pale_Height_1251@reddit
I'll take the one who I think is best at building software.
YellowLongjumping275@reddit
That depends, are you hiring him to write code or theorize? (This question is rhetorical)
Everyday_sisyphus@reddit
Know-it-alls tend to “know it all” because the practical stuff that’s worth knowing is the actual hard part, so they’re super loud about their memorized facts to try to compensate and quell insecurity that comes as a result of being sort of useless in practice. Go with the person who can actually do things. They’ll learn more theory as they continue to do things.
NoobInvestor86@reddit
I refuse to believe you’re an experienced dev with this question lol
waaaman@reddit
So a person that can memorize, but can’t/won’t think vs one that cant/wont memorize, but can think…. Idk I didn’t memorize this question.
Azure-y@reddit
When hiring, I’d say to categorize strong candidates into two buckets: 1) high ceiling, low floor: fundamentally strong such as abstraction & mental model thinking, problem solving, designs, etc. but lacks the practical experience; 2) low ceiling, high floor: strong in practicality, know all the nitty-gritty details of the specific technology will be used, but not necessarily skilled on the fundamentals.
First bucket is great for full timer. Longer ramp up, but higher potential. Second bucket is great for contractor. Quick to contribute, not expecting too much growth.
But, I believe in your case, the 1st candidate doesn’t fit in neither bucket and the 2nd candidate fits the 2nd bucket.
I would say 2nd candidate is preferable.
big_data_mike@reddit
I would go with 2 because I’ve worked with a few 1’s and hated it. That’s from my own personal anecdotal experience with a sample size of 4. So I look at it through my biased lens.
It’s better to hire attitude and teach skill.
sarnobat@reddit
At college I hated how smart professors would make theory an end in itself. It was only exciting when I realized the real world application of it.
During a contractor stint at Google my seniors taught me functional programming and thus the value of map reduce in Hadoop, Cassandra etc
sarnobat@reddit
Sadly, someone with command line skills who doesn't know what functional programming is is more useful than someone who knows lambda calculus but can't write a shell script
hulk_enjoyer@reddit
Posts like these instill impostor syndrome. It apparently is a negative impact to your career if you must look something up.
Fellas, we're cooked.
armahillo@reddit
Don't forget that the "Con" in "Con man" is short for "Confidence"
Unless by "confident" you mean "practically skilled"?
dbxp@reddit
Where I work I'd hire both, my experience with our recruiters is that we rarely get good applicants for jobs and we're a big company.
If I could only hire one I'd definitely take the second. I want someone who can work practically with multiple stake holders, the theoretical genius could easily be a liability where they refactor code simply because it doesn't match the textbook.
flavius-as@reddit
I am naturally inclined towards the one with strong theory because I was such a guy and I know how much of a boost it is to know the theory and the terminology. Helps tremendously to know what to google, even more so nowadays with AI.
However you're hiring for a position into a team. So it depends on the position and the team and the organization at large.
If you have good retention and good seniors who can mentor the theorist, that he'll rather quickly overpass the pragmatic one.
If you don't have good retention, hire the latter so that you can milk work out of him before he leaves.
mikaball@reddit
You want a Junior Dev or a Software Architect? - "unable ... or properly architect a solution". Never mind... that guy is useless.
How the hell is he "good at theory" but doesn't know how to architect a solution? What is theory for then?
StillTradition2021@reddit
I like to interview people on the basis of their problem solving. Often I ask questions on the basis of the work they claim to have done in the last project. Yes then there is some basic theory stuff which you should know. I have seen experienced developers who can’t explain difference between get/post
Realistic_Tomato1816@reddit
Theory is only good if you can quickly validate and get confirmation.
This is a deal breaker for me. I need to see a quick POC to validate. Or else, it is just pontification.
misterguyyy@reddit
You’ve basically summarized Juniors with the stuff they learned in school fresh on their mind vs Seniors who started when the ecosystem was way different.
Just like my middle schooler remembers biology terms better than I do, but I can find and vet research and sniff BS way more proficiently.
Although being front end it’s not so much “I don’t know/remember that” and more “how are the ES6/CSS3 w grid kids doing it nowadays?”
_hephaestus@reddit
Depends on the work. Does knowing how particular algorithms work come up frequently in your company? If the expectation is they’re going to be doing complicated hyper optimized cutting edge work for day trading or whatnot? In that case hire neither, if they forget how their code works/it takes them too long to build well, doesn’t really matter.
If not cutting edge, the second does fine. Looking stuff up at planning/initial writing is constant time complexity, not being able to execute in actually writing code is linear at best.
AttemptNo499@reddit
Maybe i always got unlucky, but the candidates I had who were really good at theory were always bad employees, slow, arrogant, etc... I would take someone who can handle things on their own everytime if given a choice
Klutzy-Foundation586@reddit
The confident coders with mediocre theory are exactly the developers I want to hire (although the question is stated in a way as to sound like a dev is always one or the other), and it's one of the things I'm looking for in an interview. This kind of person can pick up new languages quickly because they know what can be done and also know how to use docs or Google or whatever. They're not limited by freaking out when they run into something they don't know. One of the least productive hires I ever made was a comp sci PhD. They have a tendency to get things actually done rather than spinning on trying to find "the optimal" solution. We can always optimize later if there are issues. It also shows someone confident about what matters. Getting shit done.
I will admit that I don't like candidates to use documentation during interviews, but I also don't judge on details that docs would solve. Nobody completes my coding task, ever, but that's not the goal. It involves a detail that's pretty (surprisingly) obscure these days. I'm up front about expecting you not to know because it's a discussion point to see what you do when you simply don't know, so we talk it through. You don't have to get it right. You just have to either admit you don't know (that's a positive response because you have the self awareness to know and admit your limits) or a solution that makes sense. I don't care about syntax as long as you can describe what you meant in a way that shows you know what you're talking about.
HankScorpioMars@reddit
I volunteer for every interviewing tasks I see. I find it a privilege to be able to have a word on who I work with, so I've done a lot. I'm quite proud at how good I am at predicting how successful a candidate will be if hired.
Saying "I don't know" is one of the main green flags in my book. Being confident and quick at saying it shows that this person is happy to leave trivia aside and get the answer from someone or somewhere else. People who work by themselves and never show their knowledge gaps are terrible teammates.
You're looking for someone who's good at the job, not at the interview. You'll be getting a colleague, not an LLM-human.
Sporkmancer@reddit
Is this a troll post? Why would you ever consider someone for anything other than a junior position if they struggle to read code or debug?
moogle12@reddit
Maybe their company is building a theoretical product
stevefuzz@reddit
OP is getting destroyed lol
Any-Neat5158@reddit
I'm probably right in between the two personally, but starting out I was for sure in line with the first description.
White boarding can be nerve wracking like trying to take a piss with someone looking over your shoulder. I also just plain suck at green fielding. I can do it, and i'm getting better over time but it was a blaring weakness.
To answer your question, neither employee stands out. Both have things that need to be addressed to become competent individual contributors. Both have ramp up time to get there. Looking at #2 and thinking "well... this person will be spitting out PR's sooner / quicker" might be technically true you can be sure they'll also have to go back and redo tasks because the approach they took (while functional) doesn't really measure up in other ways. Maybe the code they wrote isn't efficient enough, maybe it's not maintainable.... etc.
Both employees need polishing. Just in different ways.
One reoccurring thing I've been told over, and over and over is that while I am not the strongest person on the team technically (I work on a team full of very good devs... so I'm among the weakest in that domain) I am absolutely a great team mate. I have the soft skills down so well that my team members are more than happy to help me grow the technical.
My lead flat out told me that you can teach a nice teammate how to code. No matter how hard you try, you'll never teach an asshole to not be an asshole.
I've seen several incredibly smart, technical, assholes get shown the door.
AnarchycMofo@reddit
Hi, I'm good in theory knowledge and fast at typing and providing solutions, also many years of xp with Java. Where do I send my resume?
/s but if you want not /s
BarfingOnMyFace@reddit
What’s up with this either/or shit?
bigbry2k3@reddit
I'd go with #1 in my opinion because they do understand what's supposed to happen or what they are supposed to do, but due to lack of experience they have trouble implementing it. Whereas #2 seems like they don't know how to research a problem and find a solution they are asking you to help them. I'd rather see a jr try to research it first and I would teach them how to do that and talk through it "rubber duck" approach, than to see someone come to me every few minutes asking them "can I use ChatGPT" "Can I google this?"
mad_pony@reddit
The one who communicates better. At the end of the day you want to be on the same page with him regarding project progress and some technical decisions.
optimal_random@reddit
Join them together, and you'll have "Pinky and the Brain". /s
Seriously, theory is usually harder to learn and eventually more important to solve very complex problems.
Assuming both guys can pick up any tech quickly, I'd choose the more theory-oriented guy.
Sporkmancer@reddit
Hard to believe the first guy can pick up tech quickly if he really does struggle to read code. Assuming that the OP is accurate and truthful about these candidates (check their second most recent topic to see why I don't think they're accurate at least...), I don't know if I'd even consider the first developer a... well, a developer.
OutragedAardvark@reddit
Especially with AI generation becoming better and better the theory seems increasingly important to me.
The only thing that gives me pause is poor code reading abilities. It is possible they are just unfamiliar with the syntax, but it could also mean they are good at high level and bad at low level. I have met these types and it doesn’t improve much over time - some people truly are good at understanding programming but bad at writing it
BanaTibor@reddit
How many YOE are we talking about? I would take the coder, if you are in the industry and can not implement anything on your own after half a year, you never will. You can teach theory, but we can not deny that like most of the thing coding requires a certain amount of talent and a specific mindset, and you can not each talent.
dgmib@reddit
I have been interviewing a lot of developers remotely lately. I have noticed a large uptick in developers who use an AI tool during the interview,
dgmib@reddit
to clarify, I’m talking about AI tools that use some form of speech to text to process my question through ChatGPT or similar. And are just reading back to me to ChatGPT answer
stevefuzz@reddit
I can't read or write code, but I memorized bucket sort in compsci 101.... That's your guy! Lol.
Rascal2pt0@reddit
Leetcode has entered the chat
alaksion@reddit
I tend to prefer the second profile. You don’t need the next Albert Einstein in your company, a guy with decent coding skills is easier to train than someone who can’t code but has the all the books in their heads
alanbdee@reddit
Our hiring standard is that they have to say, "I don't know" or something to that affect. We want someone who's open about not knowing something. Regardless of what your "standards" are, just rubber stamp them and get the one who can get stuff done.
stevefuzz@reddit
I love this. Information anxiety is a huge waste of time
dlevac@reddit
Trick question since it is obvious your company is not able to appraise candidates properly in the first place...
br0ast@reddit
I would take the candidate with string theory as it posits that all matter is made of strings, and coders need to use strings all the time
OnlyTwoThingsCertain@reddit
I think both are fine. People are capable of improving their shortcomings.
harman097@reddit
Maybe. Knowing theory but not being able to code smells of "I'm a bad problem solver, but I did my homework for this interview" and being a bad problem solver is not something that is easily fixed.
Give me the latter guy, every time. After some time on the job, he won't need to keep googling the stuff this guy is giving him shit for needing to google.
SleepAllTheDamnTime@reddit
I like to use this example from my former career very often. Would you rather have an officer know the theory of law but have zero actual experience before being sent out on patrol, or an officer who’s been on patrol a few years but doesn’t have a bachelors in Pre - Law?
The difference is massive and honestly life changing. Theory is just that, it’s theory and it needs application both within academia and outside of it.
While the other officer may not know case law, various precedents etc they can still learn this on the job as they will actually experience court first hand unlike the latter. Not only that but they will have interacted with the public, have a better social relationship with them etc, experience handling stressful/impossible situations.
The biggest factor between your candidates is the latter can be taught academia, while the former already has 4 years of college level coding will know theory yes but you’ll have to break them of the habits they’ve learned while in college.
It will also be harder for them to adjust to a work culture that likely doesn’t give time for “good coding practices”, along with deadlines.
Have seen this as well and actually had a “Senior” hired on my team that had theory and I did not.
Needless to say he’s no longer on my team. It became a constant battle between him and other Senior developers on architecture but he wouldn’t understand realistic application design and scaling.
It had to be done “by the book”. Meanwhile I actively learn on the job and outside of it in my own free time. I know more about enterprise application design from a massive company due to working directly in it.
I now can deduce after working on it for years what’s actually good and what’s not, but the key thing is I took the time to learn theory on my own. I’m also being vastly underpaid lol.
joaomeloplus@reddit
the ability to solve real problems without someone holding your hand and healthy cooperation in a team is the core of a dev responsibilities. reading docs and googling is so irrelevant that people should just let them do that in the interview itself.
Few_Committee_6790@reddit
You are the idiot in this equation
tr14l@reddit
Whichever one has the class eagerness and ability to grow rapidly.
The rest can be picked up.
Djelimon@reddit
Get the one with good ideas who makes things work. Errata lookups are a trivial amount of time and not a bad habit since things can change
LogicalPerformer7637@reddit
yes, the one good at coding is is a better choice. I have seen people who can memory the theory, but unable to put it in practice. on the other hand, looking up documentation, learning new things you need and using them is the path to become much better fit fast than the guy with strong theoretical knowledge who is not able to write a line of code.
Jace_r@reddit
There is a good chance it is more complicated than necessary BECAUSE of lack of theoretical basis: both worlds are needed, theoretical and practical
kondorb@reddit
In theory, there is no difference between theory and practice, but in practice, as most programmers know, there is practically no similarity between theory and practice.
grandeherisson@reddit
Came to write this. Why would you hire someone that can do the work in theory but not in practice? Words are wind.
teratron27@reddit
Yeah this is a a classic “knows the talk but can’t walk the walk” situation. I’ve interviewed loads of people who could talk their way through to the practical test rounds only to flame out, this shouldn’t be a question.
letsbreakstuff@reddit
The rest of the hiring mindset described in the post pretty much paints the picture. Someone with the clout to set hiring standards thought all the trivia they still remember from their comp sci degree from the 90s was the end all be all
Chili-Lime-Chihuahua@reddit
I’d also lean towards the latter. That person seems aware of weaknesses, almost to a fault, but they know there is a better solution and hopefully they would look it up while really working.
I’ve worked with on person like the former. They wanted to just “manage” rather than working on direct implementation. Manager/director had a conversation with him to set him straight.
Locellus@reddit
The desire for programming to be an arcane art was stupid 20 years ago. With AI it’s comically self defeating.
You don’t need to remember specific shit, you need to remember patterns and recognise when something sounds wrong and when something is going to be worth pursuing.
Who gives a flying fuckety fuck if a sorting algorithm is optimal when you’re writing Java and using a library .sort() every time…
What I care about is whether you think it’s a good idea to iterate over 1000000 records every time a process runs, when the process is going to run every 10 mins, vs using an indexed query in a DB. Or Whether you can explain why you might have issues using git for source control of a JSON file Or Whether you know when to ask for help
The fact you know exactly how the library sort is implemented is literally trivia, and only going to be relevant in a tiny % of performance scenarios.
Another thing, it honestly makes me laugh when I hear my software engineer colleagues argue about linting as if it fucking matters; being detail orientated is only good if you can distinguish relevant details from irrelevant details. This type of interview filtering is almost pointless, you’re focusing on trying to hire wizards when what you need is salt of the earth pragmatism!
_throwingit_awaaayyy@reddit
This industry is cooked chat 💀
CautiousRice@reddit
I'll take the experienced dev and ask him to improve his theory rather than hire a junior who knows everything but can't apply the knowledge but that's just me.
08148694@reddit
The former belongs in academia (which I don’t mean as an insult)
In industry knowledge is useless if you aren’t executing
failsafe-author@reddit
The latter and it isn’t even close. I’ve had plenty of guys strong on theory who wrote the most god awful things I’ve seen because they didn’t understand application. Theory is a tool to write good code, and like any tool, it has to be applied correctly.
boring_pants@reddit
I'm not sure if this is helpful to you but some of the best hires we had at my now former employer was when we prioritized attitude: is the candidate someone we'd want to work with? Are they eager to learn? We can bring them up to speed on whatever areas they're lacking in, but we can't change a poor attitude or an unwillingness to learn.
fragglet@reddit
Keep looking until you find a candidate you're actually enthusiastic about.
SpaceGerbil@reddit
Is this a troll post? If so, solid 10/10
jcradio@reddit
Both of them sound like great candidates in different ways. I often encourage my teams to allocate knowledge in two buckets, conceptual and practical. I have a few guys who lack conceptual knowledge and therefore tend to still write code like they did twenty five years ago. Others have the desire to work on new things, have conceptual knowledge, but struggle with learning an existing codebase.
I often wonder how I would fare these days, because I have probably forgotten more than what I remember these days. I just need to know the goal, timeline, codebase and tools. Seems orgs don't value us these days and have unrealistic expectations.
Consider the problem may be the org. I must always challenge myself if I'm being overly critical. It's about team dynamic. Having a mix of skills makes for a well rounded team.
TheTacoInquisition@reddit
For me it really depends on what the theory is. If they can't code neatly, but have great understanding of overall architecture and can make good abstraction at the right time, I won't care too much about the code side.
If they're a walking encyclopedia on the language, but can't create decent code, then I really don't want them.
If they can smash out code quickly, but not grasp why what they've done is going to turn into a problem as soon as we need the next change, then I don't really want them either.
I once had someone on my team who was smart, and knew a bunch of things, but had absolutely no feel for coding. They knew all the design patterns, but couldn't understand when it was appropriate to apply them or not. They knew a bunch about testing, but wrote pointless tests all the time. It wasnt fun.
LogicRaven_@reddit
I don’t think these are uniform categories. Some people are nervous during an interview and can forget basics things. Some people excel in interviews and perform lower at work.
I wouldn’t base a hiring decision on this categorisation.
catcherfox7@reddit
I spent too much time involved in recrument both as hiring manager and as interviewer, so I can confidently say that won't find the perfect candidate.
You need to have a structured process and assessment to enable you to benchmark candidates. Then you can tweak your process based on hired personal. You also need to define what type of people you are looking for and how much baby siting your organization is up for.
Without that, you're probably better off switching to hiring based on recommendations only and bringing your pals along.
simon-brunning@reddit
Might the "less practical skill" candidate merely be skilled in different technologies, a different stack? I'm usually very happy to take on someone who has good experience but needs to learn the particular tech stack they'll be working on.
ayananda@reddit
What I try to probe is really how much they are willing to learn. If they are heavily skewes in their knowledge, there might be reason ie. they do not care and that is issue. If you want to be great at theory but do not care about actual work we have issue. If you get your shit okayishly done but do not care to get better we have issue. I think both sides are okay if they are willing to do the work. If they are hungry to learn I would in theory dip to that theory guy as learning practices is easier. In practice the practical guy is more likely to willing to learn more.
UtopiaRat@reddit
Why would this not apply to both of them?
Ok_Aide140@reddit
because one is a proletar the other is bourgeoisie.
Ok_Aide140@reddit
personally, i hate the practice of coding. even more hate towards debugging.
note, i am not a programmer. however, sometimes i have to do system programming. sometimes this takes months.
i hate it.
but take python. coming from C++, i hated the whole language. Why? Because what i have seen are tremendous amounts of tutorials, videos, medium and other posts. that's crazy. it is just an interface. if you know the interface and you don't have a clear picture of the internals, you are cooked.
and my attitude changed, when i realized that what happens in the background is fuckin' sexy. said, i am not a programmer, but a mathematical physicist with a PhD. so i could see what a dynamic typing system with incorporated metalanguage means.
so yes, i hate programming. i can program fast. output is at leqst average. but i truly respect the background machinery.
what is the better initially in a junior position? know the interface, act like advanced LLM coding generator and know nothing or know the background but less effective at coding? what are the possible trajectories and learning curves for these people?
Ok_Aide140@reddit
this is a tradeoff between short term (predictable, low risk but smaller) and long term (less predictable, higher risk and higher) profit
in finance, you should perform a portfolio optimization. check it out.
Electrical-Ask847@reddit
is this in india?
eyeseemint@reddit
I could be a bit biased here as I consider myself to be the latter, but I would pick the latter over the former in most situations (except in niche cases where strong language/platform knowledge is required e.g. when picking someone to lead migration for a legacy asp.net project)
Maybe that extra attention to detail on sql query optimization techniques shaves off extra latency, but this project has deadlines and I need an "engineer" who can help design and abstract the overall system flow and bring it across the finish line - pragmatic and not necessarily a language/framework expert.
If its for junior/grad idk I suppose both traits are indicative of potential
FantasySymphony@reddit
You help the former with getting his syntax right and try to walk through the "reading code" process with him as if he had some more time and less interview pressure. You help the latter by telling him things he would be able to find in the docs. And then you try and figure out if their strengths and shortcomings are real/fatal. The real answer is "it depends."