4 ms·
All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are
by externalreality 8y ago
All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. "Can you show you know sufficient SQL? Did you write applications before using Rails/Django what have you? Distributed this, Web that - OK, jobs is yours." After all that the productivity of the programmer is solely based on the work environment and how motivated you can keep a developer who is becoming depressingly convinced that his calling in life is to write web handlers and optimize queries to a bloated database schema and watch the guy whose been on the job too long walk around like he's some fusion of John Carmack and Elon Musk.
Why these interview processes act as if candidates are going to be designing graphics engines from scratch for graphics hardware extracted fr om a downed alien spacecraftis beyond me. We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions and used every new OOD technique in the books when a handful few procedural functions would have sufficed.
- quickthrower2 8y agoMan, you are singing on my frequency. I’ve worked with too many John Musks. And I’ve seen too many full table scans and null reference exceptions :-(
- shapiro92 8y ago> All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. this is exactly the company/boss i would not want to work for. It is exactly the opposite. You should not care if the person if familiar with the tech you use. Who cares if you do php or c#? Does it REALLY make any difference when it comes to taking the business logic and adapting it into MVC/API?
- LandR 8y agoYes. Because if they don't have a deepish understand of the language and framework IME they tend to write crap code. If someone is being hired to write C# /.NET all day every day I don't want to have to spend time teaching them C# or .NET Especially not how to write good C# / .NET.
- metric10 8y agoWasn't part of the point of C#'s syntax was that it was easy for C++ and Java programmers to learn? Would any real C# advocate really tell me it would take months of manager supervised learning to pickup? I've been writing code for a long time in many languages and I do my best to write "good" code. The principles that make code "good" in one language appear to apply equally to other languages...
- emilecantin 8y agoThere _are_ differences in good code between language. For exmaple, I've recently worked with a very good Java dev who wrote some code for a React frontend. While his code was very good, it definitely had that "java" feel to it, and I actually fixed a few bugs by removing some of it, mostly around state vs props synchronization.
- externalreality 8y agoI would argue that what makes code "good" is completely subjective which is why I don't spend too much time thinking about it. The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples. There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".
- caseymarquis 8y agoWhile it might not always be a huge leap between languages, I think it would be a bit more work to explain something like this to a PHP user: "We used reflection to modify the expression tree Entity Framework generated from this SQLFunctions.DateDiff call to allow dynamic ranges to be used. This has saved us thousands of lines of boilerplate code, but it should only be used in non-critical locations, like reports, as it depends on the internal implementation of the expression tree using a list, which is not guaranteed under any circumstances, but very unlikely to change." I'm sure there are similar situations going from .NET to PHP. I think they would understand the implications, but I'm not sure they would be able to quickly fix it if the expression tree implementation changed and they had to determine which implementation was being used with reflection. That said, I would hire the PHP/Ruby programmer who didn't run screaming at the use of reflection and monkey patching over a .NET/Java developer with no interest in all the neat things their language of choice can do to eliminate massive amounts of boilerplate code.
- thesz 8y agoNo, they are not. The things programmers do are not mundane. The word you are missing from your description is "effects". The parts of program or system interacts with each other not only by passing and returning values, but also by effects. It is good if your effects are isolated in SQL with ACID, but oftentimes they are not. The interaction is often subtle when resource in conflicting usage is shared indirectly (systems programming, come here!). And in the end of the day you are more Sherlok than you could imagine you ever would. I am here not to say that interview questions are perfect. I am here to say that things that programmers do are not mundane (or they would be automated out quite quickly).
- jimbokun 8y ago"I am here to say that things that programmers do are not mundane (or they would be automated out quite quickly)." And they have been automated out, and so we are all working to solve other things now, which will then be automated, leaving us to solve other things...until the Singularity.
- tdumitrescu 8y ago> We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions My preferred coding interview approach is indeed to let the candidate interact with a correct but poorly-written piece of code and refactor it into something more maintainable. I find that reading and working with other people's code is a hugely important part of the job on a modern dev team, but rarely is that part of the evaluation.