As a hiring manager for embedded software engineers, I have a couple of thoughts that maybe helpful. I come at it from an american perspective, and I know europ is different but anyways:
1. I have to be able to read your CV. When I click on the link on github it says error, and I had dig around to figure out how to open it. When I’m scanning applicants I’d probably have just said “oh they don’t even know how to attach a pdf”. I know how cute it is, but I have to able to see your CV.
2. What do you want? Your CV is a good CV, in the sense of it lists what you’ve done. But give me a short executive summary, what do you want, what amazing thing have you done? But it’s also really long for someone with no work experience. Condense it down.
2a. Yes you might include a cover letter, but when I call you I’ll have your CV open, don’t make me hunt for it.
2b. Example: https://www.businessinsider.com/why-this-is-an-excellent-res...
3. Your FAQ, this rubs me really wrron “Writing a boot loader is REALLY HARD.” Ok I’ve writen a few, and it’s real pain in the ass, especially since you’re normally bringing up hardware while doing it that may not work. But it’s a solved problem that’s painful. Tell me you did it to learn and expand your knowledge and learn asm. That’s more impresive imho.
Keep up the good work!
You are also right on the FAQ part, this was more a learning exercise to prove if I could learn and do this more than anything, I have to update the README with further instructions and will most likely address this.
if you're interested in Polygots the POC||GTFO¹ pdf's have you covered.
Volume 0x07 is a PDF, a Zip file, a BPG (Better Portable Graphics) and an HTML file all in one.
Even crazier than pocorgtfo07.pdf, the pocorgtfo16.pdf is valid as a PDF document, a ZIP archive, and a Bash script that runs a Python webserver which hosts Kaitai Struct’s WebIDE which, allows you to view the file’s own annotated bytes. The zip archive has further resources to insane reversing deep dives, code to study and more.
For me this is art!
Include a video taken with a screen recording tool, from your host workstation, showing the thing booting in a 640x480 QEMU window. Or something similar.
> a custom bootloader created by me to impress technical recruiters
But do recruiters actually understand what a bootloader is or why this is such a feat? Do you know of a recruiter that has ran it?
Looking at the PDF spec, it says:
> The first line of a PDF file shall be a header consisting of the 5 characters %PDF– followed by a version number of the form 1.N, where N is a digit between 0 and 7.
where a line is:
> Each line shall be terminated by an end-of-line (EOL) marker, which may be a CARRIAGE RETURN (0Dh), a LINE FEED (0Ah), or both
On binary data:
> If a PDF file contains binary data, as most do (see 7.2, "Lexical Conventions"), the header line shall be immediately followed by a comment line containing at least four binary characters—that is, characters whose codes are 128 or greater
I'm sorry, but I don't think the file qualifies as a PDF if it doesn't meet these requirements. Still, it's pretty cool if this is PDF-like.
`gunzip`, `tar`, `jpg`, etc. fail when I give them things that don't have the magic header they expect. It's a good convention to use magic numbers to not misinterpret files.
Some PDF parsers expect the %PDF header at the beginning of the file, which explains why it does not display on Github.
It does work on macOS Preview though. I'm scared of opening any downloaded file, by now ;)
"There was an error opening this document. The file is damaged and could not be repaired."
when trying to open with Adobe Reader.
I have one suggestion with your readme. For someone who has used dd and is familiar with what needs to be done to check and change the value of /dev/sdX in your example before using it, this has all the information I need, and it's great that you included a "please be careful" line.
But my suggestion is you might add just one or two more lines of explanation for newbies who might wonder what part of the command they should take care with, and how to check the device name. You really do already have a lot of the necessary information here, I'm just saying that for newbies, given the high stakes of potentially destroying a disk or a system, you might add just a tiny bit more to clarify that when you say "drive" you mean the same thing as "device" and when you say "select" you don't mean select the drive in the UI such as by using the mouse, you instead mean specify the right device in the command line.
NOTE: Please be very careful with this command. If you
select the wrong drive you will lose data.
Get a USB, check the device name and do:
sudo dd if=cv.pdf of=/dev/sdX bs=512 count=2880
where X is your device.
Get a USB, check the device name (on Linux, for
example, by using sudo fdisk -l before and after
inserting the device and comparing the output to
see how the system identifies the newly plugged
in device) and do:
Edit: rereading, I also did not mean to imply the boot loader = garbage :) More that bytes that comprise a boot loader would look like garbage to the ZIP format.
But don't worry, the interviewers will still ask you to do a fizzbuzz on the board, or ask to invert a linked list
You're assuming the user has dd available. You might want to include instructions for something like Rufus if they're on Windows. Even if they have dd, you should probably add a lot more warnings with regards to its usage. One innocent typo or moment of inattention and their system is toast.
The second is just a small typo here:
>... by two means, in real hardware (I spend a lot of time making it compatible) of in an emulated environment.
And thanks for the typo, will fix :)
It might also help you figure out how to put the pdf first. You'll increase the odds of various viewers being able to render the pdf.
Congrats on a project that makes me wish I'd thought of it first.
Similarly, it's not clear what you actually did in the projects. Write it more like: "Implemented X for Y using Z" and add in some benchmarks such as "reduced overhead by 12%" or "scaled to 100,000 clients", if possible.
Recruiters don't have time to go through the process just to see your CV.
You won't impress them.
Especially not in Show HN threads:
I'm not going to go through the assembly with a fine-grained comb, but I don't need to. The existence of the final result demonstrates someone who persevered to do something novel that required more than a superficial understanding of their tools. It also lends itself to interesting questions for an interview (what was hardest, what would you change, are there other file formats that could work with this).
It's not by itself something that makes me want to hire you, but it certainly makes me want to talk to you.
Also, the resume opens as a regular PDF, so there’s no extra work to see it unless you want to try the bootloader.
Another was impressed by https://github.com/tlrobinson/evil.css/