7 things to do in 15 minutes before your remote job interview

Bruno Gelb — Thu, 28 Oct 2021 14:55:44 +0000

I often see people come unprepared in one small way or another to the Zoom / Google Meet job interviews, and that could stand in a way between them and the job opportunity of their desires. So perhaps a checklist could be of help here. Here's mine, in the order of priority:

1] visit a loo

Pretty self-descriptive action point. Take your medicine preemptively if you're not in a good health.

2] soundcheck your equipment: mic, headphones, webcam

Open the application for the upcoming call (Zoom / Google Meet / Skype / ..) and thoroughly check if your hardware is working correctly there. After that check, don't even breathe on your setup: no cable replugging, no operational system reboots, no nothing.

This action point is important enough to even ask for a reschedule if you're discovered technical issues. Don't be afraid to do that.

3] prepare a bottle of (still) water or a glass of tea

Preferably avoid anything that looks like beer or wine (kvass, vine juice) or has unobvious packaging. Don't drink alcohol (even if you're tempted to use it as a stress relief tool w/o consequences since you're remote) as you'll definitely need a clear head and a distinctive speech! Sparkling soda is suboptimal due to possible burping.

If you take some medication on a regular basis (cough medicine, antacids, ..), check your stash to be promptly available to you.

4] find a notepad and a pencil

Taking notes on a keyboard (especially on a mechanical one, but on a regular one as well) annoys most of the people: they assume you're not listening / you're distracting them. Pencil notes on the other hand are the whole different thing: they're nice and handy and you'd be able to do so much more with the paper (for instance, sketch during a brain teaser).

5] remove cats and people from the room

Tzeentch is trying to score some scratches from me as I type these strokes. But he's not welcome in the room when it's the interview time and neither do significant others and flatmates.

If what you have is only one room, try to warn the people to be quiet for a while and ask them for a favor of watching the pets. (Make some lasagna afterwards as a gratitude!)

6] have all necessary information and tools ready on your pc

Open & pin cv and a job opening description ready in the browser. Get your checklist of questions to the firm / project ready. If we're talking a programming interview, keep a console with repl ready.

7] notify the interviewer that you're ready

Join the meeting and throw a brief email / text to the person you've spoken to. Generally that's not a requirement, but it's always nice to be as transparent and proactive as possible — as Harvey Specter said, first impressions last.

Good luck!

What have I learned in a month of JavaSript development as a Python developer

Bruno Gelb — Mon, 04 Oct 2021 20:58:18 +0000

intro
js
html
css
special thx to

intro

For the last few years I was a python-terraform-ansible-gcp engineer. Regardless, my latest quest was to build a PoC (proof of concept) — and that's including UIUX part.

