HNHacker News
TopNewBestAskShowJobs

marcgg

163 karma · joined February 29, 2012

Talk to me on Twitter (@marcgg) or take a look at my website (marcgg.com)
submissionscomments
marcgg··on Ask HN: Who is hiring? (October 2017)
I'm sorry to hear that. This is of course not normal, could you please let me know where you sent it? We look at all applicants' tests sent via our job page, and if yours got lost then it's an error that I'd be happy to fix.

Mail: marc at drivy dot com

marcgg··on Is Amazon down
We saw some issues that seemed like a possible aws outage, but can't really confirm it
marcgg··on The Tech Recruitment Process at Drivy
As I mentioned in the article, we don't expect the code presented to be "perfect" code. If you've managed to get a side project running very quickly thanks to tradeoffs you've made, it's also interesting. It's really just a way to have a place to discuss choices.
marcgg··on The Tech Recruitment Process at Drivy
I completely agree, this was just an example of a common complain.
marcgg··on The Tech Recruitment Process at Drivy
Yes it's true that it doesn't fit all use cases. However I would see looking at a few of the fixes you're talking about as an interesting technical interview.
marcgg··on The Tech Recruitment Process at Drivy
From experience we saw that for most people doing the coding test was only taking ~an evening which seems reasonable as it removes the need for more on site discussions.

I guess that it's true that the take home assignment is not optimal if you interviews with more than 10 companies and in this case we must be loosing some candidates.

marcgg··on The Tech Recruitment Process at Drivy
Sometimes we do discuss this code if the candidate prefers. But it's still a somewhat "fake" code made for the only purpose to apply at the company. Most people would find it more interesting to discuss code they spent weeks on.

Finally we are not looking for any specific profile, but so far almost every person found a piece of code to share from their career. We don't get thousands of applicants, so maybe we're not seeing the issue just yet. If it turns out to be a problem, we'll change the process :)

marcgg··on The Tech Recruitment Process at Drivy
I never said our interview process was perfect, I mainly wanted to share it because I saw a lot of people complaining about whiteboard coding and so on... so I figured it could be interesting to some to see a less exhausting alternative.
marcgg··on The Tech Recruitment Process at Drivy
Thanks! So far it's been also very interesting on our end to discuss "real life" problems
marcgg··on The Tech Recruitment Process at Drivy
We accept any kind of code, be it a kata made during a workshop or a side project... really we just want to talk about code that the candidate wrote previously. It doesn't need to be large to have interesting tradeoffs made
marcgg··on The Tech Recruitment Process at Drivy
If you sum it all up, it is less than a day. The phone screening is ~20 minutes, the assignment takes a couple of hours and so on.

I think it's fair to expect that a candidate is willing to invest at least 5-6 hours in an interview process. Compared to what I've seen before (full day interviews, freelance period etc) this seems fair to me. But like you comment proves, it might not be for everybody.

marcgg··on The Tech Recruitment Process at Drivy
I don't think that there much one can learn by looking at a couple of classes. On our end we let the candidate decide based on their previous company's policies.
marcgg··on The Tech Recruitment Process at Drivy
Yes, some people prefer not to share this and it is totally fine by us. It's really up to the candidate to decide in accordance to the previous company's policies.

Personally I wouldn't mind if a previous employee would like to demonstrate his/her work using the codebase - as long as they're not applying to a competing firm :) We also have a lot of people that created their own companies or interesting side projects that will present this.

marcgg··on Ask HN: Who is hiring? (August 2016)
Drivy - Paris, France | https://en.drivy.com/ | Full Time | Onsite

We are building the leading peer to peer car rental platform and are hiring across the board. We believe shared cars are a better way to move around, offering more flexibility and more convenience.

We're hiring Frontend, Backend, Fullstack, iOS and Android developers. Our stack is mainly Ruby based, but we you can it learn on the job if you already know another OO language. For Android and iOS we use Java and Swift.

Recruitment process:

- technical test to do whenever you'd like: https://github.com/drivy/jobs

- phone screening

- technical on site interview (~2h, no whiteboard coding)

- it then varies depending on the applicant's profile, but usually 2-3 more hours of on site interviews.

Apply at: https://www.drivy.com/jobs

marcgg··on Ask HN: Who is hiring? (May 2015)
Drivy, Paris - Backend Engineer (Ruby, Rails...) / Fullstack / Android Developer

Our goal is to replace car ownership by a better service: shared cars available at every corner will offer the flexibility and proximity of ownership without the burden of maintenance. We already have a significant traction and rank #1 worldwide on the market of peer-to-peer car rental, but we believe the adoption should be 100 times larger in just a few years.

We're currently looking for Backend, Android and Fullstack engineers to join our tech team in Paris. Positions are detailed here: https://en.drivy.com/jobs

If it sounds like something interesting to you, please contact me directly via marc+jobs@drivy.com

_Please note that the position is in Paris, France. We might consider remote work in the future, but we are not ready to accept it just yet._

marcgg··on Ask HN: Who is hiring? (February 2015)
Drivy - Paris, France - Senior Software Engineer

We are building the leading peer to peer car rental service. Our goal is to replace car ownership by a better service: shared cars available at every corner offering the flexibility and proximity of ownership without the burden of maintenance. We already have a significant traction and rank #1 worldwide on the market of peer-to-peer car rental, but we believe the adoption should be 100 times larger in just a few years.

