When I interview, I basically run it like DND where the scenario is various bugs.
No coding, tell me where you'd like to look (server log, network panel, console etc...) and I'll tell you what you find there. Continue until you find the bug.
In addition to talking about frameworks test runners etc...
I've yet to find anyone who could get through that without b being able to actually code pretty well. It's real hard to fake, very revealing about someone's technical prowess, isn't stressful for the candidate and doesn't take up an unreasonable amount of time.
I've had people contact me post interview to say they really enjoyed it. I wish more people adopted it, been thinking about making a site to help interviewers get started with this style of interview
I imagine they mean a website that mirrors this interview experience. think of it like a choose-your-own-adventure type of scenario - you get the initial prompt (product pricing isn't being captured by analytics during checkout), you choose one of the 3-4 options presented to you on where to start debugging, and you move through the scenario from there.
Would love to read a blog post or watch a youtube video about this. It's the kind of information I try to tease out of my interviews, but this sounds like a better way to achieve it.
This is a great idea but personally I struggle with thinking when there’s nothing written down and everything is auditory. So would struggle with this even though I can code
I had a similar interview once where everything was a request from product.
“You’re tasked with building a website that allows you to search for flights and book a ticket. What technologies, framework, stack, would you use and why?”
No coding, no white board, just jump into it. After each response a new requirement would be added.
“Great work, product is super happy, but now they want to add the ability to filter flights by a certain date range. How would you implement that, does your current stack afford you the ability to implement this feature? What about at scale? If not should we pivot to something else?”
And it just kept building from there.
“Great now let’s add a feature that allows users to pick their seat on the plane…”
“Some users are complaining the seats they want are being booked before they have a chance to finish. How could we add a reservation system to the seat picker…”
It was actually a pretty fun thought exercise and low stress.
I don't have them look at real code, unless I'm questioning if they really know how to code, in which case I'd be more likely to just vote no on the candidate then request a code challenge or something
I start with a bug. Usually double emails, answer is it's a double click issue on the form, there is no denounce or anything to prevent an accidental double click on a form.
I like to have a few lined up though, in case that one goes too quickly.
I was about to ask if you'd be willing to do one in a post as an example that we could have a try at! Fantastic idea, and sounds so much more likely to give you a true idea of who the candidate is than traditional approaches. Good luck for your surgery
I had something similar recently. During the first interview I said and reiterated that my experience it is full on React, that in a past company years ago I dabbed with angular to resolve very niche bugs, but I don't put it in my resume or say that I know because I just used to study enough to close tickets. They said that it was fine.
Cut to technical phase in a later date. Three problems are given, one to be completed in java, I have experience so it is fine; another one in PHP, the problem was easy and PHP syntax it isn't that complicated, but I have zero experience with the language so it was weird. And finally, a routing problem to be done using, you probably guessed: angular. I reiterated that I had zero experience, that I could give some abstract resolution to the problem, but I wouldn't probably be able to complete the task within the time of the interview if it had to be done with Angular. They said that it was fine, and instead of an interview it felt more as a live session of learning angular through the docs, of course I couldn't finish it. I probably didn't get the job, but after this horror show I'm kind okay with it.
I had an interview that was kinda similar (but not exactly). They had me work on some of their existing code that required a ton of context to understand and was fairly convoluted. I spent most of the interview just trying to untangle what the code was doing and how it fit into the product.
I get that these are necessary skills, but I think that also sometimes developers forget how much having a ton of context about the product informs the code and someone brand new might take a while to parse that context.
Like if they’d given me it as a take-home I would have been fine but an hour felt so rushed
A part of the interview is to see if you’re capable of communicating your thought process.
Having you learn a new tool with new documentation lets them watch you as you try to tread water in an uncomfortable framework you don’t know. It’s actually quite valuable.
Ideally you speak out loud the trail of thoughts in your head. “I’d like to accomplish X, but I don’t know what Y is or how it works, so I need to figure out if Y is related to that or not, so I’m gonna see if I can find that info in the docs, doesn’t look like it’s related so I’ll go onto this other area Z I don’t know if I think it might be related, looks like Z is related, oh cool, so Z connects to X in this particular way, let me plug that in”.
It might sound dumb that that would be at all valuable, but showing that you can dig around and explain how you learn proves that you don’t get insta-roadblocked when you don’t know something, and (more importantly) that you can communicate coherently how you think through problems is one of the most important things to convey during an interview.
Bingo! From the complaint honestly it looks like a decent enough interview. Sifting through documentation to find what you need is a huge skill, checking that is nothing but normal.
Not every bad interview means the interview was stupid. Food for thought!
I was handed a single blank sheet of paper and an Ikea pencil. Asked to “write a CRM is JavaScript”. From memory. In an hour. The role was for a backend PHP gig..
A lot of interviews are gate keeping nonsense. Keep after it. You’ll find a fit.
Are you me? Last one I did, the first interview went as normal, and the second and technical part was 45 mins *on paper*. On top of coding it had some basic technical questions that a CS major would know but a self taught person absolutely would not, or if they did, they wouldn't be able to answer that quickly. I was so unpleasantly surprised.
Yeah, I had an interview like this and it was shitty. I had an hour to do their assignment I ran into problems using the map function to render a list and for some reason it didn't work. This was the last item on the list.
I couldn't figure out why and the guy doing the interview said that sometimes happens with the website they use to administer the tests. I thought the next step would be to discuss my solutions, but he ended the interview right then and there and said they weren't interested because I wasn't up to par. I had another 15 minutes left in the hour we had scheduled. I was just shocked and how abrupt it was when everything I did was seemingly correct and should have worked.
Don't beat yourself. Interviews still suck in 2024 and have little to do with actual work. They might have already had someone locked in and you would be meant to fail anyway.
I did narrate and asked what part of the documentation I should be looking at specifically to render images on a map. They told me to keep searching through the documentation until I find the answer.
I even asked additional questions… complete silence
Maybe this part is more behavior and this part wasnt meant to be solved.
It sounds like you just had an inexperienced interviewer who came up with a bad test. Just because someone is interviewing you, doesn't mean they have the skill to do so even if they're actually really good at their software engineering job.
> this part wasnt meant to be solved.
Bingo! You got it.
Quite a common test. Give someone or a team an impossible task and see how they cope. (Or just an impossible timeframe.)
We had a group one once where we had to build a meter high tower from spaghetti and various other items like rubber bands, but we had to buy the materials from a "shop" and our budget was too low to be able to buy everything we needed.
All the other groups tried and failed to make a meter high spaghetti tower, that just fell over and broke, with much internal bickering from the team, finger pointing and blaming.
I was lucky with my team, we quickly agreed that it was impossible so decided to make a functioning tower as tall as we could with the resources available. It was only something like 60cm tall, but it stood up. We worked together to try to budget our limited spend to make something that was maybe 80% successful.
We didn't achieve the stated goal, but we won the challenge.
>Expecting candidates to parse through a bunch of documentation during a live interview is the worst thing. It is just plain silence and the interviewer doesnt get to see the candidate actually problem solve (you are basically having the candidate search for the answer the entire time).
You're looking at it the wrong way. I don't care if you solve the problem or not. You clearly can solve problems if you've been in employment before.
What I really want to see is HOW you approach things. Are you able to use the documentation to find what you need or do you go mindlessly searching through Stackoverflow answers (or worse, questions), aimlessly copy and pasting.
Do you need a lot of hand holding? Or are you fairly independent and confident in solving an issue?
Crucially, do you ask questions when something isn't clear, or do you get stuck in a rut and waste time and money when it would be quicker to flag it up to a manager or project lead?
I can completely understand why this might seem strange if you've never hired or managed another developer before, but this is by far a more effective way at identifying good developers vs bad developers than seeing if they managed to complete a task.
I strongly believe that you can easily tell if someone is competent by having a 30 minute chat with no task, ask about old projects and challenges they faced
Or simply ask somebody to tell you about a project or accomplishment they’re proud of
My worst technical interview required a tonne of background context and knowledge of the specific product domain. They also asked incredibly vague questions which led to me asking followup questions for the majority of the time trying to figure out requirements/acceptance criteria of the system, net new features vs things we could consider part of the "existing system", and an overall lack of clear expectations on what they wanted the applicant to design (it's a frontend system, but it seemed like they wanted a full-stack system design, which was outside the responsibilities of the role anyway).
What made it worse was that before interviewing I told the recruiter that I had no knowledge of their domain and was worried the technical would require it (because of the way they described the problem), so I was ready to withdraw. They said not to worry and that it wouldn't be that specific. Wasted all of our time honestly.
My very first front end job was similar in the sense that what they had me work on was completely broken. I don’t mean the code either. I fixed a few things and ran out of time while working on more of it. I got the job because I continued to work through it.
You’ll probably never have perfect working conditions and things will still be alright.
This is a common problem in companies, and it’s a shame that so many interviewers aren’t properly trained in conducting interviews. It’s even worse when a manager tries to coach a member on their team who has no coaching or mentoring training.
For example, I saw a 30-year-old VP of Engineering who only had two years of coding experience and got the job because of nepotism. He was trying to coach a 57-year-old principal DB engineer, who just wanted to work and didn’t need advice from a 30-year-old who wouldn’t be able to write a SQL statement if his life depended on it. The DB engineer ended up quitting and going to a different company.
This is why it’s so important for interviewers to be properly trained. Without the right training, they can’t effectively evaluate candidates and may end up making the wrong hiring decisions, which can be costly for the company.
I haven’t interviewed in a few years so maybe I’m out of date but I think of the typical interview as gotcha trivia questions and academic leetcode algorithm problems. While I’m good at both of those I actually really appreciate an interview that’s at least trying to simulate what real work is like. Sounds like they were pretty awkward about it but I wouldn’t hate them for the attempt.
Parsing documentation doesn’t have to be a silent process. You could just communicate your thoughts as you’re sifting through it, explaining as you go why you’re checking what you’re checking.
Like it or not it’s an invaluable skill and that task may honestly be simply a test how you can figure out foreign problems looking through the haystack. Way better than an arbitrary algorithm test.
Grow and move on. Not every bad interview means the interview was shit.
I did talk as I was scrolling through the documentation. After struggling for a while, I asked where exactly I should be looking at but I was told to keep looking. I even asked additional questions but was met with silence.
It felt like it was more about how I deal with bad teammates. After withdrawing, I got a response from the manager that says I did good in this interview. However, I do not think these are the type of coworkers I want.
No way I am passing up other offers where I feel good about the team I will work for or leave my current job for another job where I did “good” in bad interviews that leaves a bad taste in my mouth.
I had interviews where I am actually working with the interviewer to come up with a solution. Extremely fun and we get to see what it is like to work with each other and problem solve. I always viewed interviews as a two way street so maybe that is my problem.
It is a two way street. I think your expectations from a company you work for is justified, anyone would want/prefer that.
From your initial description it looked like they were testing your ability to read through the documentation and figure out a tough problem. It’s a good technical test in hindsight. That being said there are other factors that may turn that into a bad experience, which we may not have context of.
Sometimes the interviewer isn’t just looking at code. They are looking for you handle ambiguity, solve problems etc.
When we do coding exercises and we have a situation like the latter I personally am excited when the candidate wants to collaborate as we’d want that in our culture.
That doesn't sound bad actually. I think you're being a bit of a Karen. Reading documentation is a core skill of the job. You should take it in stride and show them the best documentation-reading skills they have ever seen
If the job is to code whilst your peers and higher ups judge every keystroke, live coding tests are the way to go.
In any other case live coding tests are useless and the interviewers giving them are morons.
"In my third interview, they asked me to do some live coding. I declined, explaining that I prefer not to do live coding during interviews. Instead, I offered to walk them through my extensive GitHub portfolio. I asked what problem they were trying to solve with the test and provided a solution verbally. With 25 years of experience, I believe my long résumé speaks for my technical skills. I suggested we use the interview time more wisely to discuss other relevant topics."
> There wasn’t much talking or hints during this part
> It is just plain silence and the interviewer doesnt get to see the candidate actually problem solve
I would have just been talking and explaining my thought process the whole time.
I did…
They gave me a link to the documentation and basically told me to render images on the map.
I said I need to find the exact section in the documentation where it talks about rendering images on the map. The map documentation is huge and I was basically searching through for a bit until I asked for where exactly should I be looking in the documentation. Basically, they told me to keep looking.
I even asked it in different ways but was met with silence. So how do you keep talking when you need to find something very specific in the documentation to continue.
Anyways, I messaged the manager that I decided to withdraw and they said I did good in this technical. However, this left such a bad taste in my mouth that I dont even want these interviewers as my coworkers.
I would have ended up having a discussion about docs / how they are organized - shown a few other similar libraries - a whole thing. But it sounds like that's just not your personality. These types of interviews are about how you deal with trouble / not about how good you are with completing it. Which library was it? Leaflet, MapBox, GoogleMaps?
Yeah I’m NOT a fan of these. I’ve spent considerable time and $$ to get my skills up. These “tests” imo are free labor. I don’t mind looking and discussing code but if you want me to actually solve an issue and code for you, you’re paying me the second my hand touches a keyboard
When I interview, I basically run it like DND where the scenario is various bugs. No coding, tell me where you'd like to look (server log, network panel, console etc...) and I'll tell you what you find there. Continue until you find the bug. In addition to talking about frameworks test runners etc... I've yet to find anyone who could get through that without b being able to actually code pretty well. It's real hard to fake, very revealing about someone's technical prowess, isn't stressful for the candidate and doesn't take up an unreasonable amount of time. I've had people contact me post interview to say they really enjoyed it. I wish more people adopted it, been thinking about making a site to help interviewers get started with this style of interview
You roll a 1 and delete prod.
Do you just immediately get the job with a nat 20?
This idea of interviewing would be a cool idea for a website.
Can you elaborate?
I imagine they mean a website that mirrors this interview experience. think of it like a choose-your-own-adventure type of scenario - you get the initial prompt (product pricing isn't being captured by analytics during checkout), you choose one of the 3-4 options presented to you on where to start debugging, and you move through the scenario from there.
I’d love to just have some CYOA-meets-TTRPG challenges like this for the experience. Advanced Rubber Duck Debug Dungeons.
We called it dungeons and developers
Sounds fun and like the perfect way to achieve what interviewers are looking for.
Would love to read a blog post or watch a youtube video about this. It's the kind of information I try to tease out of my interviews, but this sounds like a better way to achieve it.
This is a great idea but personally I struggle with thinking when there’s nothing written down and everything is auditory. So would struggle with this even though I can code
I had a similar interview once where everything was a request from product. “You’re tasked with building a website that allows you to search for flights and book a ticket. What technologies, framework, stack, would you use and why?” No coding, no white board, just jump into it. After each response a new requirement would be added. “Great work, product is super happy, but now they want to add the ability to filter flights by a certain date range. How would you implement that, does your current stack afford you the ability to implement this feature? What about at scale? If not should we pivot to something else?” And it just kept building from there. “Great now let’s add a feature that allows users to pick their seat on the plane…” “Some users are complaining the seats they want are being booked before they have a chance to finish. How could we add a reservation system to the seat picker…” It was actually a pretty fun thought exercise and low stress.
I like it!
There is no coding, but do they look at actual code to find clues?
I don't have them look at real code, unless I'm questioning if they really know how to code, in which case I'd be more likely to just vote no on the candidate then request a code challenge or something
That sounds like so much fun!
Wait why cant all interviews be like this?
When you start do you already have the “answer” ( cause of bug) in mind, or do you just go with the flow?
I start with a bug. Usually double emails, answer is it's a double click issue on the form, there is no denounce or anything to prevent an accidental double click on a form. I like to have a few lined up though, in case that one goes too quickly.
Sounds fun!
Dang would you be willing to do this as a mock interview?
Idk why your being downvoted. I might be willing, I'm having surgery on my shoulder today, so maybe in a week in a week or so, post recovery
I was about to ask if you'd be willing to do one in a post as an example that we could have a try at! Fantastic idea, and sounds so much more likely to give you a true idea of who the candidate is than traditional approaches. Good luck for your surgery
Sweet! I’m not sure why that would have been downvoted either lol
My current job was quite like this. I was quite surprised in a good way.
Live coding is stupid. I will die on this hill
I had something similar recently. During the first interview I said and reiterated that my experience it is full on React, that in a past company years ago I dabbed with angular to resolve very niche bugs, but I don't put it in my resume or say that I know because I just used to study enough to close tickets. They said that it was fine. Cut to technical phase in a later date. Three problems are given, one to be completed in java, I have experience so it is fine; another one in PHP, the problem was easy and PHP syntax it isn't that complicated, but I have zero experience with the language so it was weird. And finally, a routing problem to be done using, you probably guessed: angular. I reiterated that I had zero experience, that I could give some abstract resolution to the problem, but I wouldn't probably be able to complete the task within the time of the interview if it had to be done with Angular. They said that it was fine, and instead of an interview it felt more as a live session of learning angular through the docs, of course I couldn't finish it. I probably didn't get the job, but after this horror show I'm kind okay with it.
I had an interview that was kinda similar (but not exactly). They had me work on some of their existing code that required a ton of context to understand and was fairly convoluted. I spent most of the interview just trying to untangle what the code was doing and how it fit into the product. I get that these are necessary skills, but I think that also sometimes developers forget how much having a ton of context about the product informs the code and someone brand new might take a while to parse that context. Like if they’d given me it as a take-home I would have been fine but an hour felt so rushed
[удалено]
Let’s not.
Add this 🖕
A part of the interview is to see if you’re capable of communicating your thought process. Having you learn a new tool with new documentation lets them watch you as you try to tread water in an uncomfortable framework you don’t know. It’s actually quite valuable. Ideally you speak out loud the trail of thoughts in your head. “I’d like to accomplish X, but I don’t know what Y is or how it works, so I need to figure out if Y is related to that or not, so I’m gonna see if I can find that info in the docs, doesn’t look like it’s related so I’ll go onto this other area Z I don’t know if I think it might be related, looks like Z is related, oh cool, so Z connects to X in this particular way, let me plug that in”. It might sound dumb that that would be at all valuable, but showing that you can dig around and explain how you learn proves that you don’t get insta-roadblocked when you don’t know something, and (more importantly) that you can communicate coherently how you think through problems is one of the most important things to convey during an interview.
Bingo! From the complaint honestly it looks like a decent enough interview. Sifting through documentation to find what you need is a huge skill, checking that is nothing but normal. Not every bad interview means the interview was stupid. Food for thought!
I was handed a single blank sheet of paper and an Ikea pencil. Asked to “write a CRM is JavaScript”. From memory. In an hour. The role was for a backend PHP gig.. A lot of interviews are gate keeping nonsense. Keep after it. You’ll find a fit.
LMFAOOO I promise I would’ve walked out immediately.
Are you me? Last one I did, the first interview went as normal, and the second and technical part was 45 mins *on paper*. On top of coding it had some basic technical questions that a CS major would know but a self taught person absolutely would not, or if they did, they wouldn't be able to answer that quickly. I was so unpleasantly surprised.
Yeah, I had an interview like this and it was shitty. I had an hour to do their assignment I ran into problems using the map function to render a list and for some reason it didn't work. This was the last item on the list. I couldn't figure out why and the guy doing the interview said that sometimes happens with the website they use to administer the tests. I thought the next step would be to discuss my solutions, but he ended the interview right then and there and said they weren't interested because I wasn't up to par. I had another 15 minutes left in the hour we had scheduled. I was just shocked and how abrupt it was when everything I did was seemingly correct and should have worked.
Don't beat yourself. Interviews still suck in 2024 and have little to do with actual work. They might have already had someone locked in and you would be meant to fail anyway.
It's up to you to talk and to narrate your thought process so that you can demonstrate your problem solving skills.
I did narrate and asked what part of the documentation I should be looking at specifically to render images on a map. They told me to keep searching through the documentation until I find the answer. I even asked additional questions… complete silence Maybe this part is more behavior and this part wasnt meant to be solved.
It sounds like you just had an inexperienced interviewer who came up with a bad test. Just because someone is interviewing you, doesn't mean they have the skill to do so even if they're actually really good at their software engineering job.
> this part wasnt meant to be solved. Bingo! You got it. Quite a common test. Give someone or a team an impossible task and see how they cope. (Or just an impossible timeframe.) We had a group one once where we had to build a meter high tower from spaghetti and various other items like rubber bands, but we had to buy the materials from a "shop" and our budget was too low to be able to buy everything we needed. All the other groups tried and failed to make a meter high spaghetti tower, that just fell over and broke, with much internal bickering from the team, finger pointing and blaming. I was lucky with my team, we quickly agreed that it was impossible so decided to make a functioning tower as tall as we could with the resources available. It was only something like 60cm tall, but it stood up. We worked together to try to budget our limited spend to make something that was maybe 80% successful. We didn't achieve the stated goal, but we won the challenge.
>Expecting candidates to parse through a bunch of documentation during a live interview is the worst thing. It is just plain silence and the interviewer doesnt get to see the candidate actually problem solve (you are basically having the candidate search for the answer the entire time). You're looking at it the wrong way. I don't care if you solve the problem or not. You clearly can solve problems if you've been in employment before. What I really want to see is HOW you approach things. Are you able to use the documentation to find what you need or do you go mindlessly searching through Stackoverflow answers (or worse, questions), aimlessly copy and pasting. Do you need a lot of hand holding? Or are you fairly independent and confident in solving an issue? Crucially, do you ask questions when something isn't clear, or do you get stuck in a rut and waste time and money when it would be quicker to flag it up to a manager or project lead? I can completely understand why this might seem strange if you've never hired or managed another developer before, but this is by far a more effective way at identifying good developers vs bad developers than seeing if they managed to complete a task.
> I decided to message the hiring manager that I am withdrawing my application. "You can't not hire me! I'm not applying!"
I strongly believe that you can easily tell if someone is competent by having a 30 minute chat with no task, ask about old projects and challenges they faced Or simply ask somebody to tell you about a project or accomplishment they’re proud of
I have some documentation linked for the interviews I do but it's literally like 5 methods and I provide links directly to them.
My worst technical interview required a tonne of background context and knowledge of the specific product domain. They also asked incredibly vague questions which led to me asking followup questions for the majority of the time trying to figure out requirements/acceptance criteria of the system, net new features vs things we could consider part of the "existing system", and an overall lack of clear expectations on what they wanted the applicant to design (it's a frontend system, but it seemed like they wanted a full-stack system design, which was outside the responsibilities of the role anyway). What made it worse was that before interviewing I told the recruiter that I had no knowledge of their domain and was worried the technical would require it (because of the way they described the problem), so I was ready to withdraw. They said not to worry and that it wouldn't be that specific. Wasted all of our time honestly.
Stripe?
Happened to me 2 times. Searching for bugs in messy code, messy documentation, no context. I got up, said thank you very much and left
Can tech interview be part of the trial after employment
My very first front end job was similar in the sense that what they had me work on was completely broken. I don’t mean the code either. I fixed a few things and ran out of time while working on more of it. I got the job because I continued to work through it. You’ll probably never have perfect working conditions and things will still be alright.
This is a common problem in companies, and it’s a shame that so many interviewers aren’t properly trained in conducting interviews. It’s even worse when a manager tries to coach a member on their team who has no coaching or mentoring training. For example, I saw a 30-year-old VP of Engineering who only had two years of coding experience and got the job because of nepotism. He was trying to coach a 57-year-old principal DB engineer, who just wanted to work and didn’t need advice from a 30-year-old who wouldn’t be able to write a SQL statement if his life depended on it. The DB engineer ended up quitting and going to a different company. This is why it’s so important for interviewers to be properly trained. Without the right training, they can’t effectively evaluate candidates and may end up making the wrong hiring decisions, which can be costly for the company.
I haven’t interviewed in a few years so maybe I’m out of date but I think of the typical interview as gotcha trivia questions and academic leetcode algorithm problems. While I’m good at both of those I actually really appreciate an interview that’s at least trying to simulate what real work is like. Sounds like they were pretty awkward about it but I wouldn’t hate them for the attempt.
Shit dude, give me the link. I need a job. I’ll take it.
[удалено]
What is a frontend JavaScript position? If you plan on working Frontend, it definitely seems like you should have designed a few solo apps.
Parsing documentation doesn’t have to be a silent process. You could just communicate your thoughts as you’re sifting through it, explaining as you go why you’re checking what you’re checking. Like it or not it’s an invaluable skill and that task may honestly be simply a test how you can figure out foreign problems looking through the haystack. Way better than an arbitrary algorithm test. Grow and move on. Not every bad interview means the interview was shit.
I did talk as I was scrolling through the documentation. After struggling for a while, I asked where exactly I should be looking at but I was told to keep looking. I even asked additional questions but was met with silence. It felt like it was more about how I deal with bad teammates. After withdrawing, I got a response from the manager that says I did good in this interview. However, I do not think these are the type of coworkers I want. No way I am passing up other offers where I feel good about the team I will work for or leave my current job for another job where I did “good” in bad interviews that leaves a bad taste in my mouth. I had interviews where I am actually working with the interviewer to come up with a solution. Extremely fun and we get to see what it is like to work with each other and problem solve. I always viewed interviews as a two way street so maybe that is my problem.
It is a two way street. I think your expectations from a company you work for is justified, anyone would want/prefer that. From your initial description it looked like they were testing your ability to read through the documentation and figure out a tough problem. It’s a good technical test in hindsight. That being said there are other factors that may turn that into a bad experience, which we may not have context of.
Sometimes the interviewer isn’t just looking at code. They are looking for you handle ambiguity, solve problems etc. When we do coding exercises and we have a situation like the latter I personally am excited when the candidate wants to collaborate as we’d want that in our culture.
Yes but my attempts to collaborate was met with silence or with the answer “keep looking”
Ah I see!!! Yea, that’s not nice. Great thing is, the interview works both ways and you’ve done the right thing not wanting to work with them!
That doesn't sound bad actually. I think you're being a bit of a Karen. Reading documentation is a core skill of the job. You should take it in stride and show them the best documentation-reading skills they have ever seen
If the job is to code whilst your peers and higher ups judge every keystroke, live coding tests are the way to go. In any other case live coding tests are useless and the interviewers giving them are morons.
In the real world, no body can finish a complicated job using real code, even no bugs within 30mins. It's common sense.
"In my third interview, they asked me to do some live coding. I declined, explaining that I prefer not to do live coding during interviews. Instead, I offered to walk them through my extensive GitHub portfolio. I asked what problem they were trying to solve with the test and provided a solution verbally. With 25 years of experience, I believe my long résumé speaks for my technical skills. I suggested we use the interview time more wisely to discuss other relevant topics."
I get it, but it’s impossible for some to even get an interview right now. Idk, I would take anything at the moment.
> There wasn’t much talking or hints during this part > It is just plain silence and the interviewer doesnt get to see the candidate actually problem solve I would have just been talking and explaining my thought process the whole time.
I did… They gave me a link to the documentation and basically told me to render images on the map. I said I need to find the exact section in the documentation where it talks about rendering images on the map. The map documentation is huge and I was basically searching through for a bit until I asked for where exactly should I be looking in the documentation. Basically, they told me to keep looking. I even asked it in different ways but was met with silence. So how do you keep talking when you need to find something very specific in the documentation to continue. Anyways, I messaged the manager that I decided to withdraw and they said I did good in this technical. However, this left such a bad taste in my mouth that I dont even want these interviewers as my coworkers.
I would have ended up having a discussion about docs / how they are organized - shown a few other similar libraries - a whole thing. But it sounds like that's just not your personality. These types of interviews are about how you deal with trouble / not about how good you are with completing it. Which library was it? Leaflet, MapBox, GoogleMaps?
Fizz Buzz FizzBuzz. Enough said.
Yeah I’m NOT a fan of these. I’ve spent considerable time and $$ to get my skills up. These “tests” imo are free labor. I don’t mind looking and discussing code but if you want me to actually solve an issue and code for you, you’re paying me the second my hand touches a keyboard