471–480 of 565 posts
Have this subordinate and the candidate participate in a staring contest. This will show a couple of things about the candidate: A) How well they maintain eye contact (very important for communication) and B) How long it takes them to back down from a challenge; this taps into their primal instincts.
Earlier quoted context omitted.
You do you. I can't see how your approach can scale to hire tens or maybe hundreds of engineers. Sounds like something that may somewhat work for you when you're the only one doing the hiring for your small team of buddies at a startup somewhere. You're not even trying to tackle things like hiring for multiple roles, interview fairness, subconscious bias, technical diversity, feedback, or making the interview process…
If you need hundreds of engineers to solve a related set of business problems[1], I wager you've done something wrong. [1] and if these problems are unrelated (think Uber's human driver app vs self driving), then why are candidates passing through the same committee?
Mature products require competence in areas such as security, architecture, compliance, devops, research and much more. Hiring has to reflect that and account for it.
It's silly and immature to suggest a 90-minute chat about some crap your candidate will bring with them is somehow the answer here (and claiming that if they don't have anything to bring with them, then chances are that they're worthless anyways and you shouldn't waste your time on them). Especially without backing this up with any meaningful data (ie. attrition, number of people hired, actual impact on business, feedback received, etc).
Earlier quoted context omitted.
I'm personally a fan of small, clean commits, rebasing without squashing before merge, always making a merge commit, and writing a clear, through merge commit explaining what the branch does. That way, I can treat the series of merge commits to trunk as the simple, linear overview of history, but when I'm bug-hunting I get small, clear commits to search through with git bisect. It also means I get more useful blame o…
Do you ensure your clean commits all pass all CI tests?
• All commits SHOULD pass all CI tests
• Merge commits MUST pass all CI tests
The reason I don't require every commit to pass all tests is to maximize reviewability and logical consistency of commits.
For example, if a file needs to move, and then be modified slightly to function in its new location, I prefer to break that into two commits:
1. A verbatim move operation. This commit will fail CI but can be effortlessly reviewed.
2. Small modifications. This commit will pass CI, and its reviewability is proportional to its size.
In contrast, if you smush those two commits together, it can be hard to see where the meaningful changes occur in one giant diff. (Some tools may be smarter about showing a minimal diff for a move-and-modify commit under limited circumstances, but that doesn't always work.)
Earlier quoted context omitted.
I apologise if I left you with that one when I left my first job in 2003! :)
When I joined in 2006, someone had replaced it with 21 regular expressions.
shudders
Intuitively I'd expect that not to make much difference since most mainstream languages are pretty similar, and the interview wasn't syntax oriented. But that's not what I experienced. Signal to noise ratio was there and definitely affected speed of processing the code.
(To answer my own question, for coding interview style algorithmic questions, it should be easy for the company to translate the questions to the applicant's preferred language before the interview. (if not then it's probably not a good interview question). Hopefully this company does that.)
Obviously if the company explicitly wants the candidate to be familiar with deep aspects of whatever language you use, then this doesn't matter. I can imagine hypothetical cases where this would hold, but I'd think it relatively rare.
Earlier quoted context omitted.
Gitflow, and its various flavours, has been a popular alternative. Though it seems trunk-based is considered the preferred standard due to emphasis on achieving a stable main branch, simplified pipelines and faster cycle times. This requires a bit more maturity to get right if I'm not mistaken as you need good automation, test coverage and code review practices.
I've never heard of Gitflow or anything. I've been doing this stuff for almost a decade and trunk based with short lived development branches is all I've ever seen. Bizarre.
When hiring developers, fetch a stoic subordinate who is A) good at eye contact and B) able to maintain said eye contact without blinking. Have this subordinate and the candidate participate in a staring contest. This will show a couple of things about the candidate: A) How well they maintain eye contact (very important for communication) and B) How long it takes them to back down from a challenge; this taps into the…
In my company we go one step further: We encourage the candidates to „bring their own code“. Then we let them explain their code, discuss possible issues, extensions and so on. Usually simply from looking at the code style one can infer a lot about the candidates level of skills. Also the candidates are less nervous and are sometimes really enthusiastic explaining their favorite side project. All in all it leads to a…
How does this work if they only have coded as part of jobs? Do you assume everyone is working on some side project or open source?
When hiring developers, fetch a stoic subordinate who is A) good at eye contact and B) able to maintain said eye contact without blinking. Have this subordinate and the candidate participate in a staring contest. This will show a couple of things about the candidate: A) How well they maintain eye contact (very important for communication) and B) How long it takes them to back down from a challenge; this taps into the…
Earlier quoted context omitted.
That's right ! Great answer. malloc() is a very old API. A more modern version would probably looks like: err_code malloc(size_t size, void **returned_ptr); The current malloc() overloads the return to say NULL == no memory available/internal malloc fail for some reason and as far as the standard goes, allowing NULL return if size==0. So if you get NULL back from malloc, did it really mean no memory/malloc fail, or z…
Except that I left out a "should". While it would be good if malloc(0) always returned a pointer, you can't rely on malloc(0) returning NULL just for errors. There's not even a guarantee that malloc(0) does the same thing every time. Note that "returning a pointer to the byte after the internal malloc header" means that malloc(0) == malloc(0), breaking the unique pointer guarantee unless malloc(0) actually causes an…
malloc(0) != malloc(0) because the internal malloc header is different for each allocation.
Asking for a malloc of size n, means internally the malloc library allocates n + h, where h is the internal malloc header size. So there is always an allocation being done for at least a size of h, just with an internal bookkeeping "size" field set to zero.
and yes, while(1) malloc(0); will eventually run out of memory, counter-intuitively :-).