Questions d'entretien Git Infrastructure Engineer chez GitHub

Aller au contenu Aller au pied de page

GitHub

Entretiens

Entretien pour Git Infrastructure Engineer

5 avr. 2017

Candidat à l'entretien anonyme

Recherches associées: Avis sur GitHub | Offres d’emploi chez GitHub | Salaires chez GitHub | Avantages sociaux chez GitHub

Entretiens chez GitHub Entretiens d’embauche pour Git Infrastructure Engineer chez GitHub Entretien chez GitHub

Entretien

I have posted my experience previously but I wanted to add more clarification (and interview questions) due to GitHub's official response to my last review in which they explained their rejection approach as a misinterpreted personal touch. First of all, I would like to say that GitHub's interview process is rather a *very* impressive one if implemented with strong ethics. So I will try my best to list only facts and minimize any interpretations and leave it to readers: 1. I applied using their website. 2. I received an offline coding exercise via email, in addition to some Linux procfs and other technical questions that you can answer by replying to the recruiter's email (see questions section). 2. If they like your answers, you will be given another offline coding exercise using GitHub issues, your answer should come as a "pull request" which will be discussed during an interview that they will schedule simultaneously. 3. An interview to discuss your answer to the second coding exercise (your pull request) plus behavioral questions. 4. If passed, you will be scheduled 6 interviews, two of them will be behavioral questions and "your thoughts about diversity", one will include an online coding session via screen share (not too difficult) and one will be with the skip manager, last one will be with HR. This step is typically done in headquarters (they will fly you to San Francisco) but in my case it was done via video calls. This is the final stage of their process and I was told I would hear back early next week. 5. Now here is the extremely disrespectful part, about 5 days after the interview. I followed up and informed my recruiter that GitHub is my first choice company but I have received another offer and they are pressing me to accept or reject as soon as possible and wondered if GitHub could give me their decision soon "as I'm worried about losing both opportunities", I received a very encouraging response to my email: "Hi xxx! When is a good time for us to check in today? I look forward to it! Cheers, XXX" Above is the exact response. Exclamation marks everywhere, and please underline "I look forward to it!". Imagine you receive such response to *my particular question* that I mentioned, what would you think their decision was? If you were being pressed too hard to accept your second-choice offer, would you be inclined to pass or accept it based on the response above from your first-choice company? I was very thrilled and responded almost immediately with proposed times to discuss. To my disappointment, I do not hear back for 4 hours, so I follow up again and I receive an even more excited response than last time: "Hi!!!! I will call you at 4:30pst". I get all thrilled again and I respond with confirmation! She misses her own appointment with me, frustrated again with her hot and cold responses, I politely remind her of the appointment. She completely ignores my reminder. An hour later, she finally decides to actually call me, but only to tell me they are passing. It was literally a whole day of hot and cold stalling that ended with rejection. And no, I did not perceive it a "personal call" attempt to reject me nicely after investing too much time in the interview process. I was clearly being stalled, I had spent almost 7 hours of repeated follow-ups that received very "excited!" responses before getting the official rejection result via "personal" phone call. It was already past 8pm EST when I received the "personal" rejection phone call, their first communication with me that day was at 1:24pm EST. If you like it when companies stall inexplicably, manipulate your feelings and emotions and behave suspiciously during hiring process, then definitely apply with GitHub. Otherwise, don't bother going through all the extensive interview sessions and flying to San Francisco and unnecessarily suffer the emotional roller-coaster. Also keep in mind, if this is how HR treat candidates, imagine what kind of culture they have cultivated in their company. For a company that is struggling with identity and finances, you would expect more humility and transparency.

Questions d'entretien [4]

Question 1

(Email Screening Question) Our monitoring shows that one of our fileserver machines is quickly running out of memory. A quick glance at the machine shows that the number of processes is continuously increasing -- it seems like some of the processes are getting stuck and not terminating. Answer the following questions with as much detail as you feel comfortable. Feel free to give written examples of commands to run. 1. How would you find which processes are stuck and which ones are progressing adequately? 2. How would you figure out who is spawning all these processes? 3. Once the processes and their source is understood, how would you debug the actual issue affecting them? 4. How would you mitigate the current situation in the machine to prevent it from falling over?

Répondre à cette question

Question 2

(Email Screening Question) A monitoring script, written in Ruby (MRI 2.1.7) and running in a server with Ubuntu 12.04 64bit, with kernel 3.2, periodically checks for the disk I/O of running processes using this snippet of code: def disk_stats(pid) proc_io =File.read("/proc/#{pid}/io") io =YAML.load(proc_io) [ io["read_bytes"], io["write_bytes"] - io["cancelled_write_bytes"] ] end The following exception, however, is sporadically raised from inside the method when trying to acquire the stats: Psych::SyntaxError: (<unknown>): could not find expected ':' while scanning a simple key at line 8 column 1 What do you think is going on here? Is the bug in our disk_stats function, in the YAML parser or in the kernel?

Répondre à cette question

Question 3

(Email Screening Question) The following areas map to technologies we use on a regular basis at GitHub. Experience in all of these areas is not a prerequisite for working here. We'd like to know how many of these overlap with your skill set so that we can tailor our interview questions if we move forward in the process. Please assess your experience in the following areas on a 1-5 scale, where (1) is "no knowledge or experience" and (5) is "extensive professional experience". If you're not sure, feel free to leave it blank. Just place the number next to the corresponding areas listed here: • coding o comp-sci fundamentals (data structures, big-O notation) o C or C++ programming o Go programming o git usage o git internals o shell scripting o ruby programming • troubleshooting o debuggers (gdb, lldb) o profilers (perf, oprofile, perftools, strace) o network flow (tcpdump, pcap) • large system design o unix processes and threads o sockets o signals o mysql o redis o distributed systems • operational experience o reading and debugging code you’ve never seen before o helping other engineers understand and navigate production systems o handling large scale production incidents (external communications, internal coordination)

Répondre à cette question

Question 4

(Second Email Screening Question) The git-daemon implementation that ships in Core Git has never been tuned for high concurrency situations (i.e. situations with thousands of clients performing git-daemon requests on the same machine). A particular source of concern is the way the daemon handles the children of the process. git-daemon stores the the list of live children in a linked list. New children are inserted into the list such that children with the same source address are clustered in the list, and the new child goes at the front of the cluster. As a result of this data structure, all operations regarding children management are extremely inefficient. • Can you spot and explain what are these operations, and what are their current asymptotic costs? This would be incredibly valuable information to have on the commit message for your changes. • How would you change the storage of the live children to make these operations significantly faster? • What are the new asymptotic costs of the implementation? Is it a strict improvement for all operations? Again, this would make great content for your commit messages. • Hint: Git already has a lot of generic data structures available -- you can reuse them instead of writing one from scratch. That should make the job much easier. • Bonus: Can you spot a corner case in the children handling code that would have terrible performance implications? What would be the easiest way to fix it?

Répondre à cette question

GitHub

Entretien pour Git Infrastructure Engineer

Entreprises suivies

Recherche d’emplois

Entretien pour Git Infrastructure Engineer