81–90 of 169 posts
Earlier quoted context omitted.
Many people who work at Google feel the same. The impostor syndrome is a recurring motive in in the internal communications.
Well, when you work at Google, at least you must have passed that kind of an interview at one point - which is something I'm fairly certain I wouldn't be able to do.
Personally, I had a lot of fun doing my interviews and learnt a lot while preparing them. I would recommend you to try them, it's gonna be interesting, even if you don't get the job.
How is "What's the angle between clock hands when it's 3:15?" a trick question? It's not 0.
I was asked that question 2 times in different companies. At the first time I apparently forgot the the Hour stick will move a little bit when the Minute stick move to 15. I guess it's a trick question when we can easily forgot that fact. My brain is train that way that when it's 3 then the Hour stick is at 3...
I recently had an interview at a taxi firm that followed this format. One two three pre-interviews followed by a day of 5 grueling 1 hour interviews. I didn't get the role. Apparently the frontend guy I had the first interview of the days five was concerned about my technical skills. I mean, I find it insulting, having worked for the last 12+ years as a developer to be told that there were "concerns about your techni…
Earlier quoted context omitted.
Apparently Google SREs spend a lot of time watching the clock.
The irony of the clock brain teaser is that it operates on two assumptions. One being that the person asked has experience with analog clocks (which, given that it's 2020 has become less relevant) and the second being that said clock behaves according to standard specifications. If the clock was instead a jump hour clock for example, then that tosses the trickery out of the window. Which is really what that brain tea…
If I were the interviewer here, I would make sure the candidate states their assumptions and that the code they wrote follows those assumptions. You can make the hour hand stick right at the number for the entire hour, or you can have it smoothly sweep as the minutes (or seconds) increase. I would not care and consider both to be reasonable interpretations (but I've never seen a clock that sticks at the hours; it is harder to implement in hardware).
I honestly wouldn't even ask this question because it's too simple. It's two divisions, a subtraction, and then a modulo 360. It is awkward when your interview question only takes 5 minutes and you have to awkwardly fill 55 minutes with follow up questions ("and how would you test that?").
I recently had an interview at a taxi firm that followed this format. One two three pre-interviews followed by a day of 5 grueling 1 hour interviews. I didn't get the role. Apparently the frontend guy I had the first interview of the days five was concerned about my technical skills. I mean, I find it insulting, having worked for the last 12+ years as a developer to be told that there were "concerns about your techni…
I've never failed a take-home test (out of 7) and I do it by doing things no reasonable person would do for production code. I will write a comment for every line (within reason). I will write an entire page of documentation for a one hour project. I will write a test to check for the presence of a title in the rendered page. I will make sure to host it on AWS or Azure and give them instructions on how to upload it t…
Normally when it comes to take-home tests I set a hard limit on actual working time to 3hrs. This doesn't include any research or reading I will do ahead of time.
The test itself was:
> We have 3 services that we want to have running in a kubernetes cluster.
> The first service is a software application called JIRA which will be used internally for the company, so we only want to be accessed by specific IP’s.
> The service needs to be highly available, have failover tolerance and able to restore from backup.
> The other services are a golang application and a python application which we provide the code.
> Inside the go-service folder we will find the golang application which exposes 2 HTTP endpoints, one of those endpoints, talks to the python microservice through GRPC protocol.
> It has 4 environment variables:
> - PORT (the port on which the http server will run)
> - SERVICE_ENDPOINT (endpoint to the python service)
> - REQUEST_TIMEOUT (request timeout in seconds)
> - IDLE_TIMEOUT (idle timeout for requests in seconds)
>
> Inside the python-service folder there is a python microservice, which only supports GRPC Protocol. This service does not have to be exposed to the outside world, and it can only be contacted by the go lang service.
> The python microservice supports a single environment variable: > - PORT (the port on where is going to be running)
>
> These services also require high availability, failover tolerance, and also they need to scale according to the load they receive, as our external clients consume them.
> Deliverables:
> - Dockerfiles for the 3 services
> - Full yaml configuration for the services to be deployed in a k8s, taking into consideration the remarks above.
> - A diagram explaining the whole infrastructure and how it is connected with each other.
> - Paper with ideas on:
> - Monitoring
> - Instrumentation
> - Security
Now, to be perfectly fair, I knew much more about how kubernetes works than how to deploy services on it, so it might have taken me a little longer to create the deployments. However, there's no way that I can make that all work in 3 hours. Not to mention that the backend code I was given wouldn't compile so I had to fix bugs.
Additionally; if I spend more than 3hours on a test, I might as well spend 6 hours, or 12 hours, or a week... At some point it becomes impossible for you to interview at multiple places. The idea of spending 9hrs of my day at work, then coming home and spending another 3hrs+ every night because I want the opportunity to keep spending 9hrs at work is insane, I'm physically unable to do that. When I get home I'm usually burned out, so these kinds of tests are done on the weekend.
Anyway. Where I work, we also give a take home test, and I apply the same principles:
If one of our team can't do it inside of an hour, we don't send it. We expect a candidate to be able to do it within 3hrs. The point of the take home test is that it's something we can discuss later, too. It's really obvious if someone struggles hard or finds it too easy.
I recently had an interview at a taxi firm that followed this format. One two three pre-interviews followed by a day of 5 grueling 1 hour interviews. I didn't get the role. Apparently the frontend guy I had the first interview of the days five was concerned about my technical skills. I mean, I find it insulting, having worked for the last 12+ years as a developer to be told that there were "concerns about your techni…
Google told me I should try doing some open source projects. I had about a hundred thousand lines in a major open source project at the time.
>At first I thought I would be applying for a software developer position but after we went through my skillset, the recruiter concluded that I would better fit as an SRE. I've got to say, I've been contacted by recruiters for Google a few times, and it has always been for SRE roles. I got the distinct impression that it's less about whether my skillset fitted being an SRE, but more that they need lots of SREs and ha…
I recently had an interview at a taxi firm that followed this format. One two three pre-interviews followed by a day of 5 grueling 1 hour interviews. I didn't get the role. Apparently the frontend guy I had the first interview of the days five was concerned about my technical skills. I mean, I find it insulting, having worked for the last 12+ years as a developer to be told that there were "concerns about your techni…
Oh yeah I've had a couple of those as well.
Usually because you can't remember one detail that can be googled or is opinionated about one specific aspect.
At the end I guess in some companies it's more of "who can jump through the hoops like a nice circus animal" more than anything.
(On the opposite side, if you throw me fizzbuzz I'll just make it harder on purpose)
Reading that stuff always makes me feel incredibly stupid (or rather clueless). I wouldn't be able to answer most of those questions off the top of my head. Including this weird clock hand question (which is probably some trivial math that might or might not have been taught to me more than a decade ago and which I never ever actually applied since). Then I probably have to remind myself that I'm (halfway successfull…
Clock hand question is painfully obvious once you look at actual analog clock face. All of the questions were easy bordering on trivial as long as your background lines up with target position. The problem is not the questions, but the culture of gotcha interviewing. Haha we got you doing off by one by offering the C option on whiteboard, haha you didnt initialize one variable on whiteboard, haha I have bad mood ther…
You see, intuitively I thought this would involve some kind of radian maths (just because it's about angles and a circle) and I don't remember any of that - never had any use for it.
But yes, it is a lot more easy than that. Not sure I would have discovered the trivial approach in an interview situation when it didn't even occur to me at home on the couch.