5 ms·

Imo, there are two kinds of programmers: people who can write code to build stuff, and people who can write code to build stuff and are also conversationally fl

by ajkjk 2y ago

Imo, there are two kinds of programmers: people who can write code to build stuff, and people who can write code to build stuff and are also conversationally fluent in the theory behind writing code. The second group is 5x more useful than the first, and coding interviews are testing which group you're in. Often the first group doesn't think the extra skill of fluency is important, which is fine, think what you want, but they're definitely wrong, and I wouldn't want to work with those people; when there are actual problems to solve I'm going to go looking for people in the second group to figure them out. A terrible situation is to end up with a team of entirely people who can code but can't theorize about code, because they'll build a mountain of crap that other people have to rebuild later. (Now it's true that some people can't theorize quickly, or in front of someone else, or especially in a stressful interview where there's a lot on the line. Those are real issues with the format that need solving. Not to mention the "esoteric trivia" sorts of questions which are pointless. But the basic objection that "coding tests aren't testing the skills you need in your day job" is absurd to me. They're not the skills you use everyday, they're the skills you need to be able to pull out when you need them, which backstop the work you do every day. Like your mechanic doesn't use their "theory of how engines work" every day to fix a car, but you wouldn't want a mechanic who doesn't know how an engine works working on your car for very long either...)

deleted 2y ago
[deleted]
codr7 2y ago
Agreed, but the question is how to reliably test for those skills, any freaking desperate idiot could have managed the interviews I've been through.
ricardobayes 2y ago
Most mechanics I know have long forgotten how to "connect the dots" and troubleshoot issues. Everything became computerized there and all they do is plug in a code reader. They literally don't do that "could it be spark, could it be fuel" kind of thing anymore. Most branded garages follow company instructions, "IKEA"-style, aka use a 10 socket and use it here.
- ajkjk 2y ago
  Could be! Doesn't mean those are the mechanics we want to be using though...
markus_zhang 2y ago
I think the best coding interview is to test some fundamental CS knowledge. For example: given a scanner, write a simple calculator that deals with precedence and only needs to support +-*/ It shouldn't take a huge amount of time to get a parser done, with BNF or not.
- ajkjk 2y ago
  That's okay, but it is testing what it says: facility with a particular part of CS that some people have studied and some people haven't. Can't hurt, though, and it's the sort of think that ought to be in everyone's toolbox, although it isn't.
- jakewins 2y ago
  Questions like these are hit and miss tho - I can do this because I worked in a sub-field where “write a parser for that” was a common tool to reach for. In my current field I haven’t seen a single parser in any company codebase; a dev that grew up here could be deeply skilled but have a gap around parsers..
- lucb1e 2y ago
  When starting to type this comment, I was going to write that I could not do it and I think of myself as a decent coder. While typing that, I had an idea and I started a stopwatch... Made this test set in the first minute: "1 + 1", "1 * 2", "1 + 2 * 2", "1-1", "1/2", "1+2/2" which I think should cover the requirements generally. Then I took 9m58s to come up with 77 super ugly lines that, to my surprise, after fixing that I forgot to cast the inputs to floating points (lines 67 and 76), gave the right answer straight away. Code and output: https://pastebin.com/C3RVqpjE https://pastebin.com/C3RVqpjE The correct answer would probably have imported ast but, while I know of the general existence of such tools, I never needed this in my life. It's not like I work on JSON parsers (a minefield) or wrote my own coding language. An old colleague did the latter for a commercial product by using str.split on operators (yes, strings were a major feature in the language), which went about as well as you expect... I know to stay away from these problems or, if tasked with it, where to look to solve it, but that doesn't mean I can do it in an interview. While I'm pleasantly surprised to have gotten a crude version working and in a faster time than I expected... ...if you're not hiring specifically for a parsing job, please don't use this as a coding exercise. It could be an interview question if you just want to hear "something something AST, and not by string-splitting on operators when the language has strings with said operators potentially in them". That could demonstrate knowledge sufficient such that the coder would do the right thing if this task were to come up in their job
cortesoft 2y ago
There is also a third group, who can't do well at either task.
- ajkjk 2y ago
  Oh sure but would you even want to call them "programmers" then?
