A long time ago I came up with an acronym that's served me well as a consultant who has to bounce from one customer to the next and run through interview gauntlets of all types: RACEMOORES:
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.
Also remember that many great opportunities will not have as their only states litmus test the usage of VIM. Not even most people that prefer that environment would use it as a litmus.
I read a theory that says that these impossible interviews were designed so that companies can say they couldn't find any qualified stateside candidates so that they could get more H1B visas. It just kinda caught on because everyone wants to imitate FAANG.
When I started in 1997, it was a 30-60 minute walk in. Now I understand multi-day interviews are the norm. Madness.
>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".
It's not a myth, most of the so called qualified devs on the market are terrible programmers. Companies do not have their pick, about 1 in 20 are worth hiring; most absolutely suck and can crank out extremely shitty code, but don't much understand what they're doing.
Rank and file engineers give interviews and participate in debriefs. If the interview process were subverted for H1B candidates, you can bet they would be screaming about it.
Where does this kind of nonsense attitude come from? I use GUI editors, use the mouse, don’t use magic keyboard shortcuts, and I manage to produce software like everyone else.
The speed of operating your tools definitely has an impact on your development velocity. Invisible interruptions like switching from keyboard to mouse add up.
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.
I guess it depends a lot on the sort of programming that you're doing. But there's still a lot of activity around the challenging bits that don't require a lot of thinking. Things like organizational/cleanup, some types of refactoring and testing, dealing with git and other commands.
>My bottleneck is nearly always thinking time. Typing time is irrelevant.
I don't agree. Code is communication. Imagine you had to sound out every letter of every word while speaking - it wouldn't just be slower, you'd lose your place or simply not bother saying certain things.
It depends on the type of work you're doing. I've been using vim for many years and I am frequently limited by my typing speed when it comes to some things like scripts.
When it comes to work that doesn't require deep thought, it matters. I'm much more likely to achieve a task that someone else might dismiss "because it requires too much typing."
It also helps a lot with refactoring, which is mostly a mechanical process. I'm much more willing to do large refactoring than some others due to the fact that I'm very good with my editor.
Point is that you're right, but you're also describing a subset of problems which require deep thought, and not fully considering the benefits that might be had from the alternative.
Indeed. Probably like, what, 10-20% of our time? Maybe 25%-30% on a good week?
I'll even argue the opposite: there are many ways to write code slowly that yield better results.
- sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie.
- pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
> - sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie.
This is precisely why I never learned to type faster. The time between my thinking and typing is spent auditing my thinking.
> - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
Ehhh. A lot of programming is creative and imposing my creativity onto someone else (or having someone's styles/preferences imposed upon me) usually doesn't help much. Any time I've pair-programmed (~6 years of professional programming) my productivity dives down to 1/3 while my quality sometimes increases marginally. It's a low ROI in my experience which is why I'll never advocate for it. But I'll play ball if the org I'm working for embraces it. There are social/team-building/ other nontechnical benefits to consider as well (although I'd argue that tasks built specifically for these purposes would be more efficient).
“The time between my thinking and typing is spent auditing my thinking”
Apparently this isn't limited to code for you, what an eloquent way to put it. I'm definitely stealing this, thanks! ;)
“creative”
I hear you loud and clear, I tend to be the same. But pair-programming has its uses, imho, which become more obvious as a lead tbh. One fundamental premise for me: voluntary participation only, it's usually bad to force it on people.
Briefly and imho, there are two kinds: "true pair" as equals (or close enough), and "asymmetric" (more like mentor-mentee). Let's tackle the latter first:
- To onboard a new team member, it's invaluable in helping them build confidence fast, learn the codebase, and integrate the team's standards and "best practice" — more to-the-point and pleasant than reading a bunch of docs: have a co-worker tell it to you, like it is, on-the-fly and on a need-to basis. Saves loads of time searching in the dark. Typically short-term (first few weeks).
- Transfer: it dramatically raises the operational level of the mentee. It effectively 'multiplies' the mentor's superiority, 'spreads it' throughout the team so to speak, as other people pick up the good stuff directly from the mouth of the lion(s).
This can be long term, depends on who you've got. I love when juniors are free to pair-prog with a willing senior, you get them out of the green zone in months as opposed to a year or more.
The benefit compounds over time, if you're building a team, it's really second-to-none (no bootcamp, no code review, no nothing comes even close). You do 'lose' one member for some time, few hours per week, but it's often a welcome walk in the park for the senior, and a really good time for the junior. It's everything you can never get in school, because it's ad hoc training both for the job and the company/team's culture/standards.
Now for pair-prog 'as equals'. Again, as a free association between two people who choose each other.
The idea here is that in terms of human brain you've got twice the 'RAM' (attention, memory, etc) and twice the 'CPU' (raw 'intelligence'). So it works ideally like a distributed system (not a failover/HA!) where each person focuses on different aspects. There is typically not much room for 'style' or 'creativity' insofar as it's decided before we write, through discussion. When one writes, the other should not interject for small details like “why not inlining here? why this name and not that name?” unless it's not just preference but mistakes or architecture etc (“did you know you could avoid all that and just write <some idiomatic thing>?” — or “this is correct but here's how we'd rather write it: ..., because it's more readable / idiomatic”)
The point is to share the thought process, and then have one set of eyes writing while the other thinks. It's thinking even slower, using two brains if you will, not at the same level — one, writing, is bound to think 'closer' to the code, while the other, watching, is free to roam-think around, look up some other file, specs, etc. Even write docs as we go, which may save time later (there is no 'rule', I only care for what actually works in practice and everyone's different so...) E.g. I don't like pattern-shoving but finding one is a common 'eureka' by the observer.
(I'd typically want a common 'pair' machine + both bring their own laptop, if doing this in person, so that each is free to do stuff. Sometimes we just off the pair prog to go faster (when human goes monkey because we have to).
What I find is that:
- explaining my 'plan' before anything is written helps make it clearer, and spot mistakes early on.
- others generally have half the good ideas seen in ...
I am absolutely in love with this response. Thank you for taking time to produce this. This could be a blog post.
Your post has me looking back at the opt-in samples of my experience and realizing that when they were opt-in, I never considered them to be "pair programming". It's always just been "healthy onboarding" or "healthy collaboration". My current org's obsession with enforcing PP for its own sake as a measured performance metric has conditioned me to squirm when I hear the term, but that's just a branding/emotional response problem. Thank you for the beautifully articulated check.
Oooh! Can I copy the body of your comment into a post on my little project and credit you with a link back to this thread?! It should be seen and discussed by more people! I can do the same as a reddit post if you'd like, too.
If you wanted to set up a little blog beforehand in case people want to follow you, I can wait. whistles
You absolutely can! Credit all you want, I'm fine either way (although validation of ideas through HN could give more weight to your post indeed).
As for the blog, I'd rather do it once and for all (I have a cleaner / LTS mindset), so that will require a little planning (e.g. domain and URLs, as I hate dead links with a passion). I just don't have the time now, hopefully before year's end. So don't wait on me!
And thank you so much for the interest. It may be pride but I'm very grateful. Have a great one!
I suppose you can always copy out your best or longest comments and post them as blog posts as is, and then later go back and update them appropriately. For any comments that overlap, just throw them all together into a single "blog post".
I know it’s a bit against the spirit of this thread, but at the risk of not being taken seriously.
If you’d like to do that a little faster, you can use `fd` piped into `fzf` as a fuzzy file finder. Once it’s set up properly you’ll never go back! NERDTree might also be helpful.
IME, Vim is mostly nice because of the satisfaction derived from these incremental improvements.
Meh, I spend a lot more time thinking than I do typing. I do prefer Vim keystrokes, but my editor these days is VS Code with vim keystroke extension installed.
I tend to see this attitude most from people that insist on using a tiny under-specced laptop, rather than a desktop with multiple screens and a proper desk.
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.
“You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.”
To be fair, emacs is a gui program with real mouse support and images and menus and buttons. But it doesn’t really do popups and most people hide the menu bar and toolbar.
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.
Lol this was so out-of-place given that most of the other advice was pretty reasonable.
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.
This reminds me of one of the worst things about interviews I’ve had (with big companies and small): typing code into a shared Google doc for phone screens.
There’s nothing like doing so that will make you appreciate auto-indent, auto-closing braces, and efficient keyboard navigation.
The kernel of truth in this is: have mastery of your tools. All else being equal, someone in a Vulcan mind meld with their editor comes across as more impressive than someone tripping over it.
The candidate who most impressed me this way used Visual Studio.
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.
Personally, I'm biased against people who use 40 year old editors written for a completely different world, when we have modern and far superior tools.
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...
> I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in.
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 agree. One of the best coders I ever met had only used Visual Studio for the past 20 years. He knew the guts of Windows and X86 hardware unlike anyone else I've ever met and he is SORELY missed (retired last year) where I work even we've mostly moved over to Linux based apps. He was also pretty decent at the Linux kernel, but still edited code in his beloved Visual Studio even then :) . So no, vim and emacs do not make you a great programmer.
I can confirm that soft skills are highly valued and useful on the job as well. They are the #1 criteria at most tech companies I've worked at. I'm highly regarded as awesome technically but I've lost jobs based on my poor soft skills alone.
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.
I got the most out of mock interviews: friends, colleagues, and when I ran out of people sites like PracticeCodingInterview.com, Gianlo.co, and Pramp.com. Just having a stranger judging me helped me up my game.
I don't like the terminology 'fail'. It implies a mental model like an examination, where there's a clear link from effort, to performance, to reward.
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.
Hard to take advice from an article with a ton of typos.
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.
I think the author is just not a native English speaker. The typos seem pretty consistent (eg the author thinks chance is spelled change) and there are some grammar errors and unidiomatic phrases but I don’t think it’s particularly difficult to read or that the errors should imply the article is bad. My guess is that the article is a translation to English of an article in Spanish for Spanish-speakers (eg it talks about “international” startups)
You're right. I'm not a native English speaker. That's why I speak in Spanish in my videos. I wrote the article too quickly (which indeed is a summary of the video) and the grammar corrector wasn't very smart with the "changes" things. Thanks for pointing out the typos.
The reason why good programmers also fail technical interviews is because the algorithmic/coding questions are mostly random. You can be asked any of over 1000 distinct questions, and if you haven't seen it before, almost no company will "reward" you by figuring it out on the spot. Instead they will compare you to another candidate that studied that question and gave a solution in the allotted time.
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.
With that said, there are lots of people that get offers like that without doing 800. (Most people I know have done like < 50 and some claim to have never done any!). I did ~240 and I still struggled when I did new grad interviews. Feels like an IQ test to me quite honestly.
That it's not a given that you did 240 questions was a guarantee for you to pass these interviews. 1. Natural aptitude often separates people 2. There maybe people who are just good at DS and Algo or have done competitive programming that they don't need these questions.
Either way it's not as straight forward as doing X or Y and getting in at Google FB is guaranteed.
One thing not many people realize is that this filters good candidates so they comply better with company culture (follow rules) and how determined they are.
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.
Most of the interview problems can be solved easily in the allotted time without having seen the problem before. Developers just have a very highly inflated opinion of their own intelligence. If they can’t solve a problem that MUST mean no one else possibly can and the question must be intrinsically unfair.
Algorithmics took many years to evolve in to the discipline it is now. If every question can be solved by intelligent people in 45m, why did it take this long for the discipline to evolve?
A quick glance through their comment history indicates to me that the person you're responding to is not someone who works directly with code, and thus has no first-hand experience with the process under discussion in this thread.
Or you could get a job in a place that isn’t a dystopian hellhole. The country is pretty big, you don’t actually have to work in California. Other places don’t do this.
Exactly, I've called out a fellow coder on these lame-ass questions before. My technical questions are things we are doing, how do you approach a big software problem, and some fundamental language questions. My co-worker always pulls out these lame zinger questions like google and she and I always give different appraisals almost every time of interviewees. Too many time someone has answered her "zinger" but hadn't the slightly clues about the fundamentals of programming or what we are currently coding for.
Yea, early on in my career (right out of college) I interviewed at google and got stumped on a couple zingers, one I remember was not being able to identify all the use cases of the virtual keyword in C++. By no means did I put myself out as a C++ expert at the time. But getting turned down from Google probably turned out to be the best thing that happened to me.
The technical interviews I enjoy the most are where I write a small piece of software beforehand and we discuss the code during the technical interview. It gives me a better idea on what to prepare for because most questions are going to be about your technical decisions and ways to improve the solution. The downside is that doing a project for every job is a lot of work.
I'm starting to think the best way to prepare is to pay a coach to train you up and give feedback. The interviews dont have much to do with reality, if you want to be good at leetcode style whiteboarding you need to get advice from someone who knows how it works on the inside. (yeah I'm bitter)
"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?")
Best interview is the 3 week probation period, prev job and ask general questions on what you did that only someone who actually did that role would know.
“don’t use a mouse” ... but true, I usually add some "fun" points into my videos and I tried to write it down (which is hard). Thanks for your comment.
Hired many, realised as long as they can do basic coding, I am not bothered about them solving complex problems. I need to identify their team and people skills first.
82 comments
[ 4.8 ms ] story [ 147 ms ] threadR: 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.
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".
Sure...
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.
And we’re not typing programs in from magazines like in the 80s here. My bottleneck is nearly always thinking time. Typing time is irrelevant.
I don't agree. Code is communication. Imagine you had to sound out every letter of every word while speaking - it wouldn't just be slower, you'd lose your place or simply not bother saying certain things.
When it comes to work that doesn't require deep thought, it matters. I'm much more likely to achieve a task that someone else might dismiss "because it requires too much typing."
It also helps a lot with refactoring, which is mostly a mechanical process. I'm much more willing to do large refactoring than some others due to the fact that I'm very good with my editor.
Point is that you're right, but you're also describing a subset of problems which require deep thought, and not fully considering the benefits that might be had from the alternative.
I'll even argue the opposite: there are many ways to write code slowly that yield better results.
- sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie.
- pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
This is precisely why I never learned to type faster. The time between my thinking and typing is spent auditing my thinking.
> - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
Ehhh. A lot of programming is creative and imposing my creativity onto someone else (or having someone's styles/preferences imposed upon me) usually doesn't help much. Any time I've pair-programmed (~6 years of professional programming) my productivity dives down to 1/3 while my quality sometimes increases marginally. It's a low ROI in my experience which is why I'll never advocate for it. But I'll play ball if the org I'm working for embraces it. There are social/team-building/ other nontechnical benefits to consider as well (although I'd argue that tasks built specifically for these purposes would be more efficient).
Apparently this isn't limited to code for you, what an eloquent way to put it. I'm definitely stealing this, thanks! ;)
“creative”
I hear you loud and clear, I tend to be the same. But pair-programming has its uses, imho, which become more obvious as a lead tbh. One fundamental premise for me: voluntary participation only, it's usually bad to force it on people.
Briefly and imho, there are two kinds: "true pair" as equals (or close enough), and "asymmetric" (more like mentor-mentee). Let's tackle the latter first:
- To onboard a new team member, it's invaluable in helping them build confidence fast, learn the codebase, and integrate the team's standards and "best practice" — more to-the-point and pleasant than reading a bunch of docs: have a co-worker tell it to you, like it is, on-the-fly and on a need-to basis. Saves loads of time searching in the dark. Typically short-term (first few weeks).
- Transfer: it dramatically raises the operational level of the mentee. It effectively 'multiplies' the mentor's superiority, 'spreads it' throughout the team so to speak, as other people pick up the good stuff directly from the mouth of the lion(s).
This can be long term, depends on who you've got. I love when juniors are free to pair-prog with a willing senior, you get them out of the green zone in months as opposed to a year or more.
The benefit compounds over time, if you're building a team, it's really second-to-none (no bootcamp, no code review, no nothing comes even close). You do 'lose' one member for some time, few hours per week, but it's often a welcome walk in the park for the senior, and a really good time for the junior. It's everything you can never get in school, because it's ad hoc training both for the job and the company/team's culture/standards.
Now for pair-prog 'as equals'. Again, as a free association between two people who choose each other.
The idea here is that in terms of human brain you've got twice the 'RAM' (attention, memory, etc) and twice the 'CPU' (raw 'intelligence'). So it works ideally like a distributed system (not a failover/HA!) where each person focuses on different aspects. There is typically not much room for 'style' or 'creativity' insofar as it's decided before we write, through discussion. When one writes, the other should not interject for small details like “why not inlining here? why this name and not that name?” unless it's not just preference but mistakes or architecture etc (“did you know you could avoid all that and just write <some idiomatic thing>?” — or “this is correct but here's how we'd rather write it: ..., because it's more readable / idiomatic”)
The point is to share the thought process, and then have one set of eyes writing while the other thinks. It's thinking even slower, using two brains if you will, not at the same level — one, writing, is bound to think 'closer' to the code, while the other, watching, is free to roam-think around, look up some other file, specs, etc. Even write docs as we go, which may save time later (there is no 'rule', I only care for what actually works in practice and everyone's different so...) E.g. I don't like pattern-shoving but finding one is a common 'eureka' by the observer.
(I'd typically want a common 'pair' machine + both bring their own laptop, if doing this in person, so that each is free to do stuff. Sometimes we just off the pair prog to go faster (when human goes monkey because we have to).
What I find is that:
- explaining my 'plan' before anything is written helps make it clearer, and spot mistakes early on.
- others generally have half the good ideas seen in ...
Your post has me looking back at the opt-in samples of my experience and realizing that when they were opt-in, I never considered them to be "pair programming". It's always just been "healthy onboarding" or "healthy collaboration". My current org's obsession with enforcing PP for its own sake as a measured performance metric has conditioned me to squirm when I hear the term, but that's just a branding/emotional response problem. Thank you for the beautifully articulated check.
That's just bad, imho, I would have the same response.
And thanks a lot for the kind words, much appreciated!
“This could be a blog post.”
You can't imagine how many times I thought this too, and yet here I am 10-15 years later still writing comments... Ha, it's never too late I guess.
If you wanted to set up a little blog beforehand in case people want to follow you, I can wait. whistles
As for the blog, I'd rather do it once and for all (I have a cleaner / LTS mindset), so that will require a little planning (e.g. domain and URLs, as I hate dead links with a passion). I just don't have the time now, hopefully before year's end. So don't wait on me!
And thank you so much for the interest. It may be pride but I'm very grateful. Have a great one!
If you’d like to do that a little faster, you can use `fd` piped into `fzf` as a fuzzy file finder. Once it’s set up properly you’ll never go back! NERDTree might also be helpful.
IME, Vim is mostly nice because of the satisfaction derived from these incremental improvements.
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.
“You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.”
- Miyamoto Musashi
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.
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.
The candidate who most impressed me this way used Visual Studio.
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.
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 wish people hated me for what I actually say, not what they imagine my attitude is :)
Poor inference => Poor programmer
> "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.
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.
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.
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.
Either way it's not as straight forward as doing X or Y and getting in at Google FB is guaranteed.
Just to confirm that is what you’re trying to say, right? Genuinely would love to understand this POV.
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 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?")