7 ms·

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

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 technical competency" I hate interviews. I hate take home coding tests and have failed every single one I've had. Apparently this is a sign that I don't do well under pressure. I've been building working software for years, and the main problem I have is convincing people that I can actually do the job. I don't have a degree, and I don't have prestigious companies on my CV, and I don't have the time or energy to chase around roles like this, so I have to settle for unfulfilling and underpaid roles

httpsterio 6y ago
I find that the interviewing style of a company is often very telling of its' general work culture. You've missed our on opportunities and had to settle in less prestigious jobs, but are you sure they would've fulfilled you any better.
- ssss11 6y ago
  I tend to agree with this view - if the interviewing experience (for you) was awful you probably dont want to work there.
deleted 6y ago
[deleted]
thiagocesar 6y ago
I understand your frustration, but it seems clear to me that there is difference in what you consider high level technical skills, and what others might perceive as such. In a highly paid position, both selling yourself and your ideas, and smoothing out differences such as this one, are expected from the employee. While I believe that with your experience, you have accomplished a high degree of strong delivery... You still need to be able to manage this whole dealing with people thing. Because that’s why you get paid a high salary, to get any issues out of the way in a skilled manner.
- Aeolun 6y ago
  The problem is that this whole dealing with people thing isn’t solely dependent on yourself, the people you are dealing with need to go along.
- deleted 6y ago
  [deleted]
- pydry 6y ago
  It's pretty indisputable that the industry has a penchant for interviewing problems/techniques that are deliberately unrealistic. Whiteboarding interviews aren't about a lack of time in interviews, for instance, theyre an homage to the academic background of many of the initial internet trailblazers (google, et al).
- alxlaz 6y ago
  > I understand your frustration, but it seems clear to me that there is difference in what you consider high level technical skills, and what others might perceive as such. Or the person who did the interview is an asshole. It's pretty hard to say which one it is. Smoothing out differences such as this one is expected not only from the employee, but also from the interviewer.
MattGaiser 6y ago
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 themselves (even if any dev should know how to throw a git repo onto the cloud). They seem to just be looking that you can do things to a certain level of excellence (even if practically unreasonable). The most recent take-home test was one hour of code and two hours of window dressing. Totally absurd, but I keep doing fine on that step. EDIT: If you are talking about the Hackerranks, those are frustrating simply because you can't clarify requirements. I remember back in university that we gathered in groups to do them to just cover as many test cases as a team as possible.
- dijit 6y ago
  Reminds me of a recent take home test for a SRE role I completed recently. 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.
chrisseaton 6y ago
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.
- MaxBarraclough 6y ago
  Did they not like that it wasn't wholly your project?
  - chrisseaton 6y ago
    > Did they not like that it wasn't wholly your project? No idea - the feedback in full was 'we're not sure you have enough practical experience programming - maybe try working on an open source project'. Then they literally showed me the door at that point lol.
    - jmchuster 6y ago
      It's an interview, so a more accurate piece of feedback would have been "you couldn't convince us you have practical experience programming." So maybe they had a question like, how would you solve those problem, and you said, here's the solution, but they really wanted you to say, there are three potential approaches that i would use, these are the things i evaluate to decide which approach is likely best, these are the war stories that I've had that led me to refine my thinking to this point.
      - chrisseaton 6y ago
        Yeah I guess but how much open source do they want? If you've already got a hundred thousand lines and it isn't fixing what they're after then suggesting something else would be more helpful. But I guess their interview method works for them.
        jmchuster 6y ago
        They're not looking for open source per se, they're looking for you to demonstrate range/depth of experience. If you haven't been able to pick it up from your job, because they're too limited in the types of projects and assignments you can work on, then they're hoping that you can get it yourself from open source. Now, you may already have the abilities that they want you to have, then what you lack is the ability to show so in the interview. edit: Just to clarify, in technical interviews, they often don't even look at your resume, they just ask you the questions and judge you on how you answer them. Stating your years of experience or lines of code written have no bearing.
zerr 6y ago
Most roles at big advertising or taxi companies are unfulfilling.
rco8786 6y ago
How would you suggest that companies interview and evaluate people like yourself?
- zozbot234 6y ago
  Acquihire? Or else seek work in the industry as a contractor, not an employee.
