Sure...
I conclude that they either have never been blessed with the opportunity to use proper tools, or that they think that you have to suffer for your art to be truly skilled.
I rather enjoy not suffering from repetitive stress injuries myself, so variety is good.
The main difference is really between an IDE massively focused on one language and a general purpose editor which is inevitably less integrated.
But I basically agree in that I think it basically doesn’t matter. Especially as far more time is spent reading code or thinking about it (or inserting it) than on editing operations. The only things which I think are really useful to have are jump-to-definition (and return) and fast easy to access search.
That said, even though I use vim/keyboard mainly, I still have embarrassing habits like opening a new vim for each file and cd'ing & ls'ing around to find the files.
The candidate who most impressed me this way used Visual Studio.
It would definitely seem a little odd if someone used no keyboard shortcuts at all (like, edit->copy, edit->paste), but even then I can't imagine really dinging someone for it if they get through the problem at a reasonable pace.
There’s nothing like doing so that will make you appreciate auto-indent, auto-closing braces, and efficient keyboard navigation.
Poor inference => Poor programmer
I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in.
That said, the vim guys do seem to get good work done somehow...
That's just flamebait.
I like vim and Emacs. There are good reasons to use either of them (or e.g. their bindings in "superior" tools).
Still, the quoted "must use vim/Emacs!" is just stupid. The point is that the work needs to get done.
That kind of attitude ("why aren't you using <insert personal preference bloated point-clicky IDE released 6 months ago>?") is just as obnoxious as what is in the article.
i’ve screened, interviewed and hired several engineers. the only time something related to tools like this came up was when using a specific tools was critical to the role.
It's completely random chance at this point. I have friend who solved 700-800 Leetcode questions and got offers from Google and Facebook. I recently did 100 LC questions and got destroyed in the interviews. They didn't care about communication skills, asking the right questions, etc, everyone including Google, Facebook, Netflix etc expects the correct answer at the end.
It is what it is, and I accept it. It's stupid, it's not representative of how I work, and it's completely gamed at this point, but it's how Silicon Valley is hiring. There's no use in pretending I'm better than it, so it's just plain studying and leetcoding for 2 hours a night until I get a new job.
However one down side for the companies is that candidates are more likely to shop around and might have heavily overfit their learning to those LC questions but not solving novel problems.
> "The most important capacity for Software Engineers is their ability to developer soft skills"
Maybe those will get you hired, but attention to detail helps you keep your job.
The company I'm working at right now gives out a bonus at the end of the year so long as your work "meets expectations", but they have a specific rule that if they don't like your behavior it doesn't matter how good your work is because your bonus will be set to zero. It's the "no brilliant assholes" rule.
When I started in 1997, it was a 30-60 minute walk in. Now I understand multi-day interviews are the norm. Madness.
I think a lot of it is just the glut of CS grads these days. The whole myth of a "tight market" for developers is just nonsense; companies have their pick of thousands of qualified developers these days and they can afford to pick and choose. Ultimately they are filtering for someone who can not just do the job, but jump through their hoops and be a good "culture fit".
The interview process seems to favor CS grads who memorize academic exercises and algorithms. It doesn't seem to take into account if you can actually produce a product and write maintainable code. I don't see the point as you can Google just about any solution during the work day, as needed, and real life work doesn't require you to write galaxy-scale algorithms within a 30 minute deadline.
R: Restate with sample inputs/outputs/diagrams
A: Assumptions ~ scale of inputs, uniqueness, range, variable parameters now and in the future
C: Complexity: runtime complexity, space complexity, etc
E: Edge cases
M: Maintainability
O: Overflow
O: Optimizations
R: Refactoring - DRY / SOLID / etc
E: Extensibility
S: Scalability
I use the "memory palace" heuristic to guide me through this, where each letter is a naked dude waving a flag on a racetrack I vividly remember from Gran Turismo back in the day. Absurdity helps it stick . I start every interview by writing this on the board and checking off the letters as I run through them. I usually stick another "O" in there for "Other stakeholders", depending on the gig.
This happens to work nicely when guiding/assessing interviewees through technical scenarios as well.
"The first advice is nice and simple: read my posts and watch my weekly videos." (Which he started two weeks ago.)
"Do not use the mouse! And use Vim or Emacs. Professional programmers only use keyboards and this kind of editors." (It's not 1980 any more, guys. There's been progress. The only time I use Vim is if I have to SSH into something.)
"Actually, there is less than 10% of changes to pass a technical interview, so don't set high expectations." (Does he mean "chances?")
A job interview is more like a date. It's two parties with a limited amount of time trying to gauge if they will be compatible. And, like a date, you shouldn't feel personally deficient if you end up being a poor fit. You should be aware that the other party may already have someone in the sidelines because, if you're popular, so may you. If the other party makes you jump through hoops you find silly, maybe that just means you're a bad fit, at which point you should feel confident to withdraw as an equal participant. If you pretend you're a better fit than you are, it won't work in the long run.
Crucially, you also shouldn't feel you're owed a reward just for being a good catch. If you are that good, it won't matter.
