At a high-level, we need to understand two points:
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.
• 45-minute systems interview, focus on responding to real world problems with an unhealthy service, such as a web server or database. The interview will start off at a high level troubleshooting a likely scenario, dig deeper to find the cause and some possible solutions for it. The goal is to probe your knowledge of systems at scale and under load, so keep in mind the challenges of the Facebook environment.
• Focus on things such as tooling, memory management and unix process lifecycle.
More specifically, linux troubleshooting and debugging. Understanding things like memory, io, cpu, shell, memory etc. would be pretty helpful. Knowing how to actually write a unix shell would also be a good idea. What tools might you use to debug something? On another note, this interview will likely push your boundaries of what you know (and how to implement it).
Interview is all about taking an ambiguous question of how you might build a system and letting
So HAProxy is primalery a load balancer an proxy for TCP and HTTP. But it may act as a traffic regulator. It may also be used as a protection against DDoS and service abuse, by maintening a wide variety of statistics (IP, URL, cookie) and when abuse is happening, action as denying, redirecting to other backend may undertaken ([haproxy ddos config], [haproxy ddos])
| package main | |
| import ( | |
| "bufio" | |
| "flag" | |
| "fmt" | |
| "io" | |
| "os" | |
| "path/filepath" | |
| "regexp" |
tmux new - Create and attach to a new session.tmux new -s NAME_HERE - Create and attach to a new session named NAME_HERE.CTRL-b, d - Detach (i.e. exit) from the currently-opened tmux session (alternatively, tmux detach). Note, this means press and hold CTRL, press b, release both, press d.tmux ls - Show list of tmux sessions.tmux a - Attach to the previously-opened tmux session.tmux a -t NAME_HERE - Attach to the tmux session named NAME_HERE.CTRL-d - Delete (i.e. kill) currently-opened tmux session (alternatively tmux kill-session).CTRL-b, [ - Enter copy mode, and enable scrolling in currently-opened tmux session. Press q to exit.CTRL-b, " - Split window horizontally (i.e. split and add a pane below).| const nsq = require('nsq') | |
| const crypto = require('crypto') | |
| module.exports = async (req, res) => { | |
| async validarAuth(req.header.authentication) | |
| // Depois de validar iniciar a escuta em uma fila única para essa request | |
| const replyQueue = crypto.randomBytes(30).toString('hex') | |
| nsq.on(replyQueue, data => { | |
| res.json(data) |