raverbashing 6y ago
> having worked for the last 12+ years as a developer to be told that there were "concerns about your technical competency" 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)
koonsolo 6y ago
> having worked for the last 12+ years as a developer I've done plenty of interviews, and the amount of years someone worked does not mean they are technically capable. By chance, last week I interviewed a frontend JavaScript expert: couldn't explain 'scope', couldn't explain 'function context', didn't know what happens when setTimeout() is followed by an infinite loop ("After 10 seconds or so the browser will probably timeout the loop"). A junior cannot know everything, a senior should be able to pull a project and team. Personal advice to you: if you are really good but cannot show it in an interview, try to land a job at companies with ex-colleagues, where they are able to vouch for your technical skills. If a colleague that I respect vouches for someone (s)he worked with, (s)he is practically already hired.
- shakopeeant 6y ago
  "didn't know what happens when setTimeout() is followed by an infinite loop" You're part of the problem.
- s1k3s 6y ago
  > didn't know what happens when setTimeout() is followed by an infinite loop I'm not some JS guru but I've done a few and I'm wondering why would I need to know this? To me this looks like the type of question that is there specifically because people answer it wrong, they know they answer it wrong and you know they know they answer it wrong so it makes them lower their demands in terms of pay rate.
  - remify 6y ago
    I guess it's an important question because it is about the event loop. Lots of weird things (bugs) can happen when you don't understand how the event loop work. I would definitely pass a "senior" javascript dev that don't know/understand the concept.
    - koonsolo 6y ago
      Exactly this. A senior should know that JavaScript runs single threaded with an event loop, and therefore doing heavy calculations will block your user interactions. If you don't know this, you also won't know when to use WebWorkers etc. Juniors can learn, seniors should be the ones teaching them. Seniors should define the architecture of your solution, and solve weird problems. You cannot do this without proper in-depth knowledge.
solraph 6y ago
In the last few years, I've sat on both sides of the interview table several times. Recruitment in software engineering is a disaster from start to finish for all involved. As salaries have risen, it's only gotten worse. On one side, there is a depressing number of people out there applying for programming jobs who effectively can't code. Their "skills" range from mindlessly repeating previous patterns they were told to use elsewhere without considering their applicability to the current context, all the way down to literally copy/pasting code chunks till the program appears to be working. Many of this group either don't care, or are blissfully unaware of what they don't know, or how little they know about subjects they believe themselves to be experts in. This group is the majority of applicants. This is where the take home coding tests come from (which frankly, I also loathe). On the other side, interviews are usually conducted by who-ever has been at an organisation the longest, and/or is most willing to put up with the shenanigans of interviewing the group mentioned above. This often means they're the ones most likely to enjoy catching people out, or who have some particular thing they like to grill people on. This is where you get the twenty-questions bingo style interviewing. Your recent interview sounds like one of these. To add to this, there's a variety of situations where the applicant _should_ get the job, but they don't for reasons outside of the interview room. A manager wants to hire someone they know. Due to reshuffling, the job requirements have changed between publishing the job ad and interviewing. The budget was curtailed after the interview. Chances are, you'll never know the true story. In addition, a large portion of developers don't ever go through the normal recruitment process. They'll do interviews, but they're recommended by colleagues, members of their meetup, friends of the above, or their IRC / Slack / Discord / etc group, and their interview process will reflect that. This is currently the best way to get a job. Often these groups are invite-only, and effectively invisiable. In the middle of this maelstrom, are the few reasonably competent applicants applying for a job that is right for them, with a reasonable and fair interviewer. -- Based on all the above, without knowing a thing about you, I'd be forced to conclude one of three options: a) You've just been really unlucky. I've been there, it sucks. b) You're not actually as good as you think you are. Usually this is when a programmer hits a certain level of expertise and stops learning anything new for some reason. Sometimes this is down to ego, sometimes it's because they've become the biggest fish in a small pond. The symptom seems to be a lack of curiosity, if not hostility, about novel or unexplored concepts. c) The above observations are based on my incredibly biased view of my corner of the world, and don't match your reality at all.
higeorge13 6y ago
IMO the take-home tests close to the job's technical requirements and followed by 1-2 technical interviews to discuss its details and potential improvements is probably the best interview method. It gives a chance to both parties to get to know their potential future colleagues and see their technical background, skills and effort on solving an actual problem that could be part of their daily tasks. And it gives you the right, if you feel 100% ok with what you delivered and you hear an excuse of lack of technical skills to skip the job and look for something else. Whereas having to pass 6 interviews with random CS and DS questions and problems where you have to memorise algorithms which you will never use in your daily work and then finally be rejected because you forgot one of them is way worse and has probably deteriorated the software engineering industry as a whole.
wayanon 6y ago
What sort of salary range dictates that kind of interview process? It seems crazy to me - it isn't the CIA.

