Having gone through Triplebyte's interview process, I'll propose another interpretation: Triplebyte's interview is on aggregate biased against Java and C# developers. I'm not accusing Triplebyte of "being biased", but rather pointing out that Java and C# tend to correlate to a skill set that Triplebyte's test process values less.
My experience of Triplebyte's interview process is slanted towards frontend/backend developers of web apps. Fortunately for me, that was my background. However, in the team I currently work with, the team is in aggregate heavily C# with only secondary experience in web frontend/backend development. That's because their expertise is in low level security. Several developers on this team are exceptions to the "don't roll your own cryptography" adage.
They're all competent developers, but the version of Triplebyte's coding test that I took (and passed) would be in unfamiliar territory for people in this team. That's fine since most of Triplebyte's clients are probably looking for web frontend/backend skills, but I think this means that Triplebyte's test shouldn't be seen as an objective measure of programmer skill, just an objective measure of fit for Triplebyte's clients.
That was annoying me the entire time I was reading this, the entire article has an unspoken assumption that their interview process couldn't possibly be responsible for any discrepancy in the data.
I recall reading something to the effect that the most competent developers by Triplebyte's metrics used vim and Ruby on a Mac. That sounded too much like the typical hipster startup dev to be a coincidence, which got me wondering: is that really a snapshot of the best developers out there, or is it just what Triplebyte, hence their clients, are selecting for?
Well, what they hiring for, their questions in a specific language, how and who is evaluating the answers, the fact that a person is looking to work for them vs other companies are all biases. Nobody should try to extrapolate their results to the whole population of software engineers.
That said, Visual Studio is really on the rise. I used to think VSCode was late and could have never catch up with the Sublime's and Atom's ecosystem. So after trying it, I went back to my editor of choice. Lately though I went back to VSCode and I think it is pretty good out of the box and very good when you install the right plugins.
I don't know if this counts, but it might, me and several friends and people I know who have all been doing Java for 10-15 years... are all writing typescript now. And using VSCode to do so.
There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me.
In my life:
- I'm committed to emacs for org-mode and LaTeX editing and daily use.
- I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging.
> This is a fantastic demonstration of why i exclusively use git from a command prompt...
Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you source control info inline are fantastic.)
Along with some nice features I've added, such as my 'git af' (add + fzf) shortcut[1][2], the commandline is very usable (don't have to 'git add' and type filenames manually).
> Engineers who use Go are also especially strong. If you know why, please let me know.
Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake.
It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interest to spend time learning something unnecessary.
It's a good text editor, first and foremost. Compared to netbeans, eclipse, visual studio, even intellj idea in my opinion. The same thing that made textmate, then sublime text successful made VSC successful. I takes a few seconds to launch, even on my celeron machine with 2Gigs of RAM, it's relatively minimal and unlike intellj it doesn't appear to be analyzing my whole hard drive for hours for no reason...
the irony is that Microsoft did hire Eclipse creator to work on that product... hopefully it doesn't end up bloated. Having an open spec for language servers is also a smart move. While others have their proprietary, often non speced protocol, now any text editor can implement the same protocol and basically use any language server already developed.
So kudos for Microsoft, it's a great piece of engineering.
VSCode is fast and it's certainly the best editor/IDE I've used since back when I was a Java dev using Eclipse back in 2006 or so.
But I recently opened up Sublime Text to compare some editor behaviour, and the difference in UI performance is astounding.
It's possible that VSCode has regressed a bit the last couple of years. It was always faster than Atom. But comparing it to Sublime shows that there are clear advantages to writing UI code in a natively compiled language. Sublime's widget drawing seems very well optimized.
VSCode has also become slower for me the last few years, simply from the load of extensions. I use the ESLint extension and the Go extension heavily, both of which parse code a lot. Neither is doing any sort of incremental parsing, so there's potentially a lot of churn. There's also some kind of indexing of symbols that happens in the background in the language server or in the extension. I sometimes have to kill the "Code Helper" process because it's sitting there consuming a whole core when idle.
Overall, VSCode is becoming increasingly closer to how I remember Atom, when I used it. I worry that it's slowly turning into Atom, performance-wise.
I could not agree more. I've made numerous attempts to embrace the new hotness that is VSCode but I just cannot get over the performance. Yes, it has some cool features, the plug-in ecosystem is booming, and it sure looks pretty. But at the end of the day none of it is compelling enough for me to put up with the constant lag.
It's funny because after several of these experiments I have literally wondered to myself if I'm getting stuck in my ways or becoming a so-called "greybeard" due to my long term adherence to Sublime Text, but is constantly getting annoyed with how slow an editor is really a hallmark of old age? I'll wait for your web page to load, I'll wait for an ssh command to return. I will not wait for my bloody text editor. I have no patience whatsoever. Now god damn it NOW!
Another thing I wonder is how many of those VSCode users have simply never used anything better. If all you've ever known is an iPhone 5, you probably think it's pretty great - maybe you think that's just how phones are! This impression will be totally ruined of course when you try an iPhone X...
I love VSCode and have moved to it from Sublime; mostly same shortcuts by default, inline debugging, extension ecosystem and blistering pace of development.
It's fast enough but Sublime blows it out of the water - especially for things to "Go To Symbol" where it works almost instantly whereas I'm constantly waiting for VSCode to stop spinning and give up and cmd-f search instead.
Also, I have to work with a lot of network-user-login RHEL6 boxes, and VSCode doesn't work on desktops that old.
It seems strange to me to compare VSCode against PyCharm, IntelliJ, and Android Studio separately.
While PyCharm, IntelliJ, and Android Studio are distinct applications, I believe they share much of their code, UI, 3rd party plugins, and workflows for all being JetBrains language-flavored IDEs.
On the other hand, VSCode supports different languages through its extensions instead of having separate language-flavored applications like "VSCode Python", "VSCode Java", or "VSCode Android".
So I feel that reaching for IntelliJ vs. PyCharm vs. Android Studio is roughly equivalent to installing a particular set of extensions in VSCode. If you look at it that way, the data from the article seems to tell a different story - while VSCode has grown significantly in popularity, JetBrains IDEs seem to dominate in terms of overall usage (11.3% + 6.9% + 4.1% = 22.3% vs. VSCode's 16.8%).
VSCode is fast, stable, and the plugin ecosystem really beats Sublime Text at this point. I was skeptical because Microsoft but it is hands down my favorite editor.
Like it was said in this thread, as long as you have an editor that is built on something js-related like electron or node-js, it just cannot beat alternatives that are made in C++.
I've tried VSCode because I wanted to have UI breakpoints with GDB, I admit that vscode seems better than atom, but for performance I have my doubts.
I really don't understand why engineers choose to use JS to made a text editor. I know that js and the dom have enabled the web, but it's because there was nothing better, choosing js to do non-web stuff doesn't only sound silly, IT IS silly.
Everyone is on the argument that because you use C++ you'll always be faster.
I disagree, you get fast by using good datastructures and algorithms. Yes, for the same algorithm C++ may have some perf gains but it's so easy to shoot yourself in the foot. Visual Studio itself is written in Visual C++. It's slow and a memory hog.
Most folks who are not familar with JS don't understand the internals of V8. V8 does amazing things to compile the JS down to really fast bytecode. It builds hidden classes and structs just the way you'd write C++ and them compile them to machine code. There are many instances where the C++ code won't be much faster than the JS. In some cases naive C++ is even slower.
As for VSCode, it's a testament to show you can build very usable things by using the web as a platform. Chromium's blink's engine is fast if you know what you're doing.
Sublime is great, don't get me wrong, but VSCode's extension architecture gives it a leg up. It's so much easier to write a vscode extension than a sublime extension. Typescript gives the JS world a lot of sanity.
> I really don't understand why engineers choose to use JS to made a text editor.
Not to sound snarky or anything, but because of their sheer numbers the argument is that it makes them a lot closer to the infinite amount of monkeys with an infinite amount of typewriters.
>I really don't understand why engineers choose to use JS to made a text editor.
-Much more beautiful and customizable UIs compared to native applications
-Easier cross platform development with Electron
Do you think it's a coincidence that some of the most used and loved desktop applications lately are written in JS/HTML? import_pkt_ws_btc_deribit_v2.py Could it be that it's extremely hard to do these kind of applications in traditional GUI frameworks?
One of my favorite things about VS Code is how usable it is with its default configuration, and how easy it is to customize to my liking. I found Atom and Sublime Text very frustrating in that regard.
Yep. I really like Sublime, and I probably still would be using it. I had it all set up to sync settings between my devices, with a nice theme, some handy plugins, and excellent syntax highlighters. But at some point I had both a new personal laptop and a new work computer. I had it on the back of my mind that I need to sort out my Sublime configuration again on both of these (which at the time included that weird dance to install Package Control). But then I already had VSCode working pretty well out of the box (including a perfectly good colour scheme), so my motivation to sort out Sublime became less and less until suddenly I was happy just using VSCode.
VS Code solves different problems then IntelliJ, PyCharm and Atom. I'm not sure this is a fair comparison. For example, I wouldn't ever code a full Java stack in VS Code. I'd go straight to IntelliJ.
Frankly, I think we're seeing the results of the new era of Python paradox. Except it's not Python 3, it's TypeScript, VS Code, and React.
If you look at the education space, many of the deployments are either Chromebooks or iPads. Back in 2012, the "learn to code" sites (like Khan Academy or Code.org) ended up building their lesson plans around JavaScript.
People who were in 3rd- and 4th-grade in 2012 would now be finishing up high school. Someone in 7th- or 8th- grade would have just finished a bachelor's, or maybe be looking for their second job after two or three years in the industry.
For these folks, TypeScript/VS Code/React would be a short jump from these learn-to-code-JavaScript-in-the-browser sandboxes.
As for Go... I suspect that's the set of people who can handle Google-scale software complexity. So either former Google employees, or people who are in the kubernetes ecosystem.
The "live shared coding" angle in VSCode makes it a great option in many areas where there's a need for it. People have been asking jetbrains for this for a decade, and there's nothing on the horizon as far as I can tell.
Ok I stopped reading when they started drawing graphs how well the people using certain editors fared better in their test as if the editor could have anything to do with it.
I've told you guys before - my 10 year old son scored 'well above average' on their interview process. We live in the UK but they are still trying to recruit him. And no - he cannot write code.
My son has seen this post and points out that he not only uses unreal engine - to my complete surprise (and not just a little delight) - he has deployed some c++. I sent him to bed because it's late. Dad;s will know why.
Another interesting angle on this is that VS Code is free (and open source), while Sublime is proprietary and (nominally) costs $80. I wonder how many people don't use Sublime because of the price? Atom is free too and never surpassed Sublime.
I've been almost exclusively an Emacs user since the turn of the millennium or so, even before I was a full-time professional programmer. I briefly tried out TextMate years ago, and I've tried out VS Code, but I stick to Emacs for day-to-day work, and the keybindings are pretty much hard-wired into me at this point.
At the same time, I hate and actively avoid typical tech interview processes, and I suspect my pass rate if I did a bunch of them would start out low and only grow after a while once I got used to "interview coding" (which is basically a separate skill from actual programming).
So I don't know why they see this effect. My first guess would be that it's a kind of survivorship bias; outside of the occasional splash of someone trendy inspiring some new users, using the classic Unix-y editors seems to correlate with older/more experienced programmers. Who, because they've managed to stick around as long as they have, probably can manage to get hired when they want or need to.
> However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why.
Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
I have a theory on this. For most interview style coding problems (which tend to be algorithmic in nature), scripting languages such as python or ruby:
1) are less verbose
2) don't require worrying about typing
3) have really easy ways to manipulate strings, iterate, etc., which are often found in interview style problems
Java and C# have many advantages over python and ruby, but I think that they put you at an inherent disadvantage for many interview style questions which often require you to solve an algorithmic or data structure type problem in a limited amount of time [1].
[1] This doesn't explain why people using Go would tend to pass at higher rates, but since the Go community is comparatively much smaller, there could be other factors at play there.
> > However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why.
> Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
> Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
Something I've noticed over time is that a good chunk of the people not too enthusiastic about their work tend to gravitate towards the enterprisey stuff like java, C# or VB while the more enthusiastic may end up in embedded, research or low level code like the guts of an OS or database.
I suspect it's because most Java and C# engineers are "enterprise" engineers who work on mostly CRUD applications. Go and Ruby would be more aligned for a startup. Given that TripleByte's interview process is more technical and computer science oriented, I'm not surprised they score less. It's mainly about the types of problems you solve at work and how well you keep technical knowledge fresh.
I think the author is saying they have no idea why C# and Java devs are worse on average than Ruby and Go devs. I'm sure they know the specific reason those devs fail, but are trying to understand the more general trends that lead to higher rates of failure. I would guess that this is another instance of the python paradox (http://www.paulgraham.com/pypar.html).
It's because the process is CS heavy. Slinging business logic together while mapping it through some ORM to satisfy the latest priority shift this sprint is what the average C# and Java engineer excels at. It's more craftsmanship and less computer science.
[+] [-] munchbunny|7 years ago|reply
My experience of Triplebyte's interview process is slanted towards frontend/backend developers of web apps. Fortunately for me, that was my background. However, in the team I currently work with, the team is in aggregate heavily C# with only secondary experience in web frontend/backend development. That's because their expertise is in low level security. Several developers on this team are exceptions to the "don't roll your own cryptography" adage.
They're all competent developers, but the version of Triplebyte's coding test that I took (and passed) would be in unfamiliar territory for people in this team. That's fine since most of Triplebyte's clients are probably looking for web frontend/backend skills, but I think this means that Triplebyte's test shouldn't be seen as an objective measure of programmer skill, just an objective measure of fit for Triplebyte's clients.
[+] [-] drewrv|7 years ago|reply
[+] [-] bitwize|7 years ago|reply
[+] [-] ChrisCinelli|7 years ago|reply
That said, Visual Studio is really on the rise. I used to think VSCode was late and could have never catch up with the Sublime's and Atom's ecosystem. So after trying it, I went back to my editor of choice. Lately though I went back to VSCode and I think it is pretty good out of the box and very good when you install the right plugins.
[+] [-] coding123|7 years ago|reply
[+] [-] xapata|7 years ago|reply
[+] [-] ww520|7 years ago|reply
[+] [-] hprotagonist|7 years ago|reply
In my life:
- I'm committed to emacs for org-mode and LaTeX editing and daily use.
- I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging.
- I write serious python code in pycharm.
- I write serious c# in full blown Visual Studio
[+] [-] kbd|7 years ago|reply
Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you source control info inline are fantastic.)
Along with some nice features I've added, such as my 'git af' (add + fzf) shortcut[1][2], the commandline is very usable (don't have to 'git add' and type filenames manually).
[1] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...
[2] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...
[+] [-] ddavis|7 years ago|reply
[+] [-] Zaheer|7 years ago|reply
[+] [-] johngalt|7 years ago|reply
Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake.
It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interest to spend time learning something unnecessary.
[+] [-] interesthrow2|7 years ago|reply
the irony is that Microsoft did hire Eclipse creator to work on that product... hopefully it doesn't end up bloated. Having an open spec for language servers is also a smart move. While others have their proprietary, often non speced protocol, now any text editor can implement the same protocol and basically use any language server already developed.
So kudos for Microsoft, it's a great piece of engineering.
[+] [-] atombender|7 years ago|reply
But I recently opened up Sublime Text to compare some editor behaviour, and the difference in UI performance is astounding.
It's possible that VSCode has regressed a bit the last couple of years. It was always faster than Atom. But comparing it to Sublime shows that there are clear advantages to writing UI code in a natively compiled language. Sublime's widget drawing seems very well optimized.
VSCode has also become slower for me the last few years, simply from the load of extensions. I use the ESLint extension and the Go extension heavily, both of which parse code a lot. Neither is doing any sort of incremental parsing, so there's potentially a lot of churn. There's also some kind of indexing of symbols that happens in the background in the language server or in the extension. I sometimes have to kill the "Code Helper" process because it's sitting there consuming a whole core when idle.
Overall, VSCode is becoming increasingly closer to how I remember Atom, when I used it. I worry that it's slowly turning into Atom, performance-wise.
[+] [-] sho|7 years ago|reply
I could not agree more. I've made numerous attempts to embrace the new hotness that is VSCode but I just cannot get over the performance. Yes, it has some cool features, the plug-in ecosystem is booming, and it sure looks pretty. But at the end of the day none of it is compelling enough for me to put up with the constant lag.
It's funny because after several of these experiments I have literally wondered to myself if I'm getting stuck in my ways or becoming a so-called "greybeard" due to my long term adherence to Sublime Text, but is constantly getting annoyed with how slow an editor is really a hallmark of old age? I'll wait for your web page to load, I'll wait for an ssh command to return. I will not wait for my bloody text editor. I have no patience whatsoever. Now god damn it NOW!
Another thing I wonder is how many of those VSCode users have simply never used anything better. If all you've ever known is an iPhone 5, you probably think it's pretty great - maybe you think that's just how phones are! This impression will be totally ruined of course when you try an iPhone X...
[+] [-] misnome|7 years ago|reply
It's fast enough but Sublime blows it out of the water - especially for things to "Go To Symbol" where it works almost instantly whereas I'm constantly waiting for VSCode to stop spinning and give up and cmd-f search instead.
Also, I have to work with a lot of network-user-login RHEL6 boxes, and VSCode doesn't work on desktops that old.
[+] [-] kcon|7 years ago|reply
On the other hand, VSCode supports different languages through its extensions instead of having separate language-flavored applications like "VSCode Python", "VSCode Java", or "VSCode Android".
So I feel that reaching for IntelliJ vs. PyCharm vs. Android Studio is roughly equivalent to installing a particular set of extensions in VSCode. If you look at it that way, the data from the article seems to tell a different story - while VSCode has grown significantly in popularity, JetBrains IDEs seem to dominate in terms of overall usage (11.3% + 6.9% + 4.1% = 22.3% vs. VSCode's 16.8%).
[+] [-] sbilstein|7 years ago|reply
[+] [-] jokoon|7 years ago|reply
I've tried VSCode because I wanted to have UI breakpoints with GDB, I admit that vscode seems better than atom, but for performance I have my doubts.
I really don't understand why engineers choose to use JS to made a text editor. I know that js and the dom have enabled the web, but it's because there was nothing better, choosing js to do non-web stuff doesn't only sound silly, IT IS silly.
[+] [-] nojvek|7 years ago|reply
I disagree, you get fast by using good datastructures and algorithms. Yes, for the same algorithm C++ may have some perf gains but it's so easy to shoot yourself in the foot. Visual Studio itself is written in Visual C++. It's slow and a memory hog.
Most folks who are not familar with JS don't understand the internals of V8. V8 does amazing things to compile the JS down to really fast bytecode. It builds hidden classes and structs just the way you'd write C++ and them compile them to machine code. There are many instances where the C++ code won't be much faster than the JS. In some cases naive C++ is even slower.
As for VSCode, it's a testament to show you can build very usable things by using the web as a platform. Chromium's blink's engine is fast if you know what you're doing.
Sublime is great, don't get me wrong, but VSCode's extension architecture gives it a leg up. It's so much easier to write a vscode extension than a sublime extension. Typescript gives the JS world a lot of sanity.
[+] [-] Shorel|7 years ago|reply
Not to sound snarky or anything, but because of their sheer numbers the argument is that it makes them a lot closer to the infinite amount of monkeys with an infinite amount of typewriters.
[+] [-] bishala|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
[+] [-] 21|7 years ago|reply
[+] [-] 33degrees|7 years ago|reply
[+] [-] dylan-m|7 years ago|reply
[+] [-] davidwparker|7 years ago|reply
That said, I've been on VS Code for a little more than a year now and it's grown on me.
[+] [-] brokenwren|7 years ago|reply
[+] [-] cbhl|7 years ago|reply
If you look at the education space, many of the deployments are either Chromebooks or iPads. Back in 2012, the "learn to code" sites (like Khan Academy or Code.org) ended up building their lesson plans around JavaScript.
https://johnresig.com/blog/introducing-khan-cs/
People who were in 3rd- and 4th-grade in 2012 would now be finishing up high school. Someone in 7th- or 8th- grade would have just finished a bachelor's, or maybe be looking for their second job after two or three years in the industry.
For these folks, TypeScript/VS Code/React would be a short jump from these learn-to-code-JavaScript-in-the-browser sandboxes.
As for Go... I suspect that's the set of people who can handle Google-scale software complexity. So either former Google employees, or people who are in the kubernetes ecosystem.
[+] [-] lowercased|7 years ago|reply
[+] [-] kyberias|7 years ago|reply
[+] [-] talltimtom|7 years ago|reply
[+] [-] zygotic12|7 years ago|reply
[+] [-] zygotic12|7 years ago|reply
[+] [-] Double_a_92|7 years ago|reply
[+] [-] indemnity|7 years ago|reply
But I use VS Code, it really is a great little editor with a good ecosystem.
The JavaScript support pulled me in, but it's a pretty decent Rust environment now as well!
[+] [-] ammon|7 years ago|reply
[+] [-] NotANaN|7 years ago|reply
I think the Interview Pass Rates chart makes it clear that the answer is a statistical "Yes", at least for Emacs.
[+] [-] ubernostrum|7 years ago|reply
At the same time, I hate and actively avoid typical tech interview processes, and I suspect my pass rate if I did a bunch of them would start out low and only grow after a while once I got used to "interview coding" (which is basically a separate skill from actual programming).
So I don't know why they see this effect. My first guess would be that it's a kind of survivorship bias; outside of the occasional splash of someone trendy inspiring some new users, using the classic Unix-y editors seems to correlate with older/more experienced programmers. Who, because they've managed to stick around as long as they have, probably can manage to get hired when they want or need to.
[+] [-] emacsuserrrr|7 years ago|reply
[+] [-] shmulkey18|7 years ago|reply
[+] [-] lowercased|7 years ago|reply
Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
[+] [-] chadash|7 years ago|reply
1) are less verbose
2) don't require worrying about typing
3) have really easy ways to manipulate strings, iterate, etc., which are often found in interview style problems
Java and C# have many advantages over python and ruby, but I think that they put you at an inherent disadvantage for many interview style questions which often require you to solve an algorithmic or data structure type problem in a limited amount of time [1].
[1] This doesn't explain why people using Go would tend to pass at higher rates, but since the Go community is comparatively much smaller, there could be other factors at play there.
[+] [-] fredsanford|7 years ago|reply
> Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
> Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
Something I've noticed over time is that a good chunk of the people not too enthusiastic about their work tend to gravitate towards the enterprisey stuff like java, C# or VB while the more enthusiastic may end up in embedded, research or low level code like the guts of an OS or database.
I wonder ....
[+] [-] Delmania|7 years ago|reply
[+] [-] nepeckman|7 years ago|reply
[+] [-] snarfy|7 years ago|reply
[+] [-] halfnhalf|7 years ago|reply
[+] [-] avip|7 years ago|reply