I always left it open-ended and that seemed to work. Part of the interview was seeing what they’d come up with. I’m pretty sure people always brought things they’d already written.
Instructor, author, developer. Creator of Beej’s Guides.
openpgp4fpr:CD99029AAD50ED6AD2023932A165F24CF846C3C8
I always left it open-ended and that seemed to work. Part of the interview was seeing what they’d come up with. I’m pretty sure people always brought things they’d already written.
It never happened–since they knew in advance, they had time to whip up something cool if there wasn’t anything else. It didn’t have to be massive. I just wanted to see some clean non-trivial code and a clear understanding of how it worked. Fizzbuzz wouldn’t have impressed. :)
One of my classmates years ago loved bash. They wrote a filesystem for their OS class in Bash. It was a really, really impressive and bad idea.
But how do you handle candidates who say something like “look, there’s heaps of code that I’m proud of and would love to walk you through, but it’s all work I’ve done for past companies and don’t have access (or the legal right) to show you?”
It never once happened. They always knew in advance, so they could code something up if they felt like it.
I asked candidates to bring me some code they were proud of and teach me how it worked. Weeded out people really quickly and brought quality candidates to the top. On two separate occasions we hired devs with zero experience in the language or framework and they rocked it. Trythat with your coding interview, eh? 🙂
The old C++ FAQ book was over 500 pages, and that was decades ago. Those were the “frequent” questions.
I drove deep into C, a much simpler language, and there’s all kinds of wild stuff in there that most C devs don’t know. Of course, it’s not applicable to 99.9999% of C programming, so who practically cares, but to learn 100% of C++? I don’t have that kind of time.
That said, it’s totally possible to learn enough C++ that covers 99.9999% of its use cases.
Another approach to thinking about it is that draw()
does two things. 1) it draws the line that’s 1
shorter than itself, then 2) it draws itself.
The for
loop happens after it draws the line that’s 1
shorter than itself.
They most definitely do.
I don’t think it’s bad–it’s impossible to make error-free material, and it’s more error-free than not, for sure.
But other people are right: you’ll “graduate” to MDN and not look at W3 Schools again.
You can absolutely write a Star Wars knockoff, though. You just can’t call it that. There’s some gray line in there somewhere.
You can start collecting at 62 and get 70% of your computed payout, which I will be doing.
The math is too hard for me given inflation and all that, but since social security rarely seems to have enough money, I’d guess they’re still paying out more than they take in…?
A shell script can be more concise if you’re doing a lot of shell things. Keeps you from having os.system()
all over the place.
Things like “diff the output of two programs” are just more complex in other languages.
I love rust, but replacing my shell scripts with rust is not something I would consider doing any more than I’d consider replacing rust with my shell scripts.
“The expert has failed more times than the beginner has even tried.” 😊👍
So the page says:
And this does in fact happen - even though some of your data was still waiting to be sent, or had been sent but not acknowledged: the kernel can close the whole connection.
But Stevens says:
By default,
close
returns immediately, but if there is any data still remaining in the socket send buffer, the system will try to deliver the data to the peer.The
SO_LINGER
socket option lets us change this default.
And, referring to the default close
behavior:
We assume that when the client’s data arrives, the server is temporarily busy, so the data is added to the socket receive buffer by its TCP. Similarly, the next segment, the client’s FIN, is also added to the socket receive buffer (in whatever manner the implementation records that a FIN has been received on the connection). But by default, the client’s
close
returns immediately. As we show in this scenario, the client’s close can return before the server reads the remaining data in its socket receive buffer. Therefore, it is possible for the server host to crash before the server application reads this remaining data, and the client application will never know.
Also:
If
l_onoff
is nonzero andl_linger
is zero, TCP aborts the connection when it is closed. That is, TCP discards any data still remaining in the socket send buffer and sends an RST to the peer, not the normal four-packet connection termination sequence.
I’m having trouble reconciling this with the article’s position that data will be discarded by the sender OS with a plain non-SO_LINGER
close()
.
I can see how the sender might be blissfully unaware that the receiver program might have crashed after the data had been sent and the connection had been closed, but before the data had arrived at the receiver program. And that’s where some kind of application ACKing mechanism might be in order.
I can also see that the receiver OS might happily collect the data and shutdown the socket correctly and then the sender app thinks everything is fine, but the receiver app has crashed and will never see the data.
But neither of those conditions result in the receiver app in the example showing less than 1,000,000 bytes received unless there’s an error.
What am I missing?
I’m a gray developer and nothing makes me more get-off-my-lawn than too many levels of abstractions. :)
I hypothesize the failure of AI in this arena will be due to the fact that English is a shit programming language. It can take many times the amount of English to be precise compared to the equivalent computer code.
What’s the backup login mechanism when you lose your biometric sensor? How do you pair with the new sensor?
Every time I find a site like this, I assume the programming is bad and the security is poor. (They don’t know how to sanitize input? They don’t know how to hash passwords?) It’s a good reason to use random passwords on every site for when that one is compromised.
Just run it through OCR. Super efficient! 😅
“Every dependency is an asset. Every dependency is a liability.”