httpsterio 6y ago

I find that the interviewing style of a company is often very telling of its' general work culture. You've missed our on opportunities and had to settle in less prestigious jobs, but are you sure they would've fulfilled you any better.

ssss11 6y ago
I tend to agree with this view - if the interviewing experience (for you) was awful you probably dont want to work there.

deleted 6y ago

[deleted]

thiagocesar 6y ago

I understand your frustration, but it seems clear to me that there is difference in what you consider high level technical skills, and what others might perceive as such. In a highly paid position, both selling yourself and your ideas, and smoothing out differences such as this one, are expected from the employee. While I believe that with your experience, you have accomplished a high degree of strong delivery... You still need to be able to manage this whole dealing with people thing. Because that’s why you get paid a high salary, to get any issues out of the way in a skilled manner.

Aeolun 6y ago
The problem is that this whole dealing with people thing isn’t solely dependent on yourself, the people you are dealing with need to go along.
deleted 6y ago
[deleted]
pydry 6y ago
It's pretty indisputable that the industry has a penchant for interviewing problems/techniques that are deliberately unrealistic. Whiteboarding interviews aren't about a lack of time in interviews, for instance, theyre an homage to the academic background of many of the initial internet trailblazers (google, et al).
alxlaz 6y ago
> I understand your frustration, but it seems clear to me that there is difference in what you consider high level technical skills, and what others might perceive as such. Or the person who did the interview is an asshole. It's pretty hard to say which one it is. Smoothing out differences such as this one is expected not only from the employee, but also from the interviewer.

MattGaiser 6y ago

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 themselves (even if any dev should know how to throw a git repo onto the cloud). They seem to just be looking that you can do things to a certain level of excellence (even if practically unreasonable). The most recent take-home test was one hour of code and two hours of window dressing. Totally absurd, but I keep doing fine on that step. EDIT: If you are talking about the Hackerranks, those are frustrating simply because you can't clarify requirements. I remember back in university that we gathered in groups to do them to just cover as many test cases as a team as possible.

dijit 6y ago
Reminds me of a recent take home test for a SRE role I completed recently. 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.

chrisseaton 6y ago

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.

MaxBarraclough 6y ago
Did they not like that it wasn't wholly your project?
- chrisseaton 6y ago
  > Did they not like that it wasn't wholly your project? No idea - the feedback in full was 'we're not sure you have enough practical experience programming - maybe try working on an open source project'. Then they literally showed me the door at that point lol.
  - jmchuster 6y ago
    It's an interview, so a more accurate piece of feedback would have been "you couldn't convince us you have practical experience programming." So maybe they had a question like, how would you solve those problem, and you said, here's the solution, but they really wanted you to say, there are three potential approaches that i would use, these are the things i evaluate to decide which approach is likely best, these are the war stories that I've had that led me to refine my thinking to this point.
    - chrisseaton 6y ago
      Yeah I guess but how much open source do they want? If you've already got a hundred thousand lines and it isn't fixing what they're after then suggesting something else would be more helpful. But I guess their interview method works for them.
      - jmchuster 6y ago
        They're not looking for open source per se, they're looking for you to demonstrate range/depth of experience. If you haven't been able to pick it up from your job, because they're too limited in the types of projects and assignments you can work on, then they're hoping that you can get it yourself from open source. Now, you may already have the abilities that they want you to have, then what you lack is the ability to show so in the interview. edit: Just to clarify, in technical interviews, they often don't even look at your resume, they just ask you the questions and judge you on how you answer them. Stating your years of experience or lines of code written have no bearing.

zerr 6y ago

Most roles at big advertising or taxi companies are unfulfilling.

rco8786 6y ago

How would you suggest that companies interview and evaluate people like yourself?

zozbot234 6y ago
Acquihire? Or else seek work in the industry as a contractor, not an employee.

raverbashing 6y ago

> having worked for the last 12+ years as a developer to be told that there were "concerns about your technical competency" 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)

koonsolo 6y ago