joha4270 2y ago
Could you expand on what > conversationally fluent in the theory behind writing code means? It might be my insufficient command of the English language, or I might be outing myself as being outside said group, but I'm unsure what that means. Is this just referring to a vocabulary for discussing the structure and creation of software, or is there a deeper mystery I have not yet grasped?
- ajkjk 2y ago
  I mean that if someone asks you questions about code, you can respond intelligently and "think on the fly" about the subject in question. For instance you haven't just memorized something like e.g. the big-O time to access a hash table, but you have reasoning behind it: you know how it works in a few cases, your knowledge about it comes from an understanding of the implementation, and you can extrapolate that knowledge to new cases or variations of the problem, etc. Maybe your knowledge ends at some point but you could keep going if you had to: like maybe you don't know how hash tables interact with page tables or CPU caches but if that starts to matter you would be able to understand it and keep going. The same way of thinking applies to design patterns (single responsibility principle->but why, and when is it okay to break?) or to architectures (OOP / dependency management -> yes but why? can you make a version yourself? can you work around problems with it?) or to libraries (React components->what are they trying to do? how do you keep that contract simple?) or to languages (JS->what are the tradeoffs? what features do you need? how important is upgrading or polyfilling?) etc. All beyond-basic intelligence takes this form: not memorization but having a working understanding of how something operates that you can use and apply to new situations and investigate and drill into and wieldy flexible. I would call that "fluency". To be conversationally fluent in a subject is not necessarily to be an expert but to be able to "think" in terms of the concepts, and usually it means you could become an expert if the situation demanded it.
  - darkerside 2y ago
    This is much more basic than what I thought you meant. What you're outlining are critical thinking skills. And I agree, lacking them makes a programmer far less valuable. But there's a whole other level of fluency around the theory of software development, and it comes from experience with different architectural patterns, and being able to see into the different futures of each architectural pathway,and being able to converse with other people who understand software at this level. Although, calling it a level really undersells it. Multiply the potential capacity for this talent by every dimension of software building, and you start to see how people having even a little of this skill, but being able to work with others who have a bit of it in a related dimension can form a team that is more than the sum of its parts.
dakiol 2y ago
I think there’s another group: people who can come up with solid code by using search tools. I code, sure, but I will never come up with a custom solution for any non trivial problem. I know where to find appropriate solutions (the best ones) because I’m aware of what I don’t know (I read a lot of tech books). You cannot test this in the classic tech interview (because I would googling 75% of the time). The final result is: you want good code or not? How I come up with it should be secondary.
- ajkjk 2y ago
  yeah, that's wrong. I don't only want good code. I want a smart person who can write code and also do a bunch of other things, like make good decisions about code and mentor other people to write good code and fix problems before they happen and keep everything maintainable and clean. How you come up with your code per se is secondary, yes, but I'm testing for a bunch of other things that are not secondary as well.
  - realsed 2y ago
    Curious. What skills from the "return all elements from a matrix in a spiral order" make you a good mentor? Or say something about your skills keeping code clean?
    - auggierose 2y ago
      I don't know what "elements from a matrix in spiral order" is supposed to mean. If it is that for the matrix A B C D E F you are supposed to return A B D C E F, then if you cannot do this, I don't care about how clean your code is.
      - deleted 2y ago
        [deleted]
      - ikiris 2y ago
        https://leetcode.com/problems/spiral-matrix/description/ https://leetcode.com/problems/spiral-matrix/description/ If you ask me a question like this, I'm going to judge your company pretty harshly.
deleted 2y ago
[deleted]
commandersaki 2y ago
I’ve been having quite a bit of luck at these coding assessments by simply memorising solutions to leetcode problems. This feels not very different to studying braindumps to get a vendor certification.
- fullstackchris 2y ago
  And this is exactly the problem. Being a software engineer is 1000 things more than just rote memorizing some toy problem that solves exactly 1 single toy use case.
- ajkjk 2y ago
  Oh yes you'll do find with that but you'll be a bad programmer when you're done. Better to work on the art of programming, at least once you've met your immediate needs like getting a job. It will get you a lot further in the career, plus it is morally better to be good at something and contribute meaningfully compared to doing just enough for a paycheck.
  - commandersaki 2y ago
    Grinding leetcode doesn't convert you into a "good programmer", and conversely memorising leetcode solutions doesn't make you a "bad programmer". The leetcode assessments done by companies are encouraged to be gamed by the companies asking for them anyway. > It will get you a lot further in the career, plus it is morally better to be good at something and contribute meaningfully compared to doing just enough for a paycheck. I've met virtually nobody that has said leetcode has got them further in their career except for passing a gated interview. Honing your craft and being good at something has nothing to do with leetcode. To me leetcode is simply a means to get past gated interviews; if memorising solutions does the trick then I'll continue to do that. Honing my craft as a programmer and being a "good programmer" is something I work on in which leetcode bears no relevance.
fullstackchris 2y ago
I find the second group more often than not so pendantically afraid of building something even a few lines of any sort of "anti pattern" that when they meet the messy qualities of reality they fail to build anything, or at least take 20x as long as the first group.
- ajkjk 2y ago
  Eh. That's not inherent to the second group. I think that's what happens when the second group is disempowered---both by the organization and by the hellish landscape of technology they have to work with. It can be very paralyzing to try to do something right when the tools are all broken. Or maybe a good team is a mix of the two. I dunno. But I know that not having theory gets you only so far, and then everything becomes awful.