We're looking for a senior developer to join our team and help us on subjects such as:

- Improving our search algorithm (matching supply and demand) to improve our search-to-book conversion

- Scaling our payments infrastructure

- Designing and implementing new API endpoints for our native apps (iPhone/Android)

- Detecting and preventing fraud

- Monitoring and scaling our platform and tools

- Implementing new features for our end users to enjoy

We build the service using mostly Ruby on Rails. We care a lot about maintaining a good code quality, testing coverage and shipping everything continuously.

You can read more about this position here: https://en.drivy.com/jobs#2015-backend

If this sounds like something interesting and you feel like you fit the job description, contact me directly via marc+hn@drivy.com

marcgg··on Redesigning Mary Meeker's Internet Slideshow
Compared to the NSA redesign you did before, I love that this time we get the whole process and not just a before/after result.
marcgg··on Tips and Tricks Learned Releasing an Hybrid App Using Steroids.js
For the record, the overall development experience improved a lot since August, and I'm sure it'll keep improving, so I'm not surprised by your comment :)

Looking forward to what will be made available in the future!

marcgg··on Tips and Tricks Learned Releasing an Hybrid App Using Steroids.js
Thanks !
marcgg··on Tips and Tricks Learned Releasing an Hybrid App Using Steroids.js
Thanks ! Glad it can be of help, I was really annoyed that such an article didn't exist (or at least I didn't find it) when I started.
marcgg··on Tips and Tricks Learned Releasing an Hybrid App Using Steroids.js
thanks!
marcgg··on The problem with Peak: Activity ≠ productivity
Thanks! When humans are involved, things get way more complicated than expected, that's true. It's all about finding a good balance and a set of metrics that makes sense for your business & team.
marcgg··on Chrome's insane password security strategy
I'm not trying to outclass anyone, I'm simply not sure that this is the right solution and so far I'm fully convinced by what he said. I'm sure he's way smarter than I and I'm probably missing something. Take everything I say as it is: a comment on the internet.

This being said, security through obscurity is never an optimal solution, but again going back to my "safe" analogy (not unbreakable, just hard to break). If a hacker wants to change the password, it takes a few clicks to locate a site where the user could be logged in. Then the clicks required to get a new password. Add the delay of email reception and so on... It takes more time and effort to do that than just click "show me all the passwords" and take a photo with a smartphone. Plus doing so will give you 1 password only.

About the keyboard presses count, let's say I use both mouse and keyboard.

ctrl+, (shortcut to settings) click to advanced click to manage click show

It's 4 operations. In my opinion, it's way shorter to do that and get ALL the passwords of a given user than try to change the Facebook password. Again, and I'm really stressing this out, it's not about making an unbreakable system. It's just making it a bit harder to break.

marcgg··on Chrome's insane password security strategy
I tend to have ways to remember passwords, so I never need this, but ok your use case makes sense. Thanks for sharing!
marcgg··on Chrome's insane password security strategy
I understand that a master password would just lead the user into a false sense of security. However, I feel that it should be make as hard as possible to find the user's password.

A good safe is judged by the time required to break it. There is no safe that is unbreakable, you just need to put enough time, effort and noise to open it. Same thing could be applied here. Installing software, dump the cookies and so on requires time. Right now with this security a person could get my password in a couple of clicks with almost no technical knowledge. I'm not talking about a clever hacker, but rather a random person in a cafe with wifi asking someone if she could check her emails and steal the password while staying in Chrome. Again, it's not about making it impossible to retrieve, it's about making it a bit harder than just clicking the "show me the password" button.

Of course I would never give physical access to my machine to anyone I don't trust. I always lock my computer when leaving it unattended... but I really doubt that anyone acts like that. It's a pretty geeky thing to do and the mainstream crowd isn't as worried by security.

Let's say the master password solution isn't good because of the feeling of security it brings. Instead why not never show the password? Just say to the users it's stored on your system, but don't show it in plain text in Chrome.

My point here is that there is little to no value (unless I'm missing something) to display the password in plain text, but there are some drawbacks (easy to see for semi-technical people). So why have this feature in the first place?

marcgg··on Why I'm Not Proud To Be French
not much, but it's pretty much established that HN covers a group of topics that interests a given community.

Right now on the homepage there's an article on "Alcoholism in Antarctica", discussions about royalties or implications of being under state surveillance...

Looking at your profile I can even say that you already knew that, seeing that you submitted an article about advertising and another one about world ward 2.

marcgg··on Why I'm Not Proud To Be French
I'm proud of French food when manage to cook something good :)
marcgg··on Dear NSA, let me take care of your slides.
I think that's the point ^^
marcgg··on Rubygems.org compromised
Thanks for handling this issue & your work on the site. I look forward to read the post mortem.

Oh, and +1 for the security page

marcgg··on 2 Days Trying To Create a Multiplayer HTML5 Game
The board was not very big, but since every movement would broadcast the entire board to all players, it would add up. I didn't bench exactly how bad it was, but as I was adding data to it I could feel the game slowing down. You have to keep in mind that at that point every movement would make the server send the whole board, and in that game you'd move constantly.

Thanks for the tips. I don't think I'll continue developing this game, but if I get some time I was thinking about doing something cross devices (iPhone / Desktop). I don't know how yet, we'll see.

Page 1 of 2Next →