> having worked for the last 12+ years as a developer I've done plenty of interviews, and the amount of years someone worked does not mean they are technically capable. By chance, last week I interviewed a frontend JavaScript expert: couldn't explain 'scope', couldn't explain 'function context', didn't know what happens when setTimeout() is followed by an infinite loop ("After 10 seconds or so the browser will probably timeout the loop"). A junior cannot know everything, a senior should be able to pull a project and team. Personal advice to you: if you are really good but cannot show it in an interview, try to land a job at companies with ex-colleagues, where they are able to vouch for your technical skills. If a colleague that I respect vouches for someone (s)he worked with, (s)he is practically already hired.

shakopeeant 6y ago
"didn't know what happens when setTimeout() is followed by an infinite loop" You're part of the problem.
s1k3s 6y ago
> didn't know what happens when setTimeout() is followed by an infinite loop I'm not some JS guru but I've done a few and I'm wondering why would I need to know this? To me this looks like the type of question that is there specifically because people answer it wrong, they know they answer it wrong and you know they know they answer it wrong so it makes them lower their demands in terms of pay rate.
- remify 6y ago
  I guess it's an important question because it is about the event loop. Lots of weird things (bugs) can happen when you don't understand how the event loop work. I would definitely pass a "senior" javascript dev that don't know/understand the concept.
  - koonsolo 6y ago
    Exactly this. A senior should know that JavaScript runs single threaded with an event loop, and therefore doing heavy calculations will block your user interactions. If you don't know this, you also won't know when to use WebWorkers etc. Juniors can learn, seniors should be the ones teaching them. Seniors should define the architecture of your solution, and solve weird problems. You cannot do this without proper in-depth knowledge.

solraph 6y ago

In the last few years, I've sat on both sides of the interview table several times. Recruitment in software engineering is a disaster from start to finish for all involved. As salaries have risen, it's only gotten worse. On one side, there is a depressing number of people out there applying for programming jobs who effectively can't code. Their "skills" range from mindlessly repeating previous patterns they were told to use elsewhere without considering their applicability to the current context, all the way down to literally copy/pasting code chunks till the program appears to be working. Many of this group either don't care, or are blissfully unaware of what they don't know, or how little they know about subjects they believe themselves to be experts in. This group is the majority of applicants. This is where the take home coding tests come from (which frankly, I also loathe). On the other side, interviews are usually conducted by who-ever has been at an organisation the longest, and/or is most willing to put up with the shenanigans of interviewing the group mentioned above. This often means they're the ones most likely to enjoy catching people out, or who have some particular thing they like to grill people on. This is where you get the twenty-questions bingo style interviewing. Your recent interview sounds like one of these. To add to this, there's a variety of situations where the applicant _should_ get the job, but they don't for reasons outside of the interview room. A manager wants to hire someone they know. Due to reshuffling, the job requirements have changed between publishing the job ad and interviewing. The budget was curtailed after the interview. Chances are, you'll never know the true story. In addition, a large portion of developers don't ever go through the normal recruitment process. They'll do interviews, but they're recommended by colleagues, members of their meetup, friends of the above, or their IRC / Slack / Discord / etc group, and their interview process will reflect that. This is currently the best way to get a job. Often these groups are invite-only, and effectively invisiable. In the middle of this maelstrom, are the few reasonably competent applicants applying for a job that is right for them, with a reasonable and fair interviewer. -- Based on all the above, without knowing a thing about you, I'd be forced to conclude one of three options: a) You've just been really unlucky. I've been there, it sucks. b) You're not actually as good as you think you are. Usually this is when a programmer hits a certain level of expertise and stops learning anything new for some reason. Sometimes this is down to ego, sometimes it's because they've become the biggest fish in a small pond. The symptom seems to be a lack of curiosity, if not hostility, about novel or unexplored concepts. c) The above observations are based on my incredibly biased view of my corner of the world, and don't match your reality at all.

higeorge13 6y ago

IMO the take-home tests close to the job's technical requirements and followed by 1-2 technical interviews to discuss its details and potential improvements is probably the best interview method. It gives a chance to both parties to get to know their potential future colleagues and see their technical background, skills and effort on solving an actual problem that could be part of their daily tasks. And it gives you the right, if you feel 100% ok with what you delivered and you hear an excuse of lack of technical skills to skip the job and look for something else. Whereas having to pass 6 interviews with random CS and DS questions and problems where you have to memorise algorithms which you will never use in your daily work and then finally be rejected because you forgot one of them is way worse and has probably deteriorated the software engineering industry as a whole.

wayanon 6y ago

What sort of salary range dictates that kind of interview process? It seems crazy to me - it isn't the CIA.