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.
A B
C D
E F
If you ask me a question like this, I'm going to judge your company pretty harshly.
(disclaimer: all of this is notwithstanding the fact that some people's brains shut down specifically during interviews/places where they feel under pressure, which I have nothing but sympathy for. Afaik that's an unsolved problem with coding interviews. I would always try to lower their stress but it is not a sure thing.)
Having said this, I'd never hire a person that's not able to reason about this. Actually writing the implementation is really secondary
Second, part of hiring junior engineers is evaluating their growth prospects — e.g. new grads are often completely unproductive for up to a year, and firms make large investments when hiring them (maybe up to $200,000 in mentorship and wages). People with the attitude “I don’t need to learn/understand things, I can just Google them” are unlikely (IMO) to reach that level of seniority.
I've been a software developer for 10 years, and I've never worked on a problem that someone else hadn't come up with a solution for somewhere. And if they haven't, alarm bells go off as to why I'm the first to do this, and where down the pipeline did I deviate so horrifically from the norm.
Someone I worked with once went off on their own and implemented a test framework that solved a lot of the problems we've been having. They could have just written tests the normal way; they did it a different way; it was great. Someone else made a debugging tool that hooked into Python's introspection abilities and made flame graphs of the stack traces. Not exactly groundbreaking science but it was entirely "innovative" in the sense that no one expected or wanted that tool, yet it solved a real issue. Someone else made a JS library that abstracted out the problem of organizing these dynamic workflows on an internal-facing took. Small, but novel, and it organized the ideas in a way that made it possible to build on the abstractions later. For my part we had this chunk of business logic that was a pain to debug and I had the thought to factor it out into a standalone library that was completely testable at the interface. Not groundbreaking, but no one had thought to do it and it obsoleted the issues from before immediately. Etc.
If your job is anything more complicated than "feature implementation", there are chances for innovation left and right, and good engineers see and pursue them.
What percentage of engineers are working on truly hard technical problems?
I can only speak from experience but the vast majority of us are doing the same shit with a different name signing the checks.
The world doesn't need millions of brilliant engineers. It needs construction workers that can assemble materials.
I am fatigued by every tech bro in the industry that thinks they need to find the next genius with their ridiculous hiring process.
> 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?
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.
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.
I think that is what a lot of these discussions seem to be miss: the issue is not really the hard tech skills/knowledge. It is more about the softer critical thinking abilities or personalities that allow someone to become skilled at something or solve a problem easier/better.
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.
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
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
Your implementation does handle it correctly though, but it requires some care when using parser generators :)
> 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.
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.
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.
(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...)