dzonga 2y ago
plenty of mechanics or other professions get by using "mechanic" or "engineering" know how vs know what that you're describing group B to be. let's look at empirical evidence: old building - do you think masons back then understood compression forces ? but those buildings still stand. what they knew was simply a matter of probability that doing a->b->c results in this predictable outcome based on what they had done or what others had done. scientism is not engineering. scientism is knowing why things work. engineering is knowing how things work or don't work.

by ajkjk 2y ago

deleted 2y ago

[deleted]

codr7 2y ago

Agreed, but the question is how to reliably test for those skills, any freaking desperate idiot could have managed the interviews I've been through.

ricardobayes 2y ago

Most mechanics I know have long forgotten how to "connect the dots" and troubleshoot issues. Everything became computerized there and all they do is plug in a code reader. They literally don't do that "could it be spark, could it be fuel" kind of thing anymore. Most branded garages follow company instructions, "IKEA"-style, aka use a 10 socket and use it here.

ajkjk 2y ago
Could be! Doesn't mean those are the mechanics we want to be using though...

markus_zhang 2y ago

I think the best coding interview is to test some fundamental CS knowledge. For example: given a scanner, write a simple calculator that deals with precedence and only needs to support +-*/ It shouldn't take a huge amount of time to get a parser done, with BNF or not.

ajkjk 2y ago
That's okay, but it is testing what it says: facility with a particular part of CS that some people have studied and some people haven't. Can't hurt, though, and it's the sort of think that ought to be in everyone's toolbox, although it isn't.
jakewins 2y ago
Questions like these are hit and miss tho - I can do this because I worked in a sub-field where “write a parser for that” was a common tool to reach for. In my current field I haven’t seen a single parser in any company codebase; a dev that grew up here could be deeply skilled but have a gap around parsers..
lucb1e 2y ago
When starting to type this comment, I was going to write that I could not do it and I think of myself as a decent coder. While typing that, I had an idea and I started a stopwatch... Made this test set in the first minute: "1 + 1", "1 * 2", "1 + 2 * 2", "1-1", "1/2", "1+2/2" which I think should cover the requirements generally. Then I took 9m58s to come up with 77 super ugly lines that, to my surprise, after fixing that I forgot to cast the inputs to floating points (lines 67 and 76), gave the right answer straight away. Code and output: https://pastebin.com/C3RVqpjE https://pastebin.com/C3RVqpjE The correct answer would probably have imported ast but, while I know of the general existence of such tools, I never needed this in my life. It's not like I work on JSON parsers (a minefield) or wrote my own coding language. An old colleague did the latter for a commercial product by using str.split on operators (yes, strings were a major feature in the language), which went about as well as you expect... I know to stay away from these problems or, if tasked with it, where to look to solve it, but that doesn't mean I can do it in an interview. While I'm pleasantly surprised to have gotten a crude version working and in a faster time than I expected... ...if you're not hiring specifically for a parsing job, please don't use this as a coding exercise. It could be an interview question if you just want to hear "something something AST, and not by string-splitting on operators when the language has strings with said operators potentially in them". That could demonstrate knowledge sufficient such that the coder would do the right thing if this task were to come up in their job

cortesoft 2y ago

There is also a third group, who can't do well at either task.

ajkjk 2y ago
Oh sure but would you even want to call them "programmers" then?

joha4270 2y ago

Could you expand on what > conversationally fluent in the theory behind writing code means? It might be my insufficient command of the English language, or I might be outing myself as being outside said group, but I'm unsure what that means. Is this just referring to a vocabulary for discussing the structure and creation of software, or is there a deeper mystery I have not yet grasped?

