894 karma · joined September 10, 2020
If not, what would you do? Change bank?
- people who have free time to work on side projects (usually young people have more free time than people with families)
- people who don't mind sharing their code with others
- people who work on interesting side projects. If your side project is boring, that will probably bore your interviewers -> no offer
- people who work on side projects on regular basis. If I get to work on one side project every year, well, chances are I may have forgotten the hell I did on that project (depending when the interview takes place). If I work on side projects constantly, I have no trouble picking up a fresh one to talk about
If the employer does the bg check before handing the offer, that means the candidate hasn't resigned yet from their current job. So wouldn't the bg check expose the candidate? (E.g., my boss would know I'm thinking about leaving)
I don't use my smartphone to listen to music because it's too big/heavy (running with it is so uncomfortable).
- my contract says the place of work is city X
- they don't have an office in city X
- they cannot unilaterally change the contract (Europe)
They asked me if I would be willing to relocate to a city in which they have an office. I declined. I'm still working from home. The company is big, so they don't care much about isolated cases like mine.
At interviews they stop me at my first attempt.
For me, the difference between and okay programmer and a good one is: how much Linux/Unix they know (processes, core system calls, networking, sockets, awk/sed/bash). Whether you are writing apis for ecommerce platforms or writing custom k8s providers, Linux knowledge is a must. Knowing how to implement a trie? I bet most of us have never been in that situation.
Give me any problem related to algorithms+ds to be solved in 45mins without internet access and someone looking over my shoulder and I will give you a poor solution. But give me a day and internet connection and I will solve the problem in the most efficient/readable/maintainable way possible.
Having some sort of vpc where you can safely put your db server that only listens to requests from servers within the same vpc (e.g., web server) sounds like good practice to me.
No one pays me for painting landscapes, so I work for company Paint Inc where I paint portraits. They pay good money since I'm very good at painting. I don't really like painting portraits. It's okeish. I don't hate it either. I take it as a job. No more nor less.
Now, do you wanna meet up to paint landscapes? I pay the drinks!
- tons of opportunities to improve things!
- fixing bugs is like being Sherlock Holmes. I enjoy that
- and the best is: if you need to deliver something that has a deadline and you couldn't make it, you can always blame the "poorly" written codebase