61–70 of 198 posts
Being an Emacs enthusiast myself, it always surprises me how much more popular VIM is. Is this because VIM is taught more in schools? Maybe because VI/VIM is typically installed by default on Linux systems?
Emacs has terrible key bindings, it’s as simple as that. No one wants to press a chord of keys to do simple tasks.
> And new generations are opting for YouTube to self-teach over books I'm definitely in the older generation because it's completely mind-boggling to me how someone effectively learns to code from watching a video tutorial. You can't flip back to a page, bookmark a link, copy text, zoom-in to see exactly what was done, etc. It feels like you're inherently missing out on so much you gain from a book or a text-filled w…
Earlier quoted context omitted.
That one stat made me question the entire survey. There's no way so many people use VIM over Atom, Sublime, etc. Right? Someone reassure me here.
I've recently been having issues with Sublime randomly freezing and restarting (may be due to a package, but I'm not going to waste my time verifying what packages are misbehaving out of the hundreds I have installed), I've gone back to Vim. After setting Vim up for multiple environments (PHP, Go, Python, and JavaScript) it's now my daily driver. Maybe other people feel similar?
Welcome to vim, but if you go overboard on plugins then you will have the same issues with it, probably more so.
> What’s the biggest challenge when hiring talent? "Hard to assess skills before onsite" -- That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to. Not to mention the actual book I co-wrote.
I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a tool. As far as I'm concerned all it does is exacerbate the already terrible hiring practices and hiring biases that plague the software industry. I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by…
Earlier quoted context omitted.
I can think of a dozen reasons for that, but here are a few of the most salient ones; 1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight…
> It might not give you a very good insight in to an applicant. I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it. > Most people's public code is of roughly equal quality (eg 'not great'). I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fa…
The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help.
Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?
> What’s the biggest challenge when hiring talent? "Hard to assess skills before onsite" -- That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to. Not to mention the actual book I co-wrote.
I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a tool. As far as I'm concerned all it does is exacerbate the already terrible hiring practices and hiring biases that plague the software industry. I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by…
This is the absolutely best skills test I've seen so far. More companies need to try it out.
One of the biggest benefits is that it removes the adversarial relationship of a normal whiteboard interview. That kind of adversarial relationship almost never happens day to day (and if it does something is very wrong).
There’s no way that many people use VIM.
Hold up. They asked “Vim or Emacs?”, not “What’s your favorite editor?” That’s why the answer distribution looks like that. I think we all know there are more normal text editor/IDE users than vi/emacs users.
> The biggest gap in knowledge is with JavaScript frameworks > Most often, employers want developers who know AngularJS, Node.js, and React. Am I overthinking this? When I've been looking for jobs, I've found the emphasis on JavaScript frameworks slightly perplexing and frustrating. I would assume that a competent web developer should be capable of quickly learning a framework. Having to know JavaScript, CSS, etc. to…
Right, they don't want to have to pay you to do the learning. It's usually not "how to get a simple task done with React" – many engineers can get there very quickly – but rather having an understanding of best-practices in terms of architecting your application. Angular, well, can take a while to learn how to use properly.
Perhaps I'm being too pedantic here, but the UI library used has very little to do with how you architect an application. Knowing how to write half decent sql or not reinvent your own message queue is far more important than whatever is happening on the front end, but you don't see the focus on them like you do with the latest javascript library.
> What’s the biggest challenge when hiring talent? "Hard to assess skills before onsite" -- That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to. Not to mention the actual book I co-wrote.
I was thinking, since public repositories or open source contributions are the new "mandatory". If you want to see me coding, just request a new feature to one of my public repositories on github. These coding assignment you sent by email? I don't even bother to read them, in fact I store them scrupulously together with your email - once you might be looking for a job and I will be the one doing hiring.