ajkjk 2y ago
I mean that if someone asks you questions about code, you can respond intelligently and "think on the fly" about the subject in question. For instance you haven't just memorized something like e.g. the big-O time to access a hash table, but you have reasoning behind it: you know how it works in a few cases, your knowledge about it comes from an understanding of the implementation, and you can extrapolate that knowledge to new cases or variations of the problem, etc. Maybe your knowledge ends at some point but you could keep going if you had to: like maybe you don't know how hash tables interact with page tables or CPU caches but if that starts to matter you would be able to understand it and keep going. The same way of thinking applies to design patterns (single responsibility principle->but why, and when is it okay to break?) or to architectures (OOP / dependency management -> yes but why? can you make a version yourself? can you work around problems with it?) or to libraries (React components->what are they trying to do? how do you keep that contract simple?) or to languages (JS->what are the tradeoffs? what features do you need? how important is upgrading or polyfilling?) etc. All beyond-basic intelligence takes this form: not memorization but having a working understanding of how something operates that you can use and apply to new situations and investigate and drill into and wieldy flexible. I would call that "fluency". To be conversationally fluent in a subject is not necessarily to be an expert but to be able to "think" in terms of the concepts, and usually it means you could become an expert if the situation demanded it.
- darkerside 2y ago
  This is much more basic than what I thought you meant. What you're outlining are critical thinking skills. And I agree, lacking them makes a programmer far less valuable. But there's a whole other level of fluency around the theory of software development, and it comes from experience with different architectural patterns, and being able to see into the different futures of each architectural pathway,and being able to converse with other people who understand software at this level. Although, calling it a level really undersells it. Multiply the potential capacity for this talent by every dimension of software building, and you start to see how people having even a little of this skill, but being able to work with others who have a bit of it in a related dimension can form a team that is more than the sum of its parts.

dakiol 2y ago

I think there’s another group: people who can come up with solid code by using search tools. I code, sure, but I will never come up with a custom solution for any non trivial problem. I know where to find appropriate solutions (the best ones) because I’m aware of what I don’t know (I read a lot of tech books). You cannot test this in the classic tech interview (because I would googling 75% of the time). The final result is: you want good code or not? How I come up with it should be secondary.

ajkjk 2y ago
yeah, that's wrong. I don't only want good code. I want a smart person who can write code and also do a bunch of other things, like make good decisions about code and mentor other people to write good code and fix problems before they happen and keep everything maintainable and clean. How you come up with your code per se is secondary, yes, but I'm testing for a bunch of other things that are not secondary as well.
- realsed 2y ago
  Curious. What skills from the "return all elements from a matrix in a spiral order" make you a good mentor? Or say something about your skills keeping code clean?
  - auggierose 2y ago
    I don't know what "elements from a matrix in spiral order" is supposed to mean. If it is that for the matrix A B C D E F you are supposed to return A B D C E F, then if you cannot do this, I don't care about how clean your code is.
    - deleted 2y ago
      [deleted]
    - ikiris 2y ago
      https://leetcode.com/problems/spiral-matrix/description/ https://leetcode.com/problems/spiral-matrix/description/ If you ask me a question like this, I'm going to judge your company pretty harshly.

deleted 2y ago

[deleted]

commandersaki 2y ago

I’ve been having quite a bit of luck at these coding assessments by simply memorising solutions to leetcode problems. This feels not very different to studying braindumps to get a vendor certification.

fullstackchris 2y ago
And this is exactly the problem. Being a software engineer is 1000 things more than just rote memorizing some toy problem that solves exactly 1 single toy use case.
ajkjk 2y ago
Oh yes you'll do find with that but you'll be a bad programmer when you're done. Better to work on the art of programming, at least once you've met your immediate needs like getting a job. It will get you a lot further in the career, plus it is morally better to be good at something and contribute meaningfully compared to doing just enough for a paycheck.
- commandersaki 2y ago
  Grinding leetcode doesn't convert you into a "good programmer", and conversely memorising leetcode solutions doesn't make you a "bad programmer". The leetcode assessments done by companies are encouraged to be gamed by the companies asking for them anyway. > It will get you a lot further in the career, plus it is morally better to be good at something and contribute meaningfully compared to doing just enough for a paycheck. I've met virtually nobody that has said leetcode has got them further in their career except for passing a gated interview. Honing your craft and being good at something has nothing to do with leetcode. To me leetcode is simply a means to get past gated interviews; if memorising solutions does the trick then I'll continue to do that. Honing my craft as a programmer and being a "good programmer" is something I work on in which leetcode bears no relevance.

fullstackchris 2y ago

I find the second group more often than not so pendantically afraid of building something even a few lines of any sort of "anti pattern" that when they meet the messy qualities of reality they fail to build anything, or at least take 20x as long as the first group.

ajkjk 2y ago
Eh. That's not inherent to the second group. I think that's what happens when the second group is disempowered---both by the organization and by the hellish landscape of technology they have to work with. It can be very paralyzing to try to do something right when the tools are all broken. Or maybe a good team is a mix of the two. I dunno. But I know that not having theory gets you only so far, and then everything becomes awful.

dzonga 2y ago

plenty of mechanics or other professions get by using "mechanic" or "engineering" know how vs know what that you're describing group B to be. let's look at empirical evidence: old building - do you think masons back then understood compression forces ? but those buildings still stand. what they knew was simply a matter of probability that doing a->b->c results in this predictable outcome based on what they had done or what others had done. scientism is not engineering. scientism is knowing why things work. engineering is knowing how things work or don't work.