Considering I was super rusty with JS / HTML / CSS (last time I've touched these Pluto was still a planet and that's sayin') this was a promising challenge from the start, but I've never anticipated how much pain I'll actually find..

So I want to share some outcome thoughts with you ladies and gentlemen just to feel sane again. Oh and also to be of some help to backend developers / JS apprentices.

disclaimer: These lessons-learned are not something that should be used per se for decisions in commercial projects! I'm not a professional frontend developer!

js

as a rule of thumb always aim for the native & modern solution. Basically yeah, this is true for most languages, however JS is the place where the profits of that are super noticeable, almost palpable. Most of the time popular JS-related questions at stackoverflow usually contain 3 types of solutions: jquery, es6/es7 and the old js. You need the es6/es7 one. You'll easily spot that one since it'd be the most laconic.
const -> let -> var (for variables and functions declaration). Which means: const is the best choice, the second best thing is let, making var the worst.
template literals are literally awesome, use them everywhere to format your strings (instead of string concatenation):

let name = 'Bruno';
console.log(`Hello ${name}, sum of 2 and 3 is ${2+3}`);

// Hello Bruno, sum of 2 and 3 is 5

frameworks (react.js, vue.js) are actually hard. Even the ones that are in fact human-faced. You'd have to learn state, components, initialization, bundling, .. BEFORE anything will work for you. I have exceeded the time limit I was comfortable with to put on that and therefore had to drop vue.js.
w/o framework you don't have a way to render your templates at the browser side. Which actually leads to ugly js code. I don't think I have a proper solution for that. I just left it as an ugly js code building html pieces. It works.
beware of red-blue functions and async code. The thing is, other languages with red-blue functions (like Python) generally allow you live in a sync world by default and (whenever you ready) you are ok to start doing some async work.
This is not the case with JS. It's async by default, and (though there are decent reasons for that) it damages your learning curve badly. The code seems to be working properly but with the first user you'll start to get mandelbugs, lots of them — because your flow of execution is unpredictable, and that's because you have a terrible mess of a sync and an async code due to the inexplicit syntax.
I'm confused what advice to give here, but what helped me was to carefully check where are actually async code and what pieces / in which order call it. At the end I've started to use chained promises for the async and it worked like a charm.
please consider allocating some men-hours / women-hours in order to build & bundle your project. In my case in a temptation to cut corners during a small project I've decided to go w/o it and was punished multiple times. I couldn't use Sentry, Typescript, some of the linters, many libraries and widgets — because in modern world everyone simply assumes you're building & bundling your js, so they won't provide you with <script> way to plug-in.
typescript is an awesome way to solve a lot, but not most of the js pitfalls. Reach for it early, it's totally worth it
while I've mentioned typescript, objects comparison / checking for null|undefined|empty string are indeed a huge pain. (Yeah turns out it wasn't just a silly pub joke Python programmers tell each other.) Don't even try to guess it. stackoverflow / mozilla docs are your only friends on this damned land
definitely setup an auto-formatter (in js the go-to weapon is prettier, and the best thing is that you could use it even without CI/CD simply via pre-commit hook) and preferably also a linter (I've tried eslint, and it gave me nothing useful but a lot of false positives. Maybe the default configuration was off, no idea).
the other main danger of the js: the language silently swallows any errors and issues that'd happen during execution flow. Yes, that's exactly as bad as it sounds, because due to that fundamental design flaw you never actually know what happened and when. (Again, I know it was intentional, still it's terrible in terms of developer experience.)
I've had some success fighting this by introducing extensive logging everywhere across my code, it looks kinda like this:

function debug(msg) {
    const today = new Date();
    const time = `${today.getHours()}:${today.getMinutes()}:${today.getSeconds()}`;
    const js_module = import.meta.url.split('/').pop();
    console.log(`[${time}] [${js_module}] [DEBUG] ${msg}`);
}

function handleMyEvent(e) {
    debug(`${e.type} handler invoked`);
    // logic
}

again, ain't pretty but it works well. The import.meta.url is the chef's kiss I like: it shows you which js file actually throwed the log message.

avoid window.onload / document.onload statements: they will silently override each other if you're using them in more than one file. Prefer constructions like this instead:

function main() {
    // your logic
}
window.addEventListener('load', main, false);

avoid working with localStorage directly. It seems friendly and handy, but that's deceptive: native js localstorage can only do strings, and (for example) it will gladly and silently accept empty array from you, but it will return empty string back on that key. Use 3rd party wrappers instead (I've chosen lockr and I'm pretty happy with it) or methods of your framework (that one is preferable if you have a framework)
beware of caching: opposed to the backend world where nothing is cached untill you configure it to do so, in the frontend world EVERYTHING is cached by default. And that's not only static server, it's also cdn, local server, browser and so on. You'd have to spent a bit of time till you'll learn each layer and how to work with them. I'd emphasize on one though: caching of static files on redeploys.
beware of mutation. Luckily I havn't cached one of those issues but it looks scary enough to be aware of.
don't you ever fall into the temptation of implementing your filters like I did.
What I did was: at each user click query all checkboxes, put all the gathered states into localStorage, then just throw a window.location.reload(); and on each page load use localStorage value to render controls.
Turns out (surprise!) not only this logic is super bad for the page performance / user experience, but it's also unreliable as hell (data flow between localStorage and controls is unpredictable) and leads to the ocean of non-debuggable bugs.
Instead use CustomEvents, separate listeners and dispatchers by js modules properly ― this specifically is how I rewrote it and it worked like a charm ever since.

html

definetely start by throwing in additional meta-tag in your base template:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no, minimal-ui">

this'll allow users to somewhat decently access your site from mobile

aim really hard to NOT use <div> tag for everything. There are <section>, <a>, <main> and many others. This is the important concept called "semantic html", it's easy and it greatly helps both to read the code and to access the site (a11y).
whether possible try to link your js files as modules, not as scripts. That way you'd be able to reuse code from them:

<script type="module" src="{% static "js/sidebar.js" %}"></script>

css

always use classes, never ids. That's much more reliable and maintainable (for instance, it covers the case with multiple elements that carry the same purpose). Then you could access it with a selector like this:

document.querySelector('.toggle_button'); // for a class toggle_button

if you're assigning more than one css class to an element via literal, don't forget you have to do it in a separate class statement:

<button class="button_yellow button_toggle"></button> // correct

<button class="button_yellow" class="button_toggle"></button> // wrong

otherwise one of the two class="" instructions will silently override the other.

assign different classes with meaningful names to elements with different purposes, don't cut corners on naming in css
I've had moderate success by using either display: flex; or display: inline-block; on css rules in order to make page blocks behave, but besides that css is still some sort of weird witchcraft and deserves it's own article.
However this small educational material by Julia Evans is the best thing I could only think of on the subject.

special thx to

@twanttobealighi for css / js / html help 💛

DEV Community: Bruno Gelb

7 things to do in 15 minutes before your remote job interview

What have I learned in a month of JavaSript development as a Python developer

table of contents

intro

js

html

css